Log4Shell seis meses después: Por qué la vulnerabilidad sigue siendo peligrosa
Seis meses después del descubrimiento de Log4Shell (CVE-2021-44228), la vulnerabilidad sigue presente en millones de sistemas. Los atacantes la siguen explotando activamente. Por qué el parcheado es tan difícil y qué deben hacer las empresas ahora.
En resumen
- Todavía activo: 6 meses después del descubrimiento, se estima que el 30% de las instancias de Log4j no están parcheadas.
- Dependencias profundas: Log4j está presente en miles de aplicaciones Java, a menudo profundamente en la cadena de dependencias.
- Actores estatales: Grupos APT de China, Irán y Corea del Norte utilizan Log4Shell para espionaje.
- CVSS 10.0: La máxima calificación de gravedad – Ejecución remota de código sin autenticación.
- Debate sobre SBOM: Log4Shell ha acelerado la demanda de Software Bill of Materials.
Por qué Log4Shell es un problema duradero
Cuando el 9 de diciembre de 2021 se hizo pública la vulnerabilidad Log4Shell, los expertos hablaron de la brecha de seguridad más grave de la década. Log4j, una biblioteca de registro Java, está presente en millones de aplicaciones – desde servidores de Minecraft hasta software empresarial de VMware, Cisco e IBM. El problema: muchas empresas ni siquiera saben dónde se utiliza Log4j en sus sistemas.
Seis meses después, la situación es desalentadora. Según Qualys, aún alrededor del 30% de las instancias de Log4j no están parcheadas. Las razones son variadas: Log4j se oculta como una dependencia transitiva en complejos stacks de software, los sistemas legacy no pueden actualizarse fácilmente y algunos fabricantes aún no han proporcionado parches.
Quién está explotando Log4Shell ahora
Mientras que en las primeras semanas fueron principalmente los mineros de criptomonedas y las botnets los que explotaron la brecha, ahora los actores estatales han tomado el control. La CISA documenta la explotación activa por parte de grupos APT de China (Deep Panda), Irán (TunnelVision) y Corea del Norte (Lazarus). Estos grupos utilizan Log4Shell como vector de acceso inicial para campañas de espionaje a largo plazo.
Qué deben hacer las empresas ahora
El primer paso es un escaneo completo de todos los sistemas en busca de versiones de Log4j – incluyendo dependencias incrustadas y transitivas. Herramientas como Syft, Grype o el escáner Log4j de CISA ayudan en esto. A continuación, todas las instancias deben actualizarse al menos a la versión 2.17.1. Donde el parcheado no sea posible, deben emplearse soluciones alternativas (eliminación de la clase JndiLookup) y segmentación de red.
Datos clave de un vistazo
CVE: CVE-2021-44228 (Log4Shell), CVSS 10.0
Descubrimiento: 9 de diciembre de 2021
Sin parchear (julio de 2022): Se estima que el 30% de todas las instancias
Software afectado: Miles de aplicaciones Java (VMware, Cisco, IBM, Apache, entre otros)
Fuente: Aviso de CISA, Investigación de Qualys, Sonatype, julio de 2022
Hecho: Solo el 43% de las PYMES alemanas tienen un plan de emergencia informática, según Bitkom.
Hecho: Según el Allianz Risk Barometer 2025, los ciberataques son el mayor riesgo empresarial a nivel mundial.
Preguntas frecuentes
¿Qué hace que Log4Shell sea tan peligroso?
Log4Shell permite la ejecución remota de código sin autenticación – un atacante puede ejecutar cualquier código en el servidor insertando una cadena especialmente diseñada en un campo de registro. La vulnerabilidad tiene la puntuación máxima de CVSS de 10.0 y es trivial de explotar.
¿Cómo puedo saber si mis sistemas están afectados?
Utilice escáneres como el escáner Log4j de CISA, Syft o Grype. Importante: Log4j puede estar oculto como una dependencia transitiva en software que no utiliza Java directamente. También revise las imágenes de contenedores, aplicaciones incrustadas y dispositivos IoT.
¿Es suficiente un parche a la versión 2.17.1?
Sí, la versión 2.17.1 corrige todas las variantes conocidas de Log4Shell. Sin embargo, todas las instancias deben estar parcheadas – también las incrustadas. Con software de terceros, depende de sus actualizaciones. Verifique el estado del parche con todos los fabricantes.
¿Por qué tarda tanto el parcheado?
Log4j es una de las bibliotecas Java más utilizadas y a menudo está presente como una dependencia transitiva varias capas profundas en los stacks de software. Los sistemas legacy no pueden actualizarse fácilmente y algunos fabricantes aún no han proporcionado parches. Además, muchas empresas carecen de una visión general de todos los componentes de software utilizados.
¿Qué tiene que ver Log4Shell con SBOM?
Log4Shell ha acelerado masivamente la discusión sobre Software Bill of Materials (SBOM). Un SBOM lista todas las componentes de software y dependencias. Si las empresas hubieran tenido SBOMs, habrían sabido en cuestión de minutos dónde se utiliza Log4j. El gobierno de EE. UU. ahora exige SBOMs mediante una orden ejecutiva.
Lectura adicional en la red
Seguridad de código abierto en la nube en cloudmagazin: cloudmagazin.com
Estrategias de gestión de parches en mybusinessfuture: mybusinessfuture.com
Por qué los CIOs deben invertir ahora en SBOM en Digital Chiefs: digital-chiefs.de
Artículos relacionados
- SOC basado en IA: Cómo las operaciones de seguridad automatizadas resuelven la escasez de mano de obra
- ChatGPT y ciberseguridad: Cómo la IA cambia el ataque y la defensa
- Directiva NIS2 aprobada: Qué le espera ahora a las empresas
Fuente de imagen: Pexels / Tima Miroshnichenko
