Log4SHELL Angriff: LOG4j 2.x CVE-2021-44228 – Was ist zu Tun?

Sie haben sicherlich schon von der Log4j Lücke gehört. Ich spare mir jetzt auch die Detailbeschreibungen, das Internet ist voll davon (z.B. beim BSI, der CISA oder bei heise). Ein paar Hinweise für die Verteidiger (IT-Admins und CISO Organisationen) kommen aus unserer Sicht aber zu kurz:

1. Ein Scan von außen auf diese Schwachstelle ist kaum möglich – die Angriffsfläche ist zu riesig. Jeder Test von außen kann nur zeigen, dass die Schwachstelle da ist, Ihnen aber keine zuverlässige Antwort liefern, dass sie nicht vorhanden ist.
2. Es gibt mittlerweile gute Listen von Kauf- und OpenSource-Komponenten die betroffen sind. Wichtig: Diese Listen können nie vollständig sein und vor allem ist auch eine ganze Menge an Individualsoftware und selbst programmierter Software betroffen, die in den Listen nie auftauchen wird.
   • https://github.com/authomize/log4j-log4shell-affected
   • https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
   • https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/#affected-products
   • https://github.com/cisagov/log4j-affected-db
   • https://github.com/NCSC-NL/log4shell/tree/main/software
3. Der Fehler kann auch von intern gut und einfach ausgenutzt werden. Auch ein Durchtunneln nach intern ist denkbar. Die Schwachstelle muss also nicht nur in Ihren DMZ bzw. Internet-facing Systemen gefixed werden (auch wenn die sicherlich Priorität haben) sondern in Ihrer gesamten Infrastruktur.
4. Log4j 2.0 kam im Juli 2014 aus der Betaphase. Log4j 1.x hatte im August 2015 sein End-of-Life. Nur Log4j > 2.0 hat den Fehler. D.h. Individualsoftware die Sie seit 2014 ohne Updates betreiben ist mit großer Wahrscheinlichkeit von diesem Fehler nicht betroffen (sie sollten sich aber dennoch dafür angemessen schämen).
5. Der Fehler ist normalerweise in einer Datei mit dem Namen log4j*.jar. Dieses Framework kann aber auch tiefer eingebaut sein oder unter anderem Namen vorhanden sein. Wichtig: „.jar“ Dateien sind normale ZIP Dateien und können mit einem ZIP-Tool (wie 7z oder ähnlichem) bearbeitet werden.
6. Vorsichtshalber und weil Sie das immer tun sollten: Am Ende kann man nicht jeden Angreifer aufhalten. Ein gut funktionierendes Offline-Backup ist wie das Sicherungsnetz eines Hochseilartisten – man hofft, dass man es nie braucht. Falls es aber doch dazu kommt, ist es oft die einzige Überlebensgarantie. Stellen Sie sicher, dass …… ein komplettes Backup Ihrer IT existiert, das zu keinem Zeitpunkt älter als 7 Tage ist. Das Backup enthält neben allen Servern und Datenbanken u.a. eine Kopie des Active Directory (bzw. des System States eines DC).
7. … dieses Backup von einem Angreifer mit Domain-Admin-Rechten und Zugriff auf die Passwörter sämtlicher Domänen-Accounts nicht gelöscht werden kann. 
8. … die Ausführung der Backup-Jobs überwacht wird. Wenn plötzlich weniger Daten als erwartet gesichert werden oder gar keine Daten mehr gesichert werden, fällt dies am nächsten Werktag auf und wird als Security Incident behandelt.

Um den Fehler zu beseitigen gibt es mehrere Wege:

1. Der ideale Weg ist sicherlich das updaten des log4j Frameworks. Dort gibt es dann Settings, um die Schwachstelle zu neutralisieren (allowedJndiProtocols, allowedLdapHosts, allowedLdapClasses). Das greift aber in den Programmcode ein und muss vom Programmhersteller erledigt werden (vor allem weil die Konfiguration von log4j an vielen Stellen passieren kann). Insbesondere bei Individualsoftware ist dies oft langwierig. Unsere Empfehlung: stoßen Sie den Updateprozess an, warten Sie aber nicht darauf.
2. Sowohl Oracle JDK als auch OpenJDK haben seit 2019 eine Einstellung das die Ausnutzung verhindert: Wenn com.sun.jndi.rmi.object.trustURLCodebase auf „false“ steht, kann die Schwachstelle nicht mehr einfach genutzt werden. Da es viele Wege gibt, dieses Setting umzustellen (unter anderem in Aufrufskripten und im Programmcode selbst) ist es kaum möglich herauszufinden, ob diese Einstellung durchgehend wirksam ist. Außerdem existieren bereits wieder Umgehungsmöglichkeiten in bestimmten Konstellationen für diese Lösung. Die Corporate Trust empfiehlt, diese Lösung NICHT zu verwenden.
3. Die gute Nachricht: die verwundbare Funktion wird häufig nicht gebraucht. Der verwundbare Code findet sich in der Datei JndiLookup.class (oder .java). Wenn sie „nur“ der Administrator und nicht der Programmierer sind, empfehlen wir Ihnen, auf allen Rechnern in allen Verzeichnissen und in allen „.jar“-Dateien (siehe oben, das sind „nur“ ZIP-Dateien) nach einer Datei JndiLookup.* zu suchen. Wenn Sie diese auf einem Server NICHT finden, dann können Sie mit >95% Sicherheit sagen, dass dieser Server auch nicht betroffen ist.
   • Unter Linux könnten Sie diese Suche z.B. so machen:
     #> find / -name JndiLookup.* 2> /dev/null
#> find / -name "*.jar" -exec unzip -l \{\} \; 2> /dev/null | fgrep JndiLookup
#> find / -name "*.war" -exec unzip -l \{\} \; 2> /dev/null | fgrep log4j | fgrep -v 1.2
#> find / -name "*.ear" -exec unzip -l \{\} \; 2> /dev/null | fgrep log4j | fgrep -v 1.2
     Wenn diese Befehle keine Ergebnisse liefern, dann wurde der verwundbare Code nicht gefunden.
   • Unter Windows können Sie dies analog mit Powershell erledigen:
     #> Get-ChildItem -Force -Include JndiLookup.* -Name -Recurse -File
     #> Add-Type -AssemblyName "System.IO.Compression.FileSystem"; Get-ChildItem -Force -Path "C:\" -Include *.jar,*.war,*.ear -Recurse -File -ErrorAction SilentlyContinue |% { foreach($entry in ([System.IO.Compression.ZipFile]::Open($_.FullName, 0)).Entries) { if($entry.Name.StartsWith("JndiLookup")) { Write-Host $_.FullName $entry.FullName -Separator '\' } } }
     Wenn diese beiden Befehle keine Ergebnisse liefern, dann wurde der verwundbare Code nicht gefunden.
     (Der zweite Befehl lässt sich nicht im Constrained Language Mode ausführen.)
4. Wenn Sie eine Datei mit dem Namen JndiLookup finden, prüfen Sie als nächstes ob diese Teil eines log4j Frameworks ist. Dies ist typischerweise der Fall, wenn im Pfad zu der Datei irgendwas mit „log“ steht, wenn die Datei im .jar File im Unterordner „org/apache/logging/log4j/core/lookup“ liegt oder im gleichen Verzeichnis eine Datei „Log4jLookup“ liegt. Wenn ja, löschen Sie die „JndiLookup.class“ Datei einfach aus der .jar-Datei (z.B. mit 7z) oder dem Dateisystem (ja bitte, machen Sie vorher eine Sicherungskopie – aber passen Sie auf, dass die nicht aufgerufen werden kann). Dann testen Sie die Anwendung nochmal kurz durch – maximal sollte es aber ein paar kleinere Probleme bei der Logausgabe geben. Typische „false positives“ der obigen Befehle sind JndiLookup Klassen im Spring Framework oder das log4javascript-Framework (Dateiendung .js) – Frameworks sind nicht betroffen.

Wenn Sie die obigen Schritte befolgt haben, sich aber noch immer nicht sicher sind, dann können Sie optional weitere Verteidigungsmaßnahmen aktivieren. Wir haben diese Maßnahmen deswegen als optional gekennzeichnet, weil der Aufwand zur Implementierung in Abhängigkeit von Ihrer Infrastruktur eventuell nicht mehr im Verhältnis zur erwarteten Schutzwirkung steht. Falls eine dieser Maßnahmen für Sie eine „low hanging fruit“ ist, ergreifen Sie die bitte:

• Verhindern von Ausleitung oder Nachladen von Code: Sämtliche interne Server von der DMZ bis hin zum Logserver dürfen selbstständig Verbindungen nur zu dediziert freigeschaltenen Zielen im Internet herstellen (per Whitelisting an der Firewall, mit einem Proxy oder einer host-based Firewall). Diese Maßnahme ist aufwändig und kann schnell zu unerwünschten Nebenwirkungen führen, ist aber auf Dauer ohnehin sinnvoll.
• Einsatz einer XDR-Lösung auf den Zielsystemen, die Code auf bekannte Angriffe prüfen (z.B. Defender for Endpoint, Crowdstrike oder das XDR Tool Ihres Anti-Malware-Herstellers). Denken Sie daran, dass Sie diese Tools monitoren müssen und dafür ggf. ein SOC brauchen.
• Überprüfen von Anfragen an die Applikation auf Ausnutzung der Schwachstelle, z.B. mit einer Web Application Firewall, einem entsprechenden Firewallmodul in Ihrer Bestandsfirewall oder einem Internetbasierten Dienst wie Cloudflare oder andere (https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/). Auch diese Gegenmaßnahme braucht Zeit und Testkapazitäten.

Weitere Ressourcen für die Verteidigerseite finden Sie hier:

• Liste von IOCs die derzeit bekannt sind: https://github.com/curated-intel/Log4Shell-IOCs
• Detection Rules: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• Microsoft Empfehlungen (inklusive IOCs und Hunting Queries): https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
• IOC Liste von Cloudflare: https://blog.cloudflare.com/actual-cve-2021-44228-payloads-captured-in-the-wild/