Hace algunas semanas la noticia de los problemas de seguridad de Log4j estuvieron poniendo de cabeza a muchos usuarios en la red y es que es una de las fallas que más se ha explotado y la cual muchos expertos han etiquetado como «la más peligrosa en mucho tiempo», de las vulnerabilidades que se dieron a conocer en la red hablamos de algunas de ellas aquí en el blog y en esta ocasión hemos encontrado la noticia de otra.

Y es que hace pocos dias se dio a conocer la noticia de que se identificó otra vulnerabilidad en la biblioteca Log4j 2 (la cual ya está catalogada bajo CVE-2021-45105) y que, a diferencia de los dos problemas anteriores, se clasificó como peligrosa, pero no crítica.

El nuevo problema permite una denegación de servicio y se manifiesta en forma de bucles y terminaciones anormales al procesar ciertas líneas.

La vulnerabilidad afecta a los sistemas que utilizan la búsqueda de contexto, como ${ctx: var}, para determinar el formato de salida del registro.

Las versiones de Log4j de 2.0-alpha1 a 2.16.0 carecían de protección contra la recursividad incontrolada, lo que permitía a un atacante manipular el valor utilizado en sustitución para provocar un bucle sin fin que se quedaría sin espacio en la pila y provocaría que el proceso se bloqueara. En particular, el problema se produjo al sustituir valores como «$ {$ {:: – $ {:: – $$ {:: – j}}}}».

Además, se puede notar que investigadores de Blumira han propuesto un ataque a aplicaciones Java vulnerables que no aceptan solicitudes de redes externas, por ejemplo, se pueden atacar sistemas de desarrolladores o usuarios de aplicaciones Java de esta forma.

La esencia del método es que si hay procesos Java vulnerables en el sistema del usuario que aceptan conexiones de red solo desde el host local (localhost), o procesan RMI-solicitudes (Invocación de método remoto, puerto 1099), el ataque puede ser realizado por código JavaScript ejecutado cuando el usuario abre una página maliciosa en el navegador. Para establecer una conexión al puerto de red de una aplicación Java en un ataque de este tipo, se usa la API de WebSocket, a la cual, a diferencia de las solicitudes HTTP, no se aplican restricciones del mismo origen (WebSocket también se puede usar para escanear puertos de red en el local host para determinar los controladores de red disponibles).

También son de interés los resultados de evaluar la vulnerabilidad de las bibliotecas asociadas a las dependencias con Log4j publicados por Google. Según Google, el problema afecta al 8% de todos los paquetes en el repositorio de Maven Central.

En particular, 35863 paquetes Java relacionados con Log4j con dependencias directas e indirectas fueron expuestos a vulnerabilidades. A su vez, Log4j se utiliza como dependencia directa del primer nivel solo en el 17% de los casos, y en el 83% de los paquetes cubiertos por la vulnerabilidad, la vinculación se realiza a través de paquetes intermedios que dependen de Log4j, es decir. dependencias del segundo y más alto nivel (21% – el segundo nivel, 12% – el tercero, 14% – el cuarto, 26% – el quinto, 6% – el sexto).

El ritmo de reparación de la vulnerabilidad todavía deja mucho que desear, una semana después de que se identificó la vulnerabilidad, de 35863 paquetes identificados, el problema se ha solucionado hasta ahora solo en 4620, es decir, al 13%.

Los cambios en los paquetes son necesarios para actualizar los requisitos de dependencia y reemplazar los enlaces de versiones antiguas con versiones fijas de Log4j 2 (los paquetes de Java practican el enlace a una versión específica, y no un rango abierto que permite la instalación de la versión más reciente).

La eliminación de la vulnerabilidad en las aplicaciones Java se ve obstaculizada por el hecho de que los programas a menudo incluyen una copia de las bibliotecas en la entrega, y no es suficiente actualizar la versión Log4j 2 en los paquetes del sistema.

Mientras tanto, la Agencia de EE. UU. Para la Protección de la Infraestructura y la Ciberseguridad emitió una directiva de emergencia que requiere que las agencias federales para que identificaran los sistemas de información afectados por la vulnerabilidad Log4j e instalaran las actualizaciones que bloqueen el problema antes del 23 de diciembre.

Por otra parte, se dio una pauta hasta el 28 de diciembre, en la cual las organizaciones tenían la obligación de informar sobre el trabajo realizado. Para simplificar la identificación de sistemas problemáticos, se ha elaborado una lista de productos en los que se ha confirmado la manifestación de una vulnerabilidad (hay más de 23 mil aplicaciones en la lista).

Finalmente, cabe mencionar que la vulnerabilidad se solucionó en Log4j 2.17 la cual fue publicada hace algunos dias y se recomienda a los usuarios que tienen las actualizaciones desactivadas, realicen la actualización correspondiente, ademas de que el peligro de la vulnerabilidad se mitiga por el hecho de que el problema se manifiesta solo en sistemas con Java 8.

Fuente: https://logging.apache.org/