Los investigadores de seguridad cibernética han descubierto un vector de ataque completamente nuevo que permite a los enemigos explotar las vulnerabilidades de Log4Shell en los servidores localmente utilizando una conexión JavaScript WebSocket.

«Este vector de ataque recientemente descubierto significa que cualquier persona con una versión vulnerable de Log4j en su computadora o red privada local puede navegar por el sitio web y potencialmente activar la vulnerabilidad», dijo Matthew Warner, CTO de Blumira. «Actualmente no hay evidencia de abuso activo. Este vector expande significativamente el alcance del ataque y puede afectar los servicios que se ejecutan como localhost que no han estado expuestos a ninguna red».

WebSockets permite la comunicación bidireccional entre un navegador web (u otra aplicación cliente) y un servidor, a diferencia de HTTP, que es unidireccional, donde el cliente envía una solicitud y el servidor envía una respuesta.

Aunque el problema se puede resolver actualizando todos los entornos de desarrollo local e Internet a Log4j 2.16.0, Apache lanzó la versión 2.17.0 el viernes, que corrige una vulnerabilidad de denegación de servicio (DoS) rastreada como CVE-2021-45105 (puntuación CVSS: 7.5), que es el tercer error de Log 4j2 que se produjo después de CVE-2021-45046 y CVE-2021-44228.

La lista completa de deficiencias descubiertas en el marco de registro después de que se descubrió el error de ejecución del código remoto original de Log4Shell es la siguiente:

• CVE-2021-44228 (Puntuación CVSS: 10.0) – Vulnerabilidad en la ejecución remota de código que afecta a las versiones 2.0-beta9 a 2.14.1 de Log4j (corregida en la versión 2.15.0)
• CVE ‑ 2021‑45046 (Puntuación CVSS: 9.0) – Vulnerabilidad y ejecución remota de código que afecta a las versiones 2.0-beta9 a 2.15.0 de Log4j, excepto 2.12.2 (corregido en la versión 2.16.0)
• CVE-2021-45105 (Puntuación CVSS: 7.5) – Vulnerabilidad de denegación de servicio que afecta a las versiones 2.0-beta9 a 2.16.0 de Log4j (corregida en la versión 2.17.0)
• CVE-2021-4104 (Puntuación CVSS: 8.1) – Error de deserialización no confiable que afecta a Log4j versión 1.2 (no hay solución disponible; actualice a la versión 2.17.0)

«No debería sorprendernos que se hayan identificado vulnerabilidades adicionales en Log4j debido a otro enfoque específico en la biblioteca», dijo Jake Williams, CTO y cofundador de BreachQuest Incident Response. «Al igual que con Log4j, esta detección inicial de la vulnerabilidad printNightmare de este verano llevó a la detección de muchas otras vulnerabilidades diferentes. El descubrimiento de vulnerabilidades adicionales en Log4j no debería generar preocupaciones de seguridad para el propio log4j. En todo caso, Log4j es más seguro debido a la atención adicional que brindan los científicos pagar.»

El último desarrollo se produce cuando varios actores de amenazas han acumulado las deficiencias de Log4j para lanzar una serie de ataques, que incluyen infecciones de ransomware que involucran al grupo ruso Conti y una nueva cepa de ransomware llamada Khonsari. Además, el error de ejecución remota de código Log4j, según investigadores de Sangfor y Curated Intel, también abrió la puerta a una tercera familia de ransomware conocida como TellYouThePass, que se utiliza para atacar dispositivos Windows y Linux.

Bitdefender Honeypots Signal Active Log4Shell 0 días de ataques en curso

Las vulnerabilidades ubicuas y fácilmente explotables, además de crear hasta 60 variantes, brindan una ventana de oportunidad perfecta para los oponentes, y la firma rumana de ciberseguridad Bitdefender informa que más del 50% de los ataques utilizan el anonimato de Tor para disfrazar sus verdaderos orígenes.

«En otras palabras, los actores de amenazas que utilizan Log4j dirigen sus ataques a través de máquinas que están más cerca de sus objetivos previstos, y el hecho de que no veamos países comúnmente asociados con amenazas de ciberseguridad en la parte superior de la lista no significa que los ataques lo hayan hecho. no ocurrió. allí «, dijo Martin Zugec, director de soluciones técnicas de Bitdefender.

Según los datos de telemetría recopilados entre el 11 y el 15 de diciembre, solo Alemania y Estados Unidos representaron el 60% de todos los intentos de recuperación. Los objetivos más comunes del ataque durante el período que se examina fueron Estados Unidos, Canadá, Reino Unido, Rumania, Alemania, Australia, Francia, Países Bajos, Brasil e Italia.

Google: más de 35.000 paquetes de Java afectados por Log4j

El desarrollo también concuerda con un análisis del equipo Open Source Insights de Google, que encontró que alrededor de 35,863 paquetes de Java, que representan más del 8% del almacenamiento de Maven Central, usaban versiones vulnerables de la biblioteca Apache Log4j. De los artefactos afectados, solo unos 7.000 paquetes dependen directamente de Log4j.

«La falta de visibilidad de los usuarios acerca de sus dependencias y dependencias transitorias dificulta el parcheo; también dificulta determinar el radio completo de esta vulnerabilidad», dijeron James Wetter y Nicky Ringland de Google. En el lado positivo, los 2.620 paquetes en cuestión ya se han reparado menos de una semana después de su publicación.

«Probablemente llevará algún tiempo comprender el impacto total de la vulnerabilidad log4j, pero solo porque está integrado en una gran cantidad de software», dijo Williams. «Esto no tiene nada que ver con el malware para los actores de amenazas. Tiene que ver con la dificultad de encontrar la miríada de sitios donde se construye la biblioteca».