La magnitud y el impacto de la crisis de Log4j han quedado patentes esta semana cuando el equipo de código abierto de Google ha informado de que la friolera de 35.863 paquetes en Java de Maven Central siguen utilizando versiones defectuosas de la biblioteca Log4j. Maven Central es el mayor y más importante repositorio de paquetes en Java.
Más del 8% de todos los paquetes en Maven Central tienen al menos una versión que está afectada por esta vulnerabilidad, dijeron los investigadores James Wetter y Nicky Ringland del equipo Open Source Insights de Google. “En cuanto al impacto en el ecosistema, el 8% es enorme. El impacto medio en el ecosistema de los avisos que afectan a Maven Central es del 2%, y la mediana es inferior al 0,1%”, explicaron los expertos de Google, añadiendo que “todavía es difícil determinar el pleno alcance de esta vulnerabilidad”.
La vulnerabilidad, identificada como CVE-2021-44228, fue descubierta y notificada inicialmente por el equipo de seguridad en la nube de Alibaba el pasado 24 de noviembre. Menos de dos semanas después, se detectó su explotación en la naturaleza, lo que provocó la publicación de múltiples parches de alta prioridad y un esfuerzo de toda la industria por aplicar mitigaciones prácticas.
En las últimas dos semanas, actores de APT vinculados a China, Irán, Corea del Norte y Turquía han añadido exploits para el fallo de ejecución de código en kits de herramientas de hackeo y hay múltiples informes fiables de que bandas de ransomware y botnet también están lanzando exploits de malware para Log4j.
Los expertos advierten de que la erradicación del problema será un proceso largo y laborioso debido a las dependencias de software y a las llamadas “dependencias transitivas” que dificultan mucho la aplicación de parches.
Entre los 35.863 artefactos Java vulnerables en Maven Central, el equipo de Google descubrió que las dependencias directas representan alrededor de 7.000 de los artefactos afectados, lo que significa que cualquiera de sus versiones depende de una versión afectada de log4j-core o log4j-api, como se describe en las CVE.
“La mayoría de los artefactos afectados provienen de dependencias indirectas (es decir, las dependencias de las propias dependencias), lo que significa que log4j no está definido explícitamente como una dependencia del artefacto, sino que es arrastrado como una dependencia transitiva”, explicaron los investigadores.
“En el momento de escribir estas líneas, se han corregido casi cinco mil de los artefactos afectados. Esto representa una respuesta rápida y un esfuerzo descomunal tanto de los mantenedores de log4j como de la comunidad más amplia de consumidores de código abierto. Eso deja más de 30.000 artefactos afectados, muchos de los cuales dependen de otro artefacto a parchear (la dependencia transitiva) y probablemente están bloqueados”.
El principal problema que se plantea es que la mayoría de los artefactos dependen de Log4j de forma indirecta, lo que significa que cuanto más profunda sea la vulnerabilidad en una cadena de dependencia, más pasos se requieren para su reparación.
“Para más del 80% de los paquetes afectados, la vulnerabilidad se encuentra a más de un nivel de profundidad, con una mayoría afectada a cinco niveles y algunos hasta a nueve niveles”, dijo el equipo de Google. “Estos paquetes requerirán correcciones en todas las partes del árbol, empezando por las dependencias más profundas primero”. Los investigadores creen que habrá que aguantar “una larga espera, probablemente años” antes de que todos los artefactos afectados por las vulnerabilidades de Log4j estén completamente parcheados.
