El impacto de la infame vulnerabilidad en la biblioteca Java Log4j se prolonga. Aunque el mayor problema se resolvió con el parche urgente 2.16, esta versión también parece ser susceptible de abuso. Los investigadores de seguridad encontraron una entrada para los ataques de denegación de servicio (DoS). Se ha publicado Log4j 2.17 para cerrar la entrada.
Apache, desarrollador de la biblioteca Java, aconseja a las organizaciones que apliquen el parche de emergencia. Ese consejo se aplica por tercera vez desde que se descubrió que la biblioteca era vulnerable.
Hace una semana y media, los investigadores de seguridad de Alibaba cloud El equipo de seguridad reveló un método para abusar de las aplicaciones con Log4j. Log4j se utiliza en aplicaciones para registrar eventos. Resultó posible acceder a aplicaciones con la biblioteca desde el exterior con instrucciones para ejecutar malware. El abuso toma poco más que un chasquido. Agregue a eso la ocurrencia estimada de la biblioteca en la mayoría de los entornos corporativos y comprenderá la escala del desastre que enfrenta el panorama global de TI.
Los desarrolladores de software como Fortinet, Cisco, IBM y muchos otros utilizan la biblioteca en su software. Sus desarrolladores trabajaron horas extra durante el fin de semana del 11 de diciembre para procesar el primer parche de emergencia para la vulnerabilidad y entregarlo a las organizaciones de usuarios. Se esperaba exactamente la misma deriva de los equipos de TI dentro de estas organizaciones. Cientos de miles de intentos de ataque tuvieron lugar en todo el mundo. Todos tenían que cambiar a 2.15 lo antes posible, hasta que también se descubrió que 2.15 era vulnerable.
Ciertas configuraciones de la biblioteca seguían siendo posibles en la versión 2.15. El uso de estas configuraciones perpetuó la vulnerabilidad. La versión 2.16 imposibilitaba las configuraciones, garantizando un nuevo parche. A menudo, para disgusto de los equipos de TI que ya están sobrecargados de trabajo. Sin embargo, siempre puede ser peor, porque 2.16 también tiene una dolencia.
De regreso al comienzo
La atención global masiva al problema provocó una investigación mundial masiva. Apache, desarrollador de la biblioteca, parece no poder recuperar el aliento durante dos días sin que una empresa de seguridad señale un problema nuevo y apremiante.
En resumen, resulta que es posible ejecutar docenas de versiones de log4j, incluida la 2.16, con una línea (cadena) para iniciar un bucle eterno que bloquea la aplicación. Las condiciones que debe cumplir un entorno para que se abuse de él son muy amplias. Tan extenso que se discute la gravedad práctica del problema. El parche se recomienda oficialmente, pero no todos están convencidos.
Nuevamente, no todas las instancias de Log4j son vulnerables, sino solo los casos en los que la biblioteca se ejecuta en configuraciones personalizadas. Un atacante potencial también necesita información detallada sobre cómo funciona Log4j. Un contraste con la vulnerabilidad inicial, de fácil acceso.