O impacto da infame vulnerabilidade na biblioteca de Java Log4j perdura. Aínda que o maior problema foi resolto co parche urxente 2.16, esta versión tamén parece ser susceptible de abuso. Os investigadores de seguridade atoparon unha entrada para ataques de denegación de servizo (DoS). Log4j 2.17 foi publicado para pechar a entrada.
Apache, desenvolvedor da biblioteca Java, aconsella ás organizacións que apliquen o parche de emerxencia. Ese consello aplícase por terceira vez desde que se descubriu que a biblioteca era vulnerable.
Hai unha semana e media, investigadores de seguridade de Alibaba cloud equipo de seguridade revelou un método para abusar das aplicacións con Log4j. Log4j úsase en aplicacións para rexistrar eventos. Resultou que era posible acceder a aplicacións coa biblioteca desde fóra con instrucións para executar malware. O abuso leva pouco máis que un instante. Engade a iso a aparición estimada da biblioteca na maioría dos ambientes corporativos e entenderás a magnitude do desastre ao que se enfronta o panorama global das TI.
Os desenvolvedores de software como Fortinet, Cisco, IBM e decenas de outros usan a biblioteca no seu software. Os seus desenvolvedores traballaron horas extra durante a fin de semana do 11 de decembro para procesar o primeiro parche de emerxencia para a vulnerabilidade e entregalo ás organizacións de usuarios. Espérase exactamente a mesma deriva dos equipos informáticos destas organizacións. Centos de miles de intentos de ataque producíronse en todo o mundo. Todo o mundo tiña que cambiar á 2.15 o antes posible, ata que tamén se descubriu que 2.15 era vulnerable.
Certas configuracións da biblioteca seguían sendo posibles na versión 2.15. O uso destas configuracións perpetuou a vulnerabilidade. A versión 2.16 imposibilitaba as configuracións, garantindo un novo parche. Moitas veces para disgusto dos equipos informáticos xa sobrecargados. Non obstante, sempre pode ser peor, porque 2.16 tamén ten unha doenza.
Volver ao comezo
A atención global masiva ao problema provocou unha investigación masiva en todo o mundo. Apache, desenvolvedor da biblioteca, parece que non pode recuperar o alento durante dous días sen que unha empresa de seguridade sinala un problema novo e urxente.
En resumo, resulta que é posible executar ducias de versións de log4j, incluída a 2.16, cunha liña (cadea) para iniciar un bucle eterno que faga falla a aplicación. As condicións que debe reunir un ambiente para ser abusado son amplas. Tan extenso que se cuestiona a gravidade práctica do problema. O parche é oficialmente recomendado, pero non todos están convencidos.
Unha vez máis, non todas as instancias de Log4j son vulnerables, senón só os casos nos que a biblioteca se executa con configuracións personalizadas. Un atacante potencial tamén necesita información detallada sobre como funciona Log4j. Un contraste coa vulnerabilidade inicial, de fácil acceso.