Como si el hallazgo de un fallo fácilmente explotable y extremadamente peligroso en la omnipresente biblioteca de registro de Java Apache Log4j no hubiera puesto ya de cabeza a la comunidad de seguridad de Internet, los investigadores han encontrado ahora una nueva vulnerabilidad en el parche de Apache publicado para mitigarla.
El jueves pasado los investigadores de seguridad comenzaron a advertir que una vulnerabilidad rastreada como CVE-2021-44228 en Apache Log4j estaba bajo ataque activo y tenía el potencial, según muchos informes, de romper Internet. Apodado Log4Shell por LunaSec, el fallo reside en la biblioteca de registro Java ampliamente desplegada y es un error de ejecución remota de código (RCE) que es sencillo de explotar en muchos servicios y productos.
Un aluvión de atacantes se lanzó inmediatamente sobre Log4Shell, inicialmente para desatar código malicioso en servidores o clientes que ejecutaban la versión Java de Minecraft manipulando los mensajes de registro, incluso del texto escrito en los mensajes de chat. Luego, los atacantes comenzaron a ramificarse, generando 60 o más mutaciones mayores del exploit original en un día.
Apache se apresuró a publicar un parche para corregir Log4Shell con la versión 2.15.0 de Log4j el pasado viernes. Pero ahora los investigadores han descubierto que este parche «está incompleto en ciertas configuraciones no predeterminadas» y abre el camino a ataques de denegación de servicio (DoS) en determinados escenarios, según un aviso de seguridad de Apache.org.
El fallo recién descubierto, rastreado como CVE-2021-45046, podría permitir a los atacantes con control sobre los datos de entrada del Mapa de Contexto de Hilos (MDC) elaborar datos de entrada maliciosos utilizando un patrón de búsqueda de la Interfaz de Nombres y Directorios de Java (JNDI) en ciertos casos, lo que resulta en un ataque de denegación de servicio, según el aviso.
La configuración de la explotación se produce cuando la configuración del registro utiliza un diseño de patrón no predeterminado con una búsqueda de contexto – por ejemplo, $${ctx:loginId} – o un patrón de mapa de contexto de hilo (%X, %mdc o %MDC), según el aviso.
«Log4j 2.15.0 restringe las búsquedas JNDI LDAP a localhost por defecto», según Apache.org. «Tenga en cuenta que las mitigaciones anteriores que implican la configuración como establecer la propiedad del sistema log4j2.noFormatMsgLookup a true NO mitigan esta vulnerabilidad específica».
Arreglando lo arreglado
Una nueva versión de Log4j, la 2.16.0, corrige el problema eliminando el soporte para los patrones de búsqueda de mensajes y desactivando la funcionalidad JNDI por defecto, según el aviso. Para mitigar el fallo en las versiones anteriores de Log4j, los desarrolladores pueden eliminar la clase JndiLookup del classpath, según aconseja Apache.org.
Un profesional de la seguridad señaló que la prisa de Apache por publicar un parche para Log4Shell tras el pánico inicial por su descubrimiento puede haber causado inadvertidamente la última CVE.
«A menudo, apresurarse a lanzar parches para corregir vulnerabilidades significa que la solución puede no ser completa, como es el caso aquí», observó John Bambenek, principal cazador de amenazas de Netenrich, en un correo electrónico enviado a Threatpost el martes. Dijo que la solución al problema es «desactivar por completo la funcionalidad de JNDI».
Dado que ya se sabe que al menos una docena de grupos están explotando estas vulnerabilidades, instó a tomar medidas inmediatas para parchear, eliminar JNDI de Log4j o sacarlo del classpath – «preferiblemente todo lo anterior», dijo Bambenek.
Cómo controlar la situación
Los investigadores y los profesionales de la seguridad todavía están dándole vueltas a las amplias implicaciones de Log4Shell, así como a la posibilidad de que se descubran aún más fallos relacionados, señaló otro profesional de la seguridad.
«Cuando se descubre una vulnerabilidad y hace tanto ruido como Log4Shell, invariablemente indica que hay más vulnerabilidades en el mismo software o correcciones para ese software y desencadena investigaciones y descubrimientos adicionales», escribió Casey Ellis, fundador y CTO de Bugcrowd, en un correo electrónico a Threatpost.
De hecho, ya existe cierta confusión sobre cuántas vulnerabilidades existen actualmente relacionadas con Log4Shell y cómo se correlacionan entre sí, lo que se suma a la avalancha de información que se está publicando sobre el fallo, escribieron los investigadores de RiskBased Security en una entrada de blog publicada el martes.
En este momento, hay tres CVEs publicadas asociadas a Log4Shell – CVE-2021-44228, el día cero original; CVE-2021-45046, la «corrección incompleta»; y CVE-2021-4104, un fallo encontrado en otro componente de Log4j, JMSAppender, que no parece ser de gran preocupación, según el equipo de RiskBased Security.
En el caso de la CVE-2021-44228, los investigadores sostienen que no se trata de un problema nuevo en absoluto, «sino que es realmente la misma vulnerabilidad», según el post.
«MITRE y las Autoridades de Numeración de CVE (CNA) asignarán un segundo ID de CVE en los casos de correcciones que no parcheen completamente un problema», escribieron los investigadores. «Esto ayuda a algunas organizaciones en el seguimiento de un problema, mientras que introduce la confusión a otros».
Y a pesar de que hay más de un CVE, «los lugares los han estado tratando como un solo problema, pero esto definitivamente no es el caso», según RiskBased Security.
Peor antes de que mejore
Una cosa que es cierta sobre el creciente drama que rodea a Log4Shell es que, debido a que la superficie de ataque para la vulnerabilidad es tan amplia, hay un gran potencial para la explotación extensa y adicional, según RiskBased Security.
«Es importante señalar que Log4j es un popular marco de registro en Java», escribieron los investigadores en el post. «Esto significa que se utiliza en un número extraordinario de cosas».
De hecho, una larga lista de productos de proveedores son vulnerables a Log4Shell, incluyendo pero no limitado a: Broadcom, Cisco, Elasticsearch, F-secure, Fedora, HP, IBM, Microsoft, National Security Agency (NSA), RedHat, SonicWall y VMWare.
A las pocas horas de la revelación pública del fallo, los atacantes estaban buscando servidores vulnerables y desencadenando ataques para lanzar mineros de monedas, el malware Cobalt Strike, el nuevo ransomware Khonsari, el troyano de acceso remoto (RAT) Orcus. shells bash inversos para futuros ataques, Mirai y otras redes de bots, y puertas traseras.
Pase lo que pase en el futuro, a medida que sigan surgiendo variaciones del exploit original y los atacantes sigan pululando, es probable que la situación empeore antes de mejorar. Esto significa que el polvo sobre Log4Shell probablemente no se asentará durante mucho tiempo.
«Esta nueva vulnerabilidad de Log4j probablemente nos perseguirá durante años», según RiskBased Security.
