Management Summary: Was steckt hinter der Sicherheitslücke in Log4J?

Java spielt in der Softwareentwicklung immer noch eine große Rolle, auch wenn man es nicht wahrnimmt. Anwendungen auf Basis von Java werden zwar weniger, im Hintergrund arbeiten aber auch heute noch viele Java-Komponenten.

Dies bedeutet, dass es eine gewisse Wahrscheinlichkeit gibt, dass in Webservices und auch in Systemdiensten durchaus noch Java zu finden ist. Offensichtlich ist es immer dann, wenn zur Bereitstellung des Dienstes z.B. ein Apache Tomcat[1] als Webserver eingesetzt wird. Aber auch im Hintergrund ist Java auffindbar. Als Beispiel wäre die Software JasperReports[2] zu nennen, auf die wir später nochmals zurückkommen werden.

Wenn eine Software plattformunabhängig arbeiten soll, also gleichermaßen auf Windows, Mac OS und Linux funktionieren soll, wird ebenfalls noch häufig auf Java zurückgegriffen.

Ein Modul in Java ist dabei für das Schreiben von Protokollen zuständig – Log4J. Dieses Modul wurde bisher von einer einzelnen Person in seiner Freizeit gepflegt und wurde ansonsten scheinbar nicht weiter zur Kenntnis genommen. Und genau in diesem Modul ist bereits 2013 eine Änderung programmiert worden, die die hier beschriebene Sicherheitslücke ermöglicht.

Die Sicherheitslücke wurde vom BSI (Bundesamt für Sicherheit in der Informationstechnik) als kritisch[3] eingestuft und hat der Schwachstell die Warnstufe rot zugeordnet.

Wie erfolgt der Angriff?

Hier kann zwischen aktiven Netzwerkdiensten und Anwendungen auf den Systemen unterschieden werden. Bei aktiven Netzwerkdiensten reicht es aus, wenn der Angreifer Kontakt mit den Diensten aufnehmen kann. Durch eine manipulierte Anfrage an den Dienst wird dieser dazu gebracht entsprechende Befehle des Angreifers auszuführen und ggf. Schadsoftware nachzuladen.

Bei lokalen Anwendungen ist der Angriff schon etwas schwieriger. Denn der Angreifer muss bereits Zugriff auf das interne Netzwerk haben. Diesen Zugriff kann der Angreifer beispielsweise durch Phishing-Attacken erlangt haben. Findet der Angreifer nun angreifbare Programmpakete, könnte er die Software entsprechend manipulieren, damit die Sicherheitslücke ausgenutzt wird. Verfügt der Angreifer jedoch nur normale Benutzerrechte und kann auch das Programm nur im Benutzerkontext aufrufen, so erlangt er ohne Ausnutzung weiterer Sicherheitslücken auch weiterhin nur normale Benutzerrechte. Damit könnte der Angreifer die Schadsoftware auch selbst nachladen und ausführen, die Ausnutzung der Sicherheitslücke würde keinen Vorteil bringen. Daher ist die Ausnutzung der Sicherheitslücke bei einer lokalen Anwendung nicht nur schwieriger, sondern wohl auch unwahrscheinlicher.

Läuft die Software jedoch im SYSTEM-Kontext, verfügt der Angreifer durch die Ausnutzung der Sicherheitslücke über erweiterte Rechte und könnte eine Schadsoftware dauerhaft auf dem System platzieren.

Wie lange ist die Sicherheitslücke bereits bekannt?

Auch wenn die Medien erst seit dem Wochenende um den 10.12.2021 von der Sicherheitslücke berichten, gab es erste Erkenntnisse bereits lange vorher auf GitHub (einer Plattform zur gemeinsamen Bearbeitung von Quelltexten). Hier findet sich ein „Proof of concept“[4] aus März 2021. Der eigentliche Angriffsweg ist bereits seit 2016[5] bekannt, es fehlte lediglich die offene Tür, um diesen Angriff zu platzieren. Diese Tür ist mit Log4J gefunden worden.

Wie lässt sich Log4J erkennen?

Erkennbar wird ein Angriff in den Protokollen des Systems. Erfolgt der Angriff über einen Webdienst, sind im Protokoll entsprechende Einträge zu finden.

Erfolgt der Angriff gegen einen Webserver, sind in den Protokollen häufig manipulierte User-Agents aufgeführt. In vielen Berichten im Internet beginnen diese User-Agents mit „${jndi:ldap://….“[6].

Auch Analyse-Tools, die zur Ermittlung potenzieller Infektionen vorgesehen sind, suchen nach solchen Zeichenketten. Das Tool von datto.com sucht dabei nach „ldap“, „ldaps“ und „rmi“[7].

Allerdings sind Sicherheitsforscher bereits auf verschleierte Zeichenketten aufmerksam geworden[8], die eine Erkennung deutlich erschweren. Als Beispiele werden diese Zeichenketten genannt: „{jndi:${lower:l}${lower:d}a${lower:p}“ oder „${${::-j}${::-n}${::-d}${::-i}“

Auf Linux-Systemen könnten die Logfiles beispielsweise über die Kommandozeile analysiert werden[9]:
sudo find /var/log/ -type f -exec sh -c „cat {} | sed -e ’s/\${lower://’g | tr -d ‚}‘ | egrep -I -i ‚jndi:(ldap[s]?|rmi|dns):'“ \;

Schwieriger wird die Erkennung, wenn die eingesetzte Software keinen direkt auffindbaren Protokolldateien anlegt, jedoch trotzdem Log4J implementiert. In diesen Fällen wäre eine Software angreifbar, aber die Erkennung eines Angriffes wäre nahezu unmöglich.

Daher sollten die eingesetzten Systeme auch ohne Anzeichen einer Kompromittierung auf das Vorhandensein der verwundbaren Programmbibliotheken kontrolliert werden.

Manchmal ist es auf Anhieb nicht erkennbar, welche Programme Java im Hintergrund verwenden. Auch wenn eine Windows-Anwendungen genutzt wird, kann darin auch Java zum Einsatz kommen. Beispielsweise setzt die DATEV eG in ihren Produkten „JasperReports“ ein. Dieses Modul basiert ebenfalls auf Java und wird für diverse Exporte in den DATEV-Programmen genutzt. Die DATEV eG hat am 14.12.2021 einen Hotfix für diese Programmkomponente freigegeben[10].

Wie kann man sich schützen?

Aber der Version 2.10 von Log4J hilft es wohl, die Abfragen der externen Server in der Konfiguration zu deaktivieren („log4j2.formatMsgNoLookups=true“). Alternativ kann die entsprechende Java-Klasse aus Log4J entfernt werden[11] („zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class“).

Es gibt auf GitHub mittlerweile auch Hilfsprogramme, die diese Aufgabe auf den Systemen übernehmen. Beispielsweise liefert LOGPRESSO[12] ein entsprechendes Tool an.

Bei Appliances, also geschlossenen Hardwarekomponenten, deren Software man nicht beeinflussen kann, kann man sich nur an den Hersteller halten oder – wenn die Systeme frei im Netzwerk erreichbar sind – diese ggf. vorübergehen isolieren oder vom Netz nehmen.

Daher sollten zu allen eingesetzten Systemen und Anwendungen im Netzwerk entsprechende Informationen der Hersteller eingeholt werden und verfügbare Updates sollten umgehend installiert werden.

Was tun, wenn eine Kompromittierung erkannt wurde?

Wenn ein „indicator of compromise“ (IOC) vorhanden ist, sollte das betroffene System umgehend vom Netz genommen werden und eingehend analysiert werden. Sprechen andere Faktoren dafür, dass eine Infektion vorliegt, oder war es nur die Ermittlung potenziell angreifbarer Systeme? Faktoren, die für eine Infektion sprechen, können vielfältig sein. Neben offensichtlicher Schadsoftware, die hoffentlich von den Schutzsystemen erkannt und eliminiert wurde, können noch unbekannte Schadkomponenten auf dem System gespeichert worden sein. Schadsoftware, die über die Sicherheitslücke in Log4J verteilt wird, ist bereits gesichtet worden[13].

Aber auch erhöhte Netzwerkaktivitäten könnten ggf. auftreten. Sollte eine Infektion vorliegen, versuchen die Systeme in der Regel mit einem Command and Control-Server im Internet zu kommunizieren. Entsprechende Aktivitäten könnten am Gateway von der Firewall erkannt werden.

Kann eine Kompromittierung nicht ausgeschlossen werden, bleibt im Zweifel nur eine Rücksicherung der Systeme aus dem Backup oder eine komplette Neuinstallation.

Handlungsempfehlung für Ihre IT oder Ihren IT-Dienstleister

Stellen Sie fest, auf welchen Systemen und in welchen Anwendungen sich angreifbare Versionen von Log4J befinden.
Installieren Sie alle Programmupdates, die Ihnen die Softwarehersteller zur Verfügung stellen.
Aktualisieren Sie alle Server und Serverdienste, achten Sie auch auf Appliances, deren Programmfunktionen Sie nicht kennen.
Analysieren Sie die Protokolle Ihrer Systeme, ob bereits im Vorfeld eine Kompromittierung stattgefunden haben könnte.
Sofern entsprechende IOCs gefunden worden sind, sollten umgehende Maßnahmen zur Behebung eingeleitet werden.
Prüfen Sie, ob vorhandene Portfreigaben zur Veröffentlichung von Diensten im Internet tatsächlich notwendig sind und ob entsprechende Angriffsflächen mit Netzwerk- und Web-Application-Firewalls reduziert werden können.

Fazit

Aktuell ist es nicht überschaubar, welche Anwendungen und Systeme von der Schwachstelle betroffen sind. Auch haben sich noch nicht alle Hersteller abschließend dazu geäußert, ob die jeweiligen Produkte angreifbar sind.

Wir hoffen, wir konnten mit dieser Zusammenfassung bei der Erkennung und Absicherung der eigenen Systeme helfen.

[1] https://de.wikipedia.org/wiki/Apache_Tomcat

[2] https://de.wikipedia.org/wiki/JasperReports

[3] https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2021/211211_log4Shell_WarnstufeRot.html

[4] https://github.com/nice0e3/log4j_POC/releases/tag/log4j_POC

[5] https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

[6] https://api.heise.de/svc/embetty/tweet/1469258597930614787-images-0

[7] https://www.datto.com/blog/dattos-response-to-log4shell

[8] https://www.golem.de/news/log4j-luecke-warum-log4shell-so-gefaehrlich-ist-und-was-nicht-hilft-2112-161757-4.html

[9] https://medium.com/s2wlab/logs-of-log4shell-cve-2021-44228-log4j-is-ubiquitous-en-809064312039

[10] https://www.datev.de/web/de/service/software-auslieferung/datev-hotfixes/b0001429-01750/

[11] https://www.heise.de/news/Kritische-Zero-Day-Luecke-in-log4j-gefaehrdet-zahlreiche-Server-und-Apps-6291653.html