Investigadores de Ciberseguridad han descubierto un nuevo método de explotación de la vulnerabilidad Log4Shell en servidores locales mediante una conexión de tipo JavaScript WebSocket.
Este nuevo método de ataque podría llevarse a cabo desde una página web, si se visita con un equipo que tenga la librería Apache Log4j instalada y sin actualizar.
WebSocket es un protocolo de red basado en TPC que permite que una aplicación web establezca una conexión bi-direccional persistente entre la capa de presentación de la web en el navegador y el servidor. Los WebSockets utilizan puertos estándar 80 y 443 igual que http y https aunque con un protocolo de comunicación distinto, que puede estar encriptado (wss://) y sin encriptar (ws://).
Para iniciar el intercambio de datos, el cliente envia una solicitud al servidor y se estable una conexión mediante TCP que permanece abierta tras el handshake (apretón de manos) entre el cliente y servidor.
Por el momento, no se conocen pruebas de que este nuevo vector de entrada esté siendo activamente explotado, pero tras hacerse público por los investigadores, es muy probable que comience a ser utilizada por atacantes. Recordemos las vulnerabilidades encontradas en la librería Apache Log4j:
CVE-2021-44228, con una puntuación de gravedad de 10 sobre 10. Esta vulnerabilidad permite la ejecución de código remoto y afecta a las versiones Log4j desde la 2.0-beta9 hasta la 2.14.1. Ha sido parcheada en la versión Log4j 2.15.0.
CVE-2021-45046, con una puntuación de 9 sobre 10. – Esta vulnerabilidad permite una fuga de información y también la ejecución remota de código. Afecta a las versiones Log4j desde la 2.0-beta9 hasta 2.15.0, excluyendo la versión 2.12.2. Ha sido parcheada en la versión Log4j 2.16.0.
CVE-2021-45105, con una puntuación de 7.5 sobre 10. – Esta vulnerabilidad es de tipo denegación de servicio y afecta a las versiones desde la 2.0-beta9 hasta la 2.16.0. Ha sido parcheada en la versión 2.17.0.
Muchos investigadores coinciden en que podrían encontrarse nuevos vectores de entrada y vulnerabilidades en esta biblioteca en los próximos días tal y como ha ocurrido con otros problemas de seguridad en el pasado.
No debería sorprendernos que se descubrieran vulnerabilidades adicionales en Log4j dado el enfoque específico adicional en la biblioteca. Al igual que Log4j, este verano la divulgación de la vulnerabilidad PrintNightmare original condujo al descubrimiento de múltiples vulnerabilidades distintas adicionales. El descubrimiento de vulnerabilidades adicionales en Log4j no debería causar preocupación sobre la seguridad de log4j en sí. En todo caso, Log4j es más seguro debido a la atención adicional prestada por los investigadores
Jake Williams, CTO de BreachQuest.
Se recomienda actualizar la biblioteca de registro Log4j a su última versión en todos los entornos, local, desarrollo e internet lo antes posible para así evitar el aluvión de ataques que se están produciendo. Ataques con ransomware, malware de minado y otros.
