So funktioniert der Exploit

1. Die Opfer-App protokolliert vom Angreifer bereitgestellte Eingaben aus einem HTTP-Header.
2. Der LDAP-Server des Angreifers antwortet mit einer Referenz auf Exploit.class.
3. Das Opfer ruft Exploit.class über HTTP ab.
4. Der statische Initialisierer in Exploit läuft und erzeugt eine Reverse-Shell zurück zum Angreifer.

2. Risiko

• Auswirkung: Nicht authentifizierte RCE – höchstmöglicher Schweregrad.
• Wer/was ist gefährdet:
  • Jede Java-Anwendung, die Log4j <= 2.14.1 verwendet.
  • Internetzugängliche und interne Dienste, die benutzergesteuerte Eingaben protokollieren (z. B. HTTP-Header).
• Konsequenzen:
  • Systemkompromittierung (Shell-Zugriff).
  • Datenexfiltration.
  • Pivoting in interne Netzwerke.
  • Umgehung von Perimeter-Verteidigungen (Angriffe über interne Dienste).

3. Proof of Concept

Voraussetzungen

1. docker + docker-compose
2. netcat
3. make

Erstellen und starten

Exploit

1. Starten Sie einen netcat-Listener:

2. Exploit auslösen:

3. Netcat empfängt eine Reverse-Shell vom Opfer:

4. Behebung

Bevorzugte Lösung

• Upgrade auf Log4j 2.17.1 oder höher.
• Dies ist die einzige vollständige und langfristige Lösung. Frühere Versionen behoben teilweise, ließen jedoch noch Schwachstellen offen:
  • CVE-2021-45046: RCE über nicht standardmäßige Logging-Konfiguration
  • CVE-2021-45105: DoS über selbstreferenzielle Lookups
  • CVE-2021-44832: RCE über bestimmte JDBC-Appender-Konfigurationen

Zwischenlösungen (falls Upgrade nicht möglich)

1. Zeit gewinnen

• Beschränken Sie eingehende Exploit-Zeichenfolgen (${jndi:-Muster) mit einer WAF oder Middleware.
• Beschränken Sie ausgehendes LDAP von Anwendungsservern mit Egress-Filterung.

2. Lookups deaktivieren:

3. JVM härten:

Operative Maßnahmen

1. Abhängigkeiten und Laufzeit auditieren

• Erstellen Sie eine SBOM (gradle dependencies, Snyk, Wiz, etc.).
• Durchsuchen Sie bereitgestellte Images/Server nach log4j-core-*.jar, einschließlich fat JARs.
• Triagieren und priorisieren Sie Maßnahmen für die riskantesten Workloads.

2. Überwachen & erkennen

• Achten Sie auf Exploit-Versuche in Logs (${jndi:...}, ${${lower:j}ndi:...}, etc.).
• Überwachen Sie ausgehenden LDAP-Verkehr auf Callbacks.
• Behandeln Sie Funde als potenzielle Kompromittierungen, eskalieren Sie zur Incident-Response (forensische Untersuchung, Entfernung bösartiger Artefakte, Rotation von Geheimnissen, etc.).

3. Hersteller-Patches

• Verfolgen Sie Hersteller-Advisories (z. B. Elasticsearch) – viele liefern gebündeltes Log4j aus.
• Wenden Sie bereitgestellte Hotfixes oder Workarounds an, bis offizielle Patches verfügbar sind.

4. Strategische Verbesserungen

• Durchsetzen einer „Standardmäßig verweigern“-Richtlinie für die Filterung ausgehenden Datenverkehrs.
• Erzwingen Sie Dependency Scanning in CI/CD.
• Formalisieren Sie Response-Playbooks, damit Teams genau wissen, was bei der nächsten „10.0 CVSS“-Schwachstelle zu tun ist.
• Führen Sie Resilienzübungen/Tabletops durch, um die Bereitschaft für einen „neuen Log4Shell-Klasse“-Vorfall zu testen.

5. Referenzen

• Apache Security Advisories