Die Log4j-Schwachstelle oder „Log4Shell“ gilt als einer der katastrophalsten Softwarefehler aller Zeiten. Apache hat die Schwachstelle im Dezember 2021 gepatcht, dennoch bleibt sie ein Problem für Sicherheitsteams. In der Tat gehört sie immer noch zu den am häufigsten ausgenutzten Sicherheitslücken.
Log4Shell bleibt bestehen, weil das Apache Log4j 2-Softwarepaket, das es betrifft, eine der weltweit am häufigsten verwendeten Protokollierungsbibliotheken ist. Nach Angaben des US Department of Homeland Security (das US-amerikanische Heimatschutzministerium) wird es voraussichtlich ein Jahrzehnt dauern, bis jede einzelne Log4Shell-Instanz gefunden und behoben ist.
In der Zwischenzeit können Sicherheitsteams einige Maßnahmen ergreifen, um die Schadensbegrenzung und Sanierung von Log4Shell in ihren Netzwerken zu beschleunigen.
Schließen Sie sich Führungskräften im Bereich Sicherheit an, die von den kuratierten Nachrichten zu KI, Cybersicherheit, Daten und Automatisierung im Think Newsletter profitieren. Lernen Sie schnell von Experten-Tutorials und Erläuterungen, die direkt in Ihren Posteingang geliefert werden. Weitere Informationen finden Sie in der IBM Datenschutzerklärung.
Bevor wir uns mit der Erkennung und dem Patchen von Log4Shell befassen, sollten wir die Art der jeweiligen Schwachstelle verstehen.
Log4j ist ein Open-Source-Logger (von der Apache Software Foundation verwaltet), der Informationen und Ereignisse in einem Programm aufzeichnet. Log4j ist keine eigenständige Software, sondern ein Codepaket, das Entwickler in ihre eigenen Java-Apps einfügen können. Das Apache Log4j-Framework wird in einigen der größten Services im Web verwendet, von Netzwerkinfrastrukturen wie Amazon Web Services (AWS) und Cisco-Lösungen bis hin zu beliebten Apps wie Twitter und Minecraft.
Einige Versionen von Log4j – insbesondere Log4j 2.17.0 und niedriger – weisen schwerwiegende Sicherheitslücken auf. Die gefährlichste davon ist Log4Shell (CVE-2021-44228; CVSS-Bewertung: 10), eine Zero-Day-Schwachstelle in Bezug auf Remote-Code-Ausführung (RCE), die in den Log4j-Versionen 2.14.1 und früheren Versionen gefunden wurde.
Log4Shell ist eine Folge der Art und Weise, wie verwundbare Versionen von Log4j mit dem Java Naming and Directory Interface (JNDI) umgehen, einer API, die Java-Apps für den Zugriff auf Ressourcen auf externen Servern verwenden. Bedrohungsakteure können fast die gesamte Kontrolle über anfällige Systeme übernehmen, indem sie bösartige JNDI-Lookup-Befehle über Log4j senden. Diese Befehle bringen die App dazu, beliebigen Code auszuführen, der fast alles tun kann: Daten stehlen, Ransomware installieren, Geräte offline schalten und mehr.
Ein typischer Log4Shell-Cyberangriff funktioniert so:
Während Apache an Patches für Log4Shell arbeitete, identifizierten Sicherheitsforscher eine Handvoll damit verbundener Schwachstellen in einigen Versionen von Log4j. Dazu gehören:
Es kann schwierig sein, jede anfällige Instanz von Log4j in einem Netzwerk zu finden. Log4j kommt in schätzungsweise Millionen von Apps vor, was bedeutet, dass Sicherheitsteams eine Vielzahl von Assets überprüfen müssen.
Darüber hinaus ist Log4j häufig als indirekte Abhängigkeit vorhanden. Das bedeutet, dass sie nicht direkt im Quellcode eines Assets enthalten ist, sondern als Abhängigkeit von einem Softwarepaket oder einer Integration erscheint, auf die das Asset angewiesen ist. Google berichtet, dass die meisten anfälligen Log4j-Instanzen mehr als eine Ebene tief in der Kette der Abhängigkeiten liegen – in manchen Fällen sogar neun Ebenen.
Dennoch können Sicherheitsteams Log4j-Schwachstellen mit den richtigen Taktiken und Tools erkennen.
Jede Version von Log4j 2 von 2.0-Beta9 bis 2.17 ist anfällig für Log4Shell oder einen verwandten Fehler. Anders ausgedrückt: Sicherheitsteams müssen jede Version von Log4j vor 2.17.1 finden und beheben.
Log4Shell und die damit verbundenen Mängel sind nur in „Log4j-Core“-Dateien vorhanden, die Kernfunktionalität von Log4j bereitstellen. Die Fehler sind in den „Log4j-api“-Dateien, die Schnittstelle zwischen Apps und Log4j-Loggern steuern, nicht vorhanden.
Log4j kann in Assets erscheinen, die das Unternehmen kontrolliert, in Assets Dritter, die das Unternehmen nutzt (z. B. Cloud-Services), und in Assets, die von Dienstanbietern mit Zugang zum Unternehmensnetzwerk verwendet werden. Während Log4j am ehesten in Java-basierten Apps auftauchen wird, kann es über Abhängigkeiten und Integrationen auch in Nicht-Java-Apps vorhanden sein.
In Java-Apps werden Bibliotheken wie Log4j häufig in Java-Archivdateien oder „JAR-Dateien“ gepackt. JAR-Dateien können andere JAR-Dateien enthalten, die wiederum ihre eigenen JAR-Dateien enthalten können, und so weiter. Um alle anfälligen Versionen von Log4j zu finden, müssen Sicherheitsteams alle Ebenen von JAR-Dateien untersuchen, nicht nur die Dateien der obersten Ebene.
Experten empfehlen die Verwendung einer Kombination von Techniken zur Suche nach Log4j-Schwachstellen.
Manuelle Suche. Sicherheitsteams können manuell nach Log4j-Fehlern suchen. Sie können Entwicklungstools wie Apache Maven verwenden, um Abhängigkeitsbäume zu generieren, die alle Abhängigkeiten in einer App abbilden, oder sie können externe Threat-Intelligence verwenden, um betroffene Assets zu identifizieren. Die Cybersecurity and Infrastructure Security Agency (CISA) hat zum Beispiel eine Liste von Software zusammengestellt, die bekanntermaßen von Log4Shell betroffen ist. Die Liste ist auf GitHub verfügbar.
Auf Linux-, Microsoft Windows- und macOS-Betriebssystemen können Sicherheitsteams über die Befehlszeilenschnittstelle Dateiverzeichnisse nach Instanzen von Log4j durchsuchen.
Tools zum Scannen von Schwachstellen. Nach der Entdeckung von Log4Shell haben einige Unternehmen kostenlose Tools veröffentlicht, die Log4j-Schwachstellen finden. Beispiele hierfür sind unter anderem der Log4j-Sniffer von Palantir und der Scanner des CERT Coordination Center.
Spezialisierte Scanner sind zwar weiterhin verfügbar, aber viele Standardsicherheitslösungen wie Schwachstellenscanner, Angriffsfläche Management (ASM) Plattformen und Endpoint Detection and Response (EDR) Lösungen können jetzt Log4j-Schwachstellen erkennen.
Da Log4Shell sich tief in Abhängigkeitsketten verstecken kann, können Sicherheitsteams automatische Scans durch praktischere Methoden wie Penetrationstests ergänzen.
Threat Hunting. Nach Angaben von CISA ist bekannt, dass Angreifer mit Log4Shell in ein Netzwerk eindringen und dann das kompromittierte Asset patchen, um ihre Spuren zu verwischen. Aus diesem Grund wird empfohlen, dass Sicherheitsteams davon ausgehen, dass eine Sicherheitsverletzung bereits stattgefunden hat, und aktiv nach Anzeichen einer Log4Shell-Ausbeutung suchen.
Cybersicherheits-Tools wie SIEM-Lösungen (Security Information and Event Management) und XDR-Plattformen (Extended Detection and Response) können dabei helfen, abnormale Aktivitäten im Zusammenhang mit Log4Shell zu erkennen, z. B. seltsame Protokolleinträge oder verdächtige Datenverkehrsmuster. Sicherheitsteams sollten bei jedem möglichen Hinweis auf Log4Shell umfassende Vorfallreaktions- und Ermittlungsverfahren einleiten, da die Folgen eines Angriffs sehr schwerwiegend sein können.
Sicherheitsteams haben einige Möglichkeiten, um Log4j-Schwachstellen zu beheben.
Um die vollständige Sanierung von Log4Shell und damit verbundene Schwachstellen zu erreichen, müssen Unternehmen alle Instanzen von Log4j in ihren Netzwerken auf die neueste Version (oder mindestens auf Version 2.17.1) aktualisieren. Die neuesten Versionen von Log4j entfernen die Funktionen, die Angreifer ausnutzen können, und die Unterstützung für häufig missbrauchte Protokolle wie LDAP.
Es gibt keinen einzelnen, systemweiten Patch, und das Update von Java selbst behebt das Problem nicht. Sicherheitsteams müssen jede Instanz von Log4j in jedem betroffenen Asset aktualisieren.
Sicherheitsforscher sind sich einig, dass Patching die ideale Lösung ist. Wenn ein Patching nicht durchführbar ist, können Unternehmen andere Maßnahmen zur Schadensbegrenzung nutzen, um die Wahrscheinlichkeit eines Angriffs zu minimieren.
Verbieten von Nachrichten-Lookups aus anfälligen Apps. Angreifer nutzen eine Funktion von Log4j namens „Nachrichten-Lookup-Ersetzungen“, um bösartige Befehle an anfällige Apps zu senden. Sicherheitsteams können diese Funktion manuell ausschalten, indem sie die Systemeigenschaft „Log4j2.formatMsgNoLookups“ auf „true“ setzen oder den Wert der Umgebungsvariablen „LOG4J_FORMAT_MSG_NO_LOOKUPS“ auf „true“ setzen.
Das Entfernen der Substitutionsfunktion für das Nachschlagen von Nachrichten erschwert Angreifern zwar den Angriff, ist aber nicht narrensicher. Böswillige Akteure können CVE-2021-45046 weiterhin verwenden, um böswillige JNDI-Lookups an Anwendungen mit nicht standardmäßigen Einstellungen zu senden.
Entfernen der JndiLookup-Klasse aus anfälligen AppsIn Log4j regelt die Klasse JNDIlookup, wie der Logger JNDI-Lookups verarbeitet. Wenn diese Klasse aus dem Klassenverzeichnis von Log4j entfernt wird, können keine JNDI-Lookups mehr durchgeführt werden.
Apache weist darauf hin, dass der folgende Befehl verwendet werden kann, um die JNDIlookup-Klasse aus anfälligen Apps zu entfernen:
zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class
Diese Methode ist zwar effektiver als das Verbieten von Nachrichten-Lookups, hindert Angreifer jedoch nicht daran, andere Ausbeutungsversuche zu starten, z. B. Denial-of-Service-Angriffe durch rekursive Lookups auszulösen.
Blockieren potenziellen Log4Shell-Angriffsdatenverkehrs. Sicherheitsteams können Web Application Firewalls (WAFs), Intrusion Detection and Prevention Systems (IDPS), EDRs und andere Cybersicherheitstools verwenden, um den Datenverkehr zu und von Angreifern kontrollierten Servern abzufangen, indem sie häufig verwendete Protokolle wie LDAP oder RMI blockieren. Sicherheitsteams können auch IP-Adressen blockieren, die mit Angriffen in Verbindung stehen, oder die Zeichenfolgen, die Angreifer häufig in bösartigen Anfragen verwenden, wie z. B. „jndi“, „ldap“ und „rmi“.
Angreifer können diese Abwehrmaßnahmen jedoch umgehen, indem sie neue Protokolle und IP-Adressen verwenden oder bösartige Zeichenfolgen verschleiern.
Quarantäne der betroffenen Assets. Wenn alles andere fehlschlägt, können Sicherheitsteams betroffene Assets unter Quarantäne stellen, während sie auf einen Patch warten. Eine Möglichkeit, dies zu erreichen, ist die Platzierung anfälliger Assets in einem isolierten Netzwerksegment, auf das nicht direkt über das Internet zugegriffen werden kann. Für zusätzlichen Schutz kann eine WAF um dieses Netzwerksegment herum platziert werden.
Eines der schwierigen Dinge bei der Sanierung von Log4Shell ist, dass es nicht immer gepatcht bleibt. Im November 2022 berichteteTenable , dass 29 % der Assets, die weiterhin für Log4Shell anfällig waren, „Wiederholungen“ waren, d. h. sie wurden gepatcht, doch die Schwachstelle trat erneut auf. Wiederholungen treten auf, wenn Entwickler versehentlich Softwarebibliotheken verwenden, die nicht gepatchte Versionen von Log4j enthalten, um Apps zu erstellen oder zu aktualisieren.
Während Entwickler die von ihnen verwendeten Frameworks genauer unter die Lupe nehmen können, ist es leicht, anfällige Versionen von Log4j zu übersehen, wenn sie sich mehrere Ebenen in den JAR-Dateien befinden.
Die Implementierung formaler Schwachstellenmanagement- und Patch-Management-Programme kann Sicherheitsteams eine effektivere Möglichkeit bieten, Assets auf das Wiederauftreten von Log4j-Schwachstellen zu überwachen. Regelmäßige Schwachstellen-Scans und Penetrationsprüfungen können helfen, neue Sicherheitslücken, Log4Shell oder andere, schnell zu erkennen. Patch-Management stellt sicher, dass neue Schwachstellen geschlossen werden, sobald Anbieter Fixes veröffentlichen.