Die Log4j-Sicherheitslücke oder „Log4Shell„ gilt als einer der katastrophalsten Softwarefehler aller Zeiten. Apache hat den Fehler im Dezember 2021 behoben, dennoch gibt er den Sicherheitsteams weiterhin Anlass zur Sorge. Tatsächlich gehört es immer noch zu den Die am häufigsten ausgenutzten Sicherheitslücken.

Log4Shell bleibt bestehen, da das betroffene Apache Log4j 2-Softwarepaket eine der weltweit am häufigsten verwendeten Protokollierungsbibliotheken ist. Demnach wird es voraussichtlich ein Jahrzehnt dauern, jede Instanz von Log4Shell zu finden und zu reparieren Ministerium für Innere Sicherheit.

In der Zwischenzeit können Sicherheitsteams einige Schritte unternehmen, um die Schadensbegrenzung und Behebung durch Log4Shell in ihren Netzwerken zu beschleunigen. 

Log4j-Schwachstellen verstehen  

Bevor wir uns mit der Erkennung und dem Patchen von Log4Shell befassen, ist es wichtig, die Art der Schwachstelle zu verstehen.

log4j ist ein Open-Source-Logger (verwaltet von der Apache Software Foundation), der Informationen und Ereignisse in einem Programm aufzeichnet. Log4j ist keine eigenständige Software, sondern ein Codepaket, das Entwickler in ihre eigenen Java-Apps integrieren können. Das Apache Log4j-Framework wird in einigen der größten Dienste 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 Schwachstellen auf. Das Gefährlichste davon ist Log4Shell (CVE-2021-44228; CVSS-Bewertung: 10), eine Remote Code Execution (RCE) Zero-Day-Schwachstelle gefunden in Log4j-Versionen 2.14.1 und früher. 

Log4Shell ist ein Ergebnis der Art und Weise, wie anfällige Versionen von Log4j mit dem Java Naming and Directory Interface (JNDI) umgehen API die Java-Apps verwenden, um auf Ressourcen zuzugreifen, die auf externen Servern gehostet werden. Bedrohungsakteure können nahezu die vollständige Kontrolle über anfällige Systeme erlangen, indem sie bösartige JNDI-Suchbefehle über Log4j senden. Diese Befehle verleiten die App dazu, beliebigen Code auszuführen, der fast alles kann: Daten stehleninstallieren Ransomware, Geräte offline schalten und mehr.

Log4Shell-Angriffe

Eine typische Log4Shell Cyberangriff funktioniert so: 

1. Ein Hacker richtet einen Server mithilfe eines gängigen Protokolls ein, beispielsweise Lightweight Directory Access Protocol (LDAP) oder Domain Name System (DNS). 
2. Der Hacker speichert Malware oder andere schädliche Nutzdaten auf dem Server.
3. Der Hacker sendet eine JNDI-Suche an eine App, auf der Log4j ausgeführt wird, und leitet die App an den Server des Hackers weiter. 
4. Durch die JNDI-Suche stellt die App eine Verbindung zum Server des Hackers her, lädt die schädliche Nutzlast herunter und führt den schädlichen Code aus. 

Verwandte Log4j-Schwachstellen und wie sie ausgenutzt werden

Während Apache daran arbeitete, Log4Shell zu patchen, identifizierten Sicherheitsforscher eine Handvoll damit zusammenhängender Schwachstellen in einigen Versionen von Log4j. Diese beinhalten: 

• CVE-2021-45046 ermöglicht es Hackern, böswillige JNDI-Lookups an Systeme zu senden, die bestimmte nicht standardmäßige Einstellungen verwenden, selbst wenn diese Systeme Log4Shell repariert haben. Vorhanden in Log4j-Versionen 2.15 und niedriger.  
• CVE-2021-45105 ermöglicht Hackern den Start Denial-of-Service-Angriffe durch das Senden bösartiger Nachrichten an Log4j. Vorhanden in Log4j-Versionen 2.16 und niedriger. 
• CVE-2021-44832 ist eine Sicherheitslücke bezüglich Remotecodeausführung. Dieser Fehler ist weniger kritisch als Log4Shell, da Hacker erhöhte Berechtigungen erhalten müssen, bevor sie ihn ausnutzen können. Vorhanden in Log4j-Versionen 2.17 und niedriger.  

So erkennen Sie Log4j-Schwachstellen   

Es kann schwierig sein, jede anfällige Instanz von Log4j in einem Netzwerk zu finden. Log4j erscheint in einer Schätzung Millionen von AppsDas bedeutet, dass Sicherheitsteams viele Vermögenswerte überprüfen müssen. 

Darüber hinaus ist Log4j häufig als indirekte Abhängigkeit vorhanden. Das bedeutet, dass es nicht direkt im Quellcode eines Assets enthalten ist, sondern als Abhängigkeit eines Softwarepakets oder einer Integration erscheint, auf die das Asset angewiesen ist. Google-Berichte dass die meisten anfälligen Log4j-Instanzen mehr als eine Ebene tief in der Abhängigkeitskette liegen, einige sogar bis zu neun Ebenen tief.

Allerdings können Sicherheitsteams Log4j-Schwachstellen mit den richtigen Taktiken und Tools erkennen.  

Was es zu sehen

Jede Version von Log4j 2 von 2.0-beta9 bis 2.17 ist anfällig für Log4Shell oder einen damit verbundenen Fehler. Anders ausgedrückt: Sicherheitsteams müssen jede Version von Log4j vor 2.17.1 finden und beheben.

Log4Shell und die damit verbundenen Fehler sind nur in „Log4j-core“-Dateien vorhanden, die die Kernfunktionalität von Log4j bereitstellen. In „Log4j-api“-Dateien, die die Schnittstelle zwischen Apps und Log4j-Loggern steuern, sind die Fehler nicht vorhanden.

Log4j kann in Vermögenswerten erscheinen, die das Unternehmen kontrolliert, in Vermögenswerten Dritter, die das Unternehmen nutzt (z. B. Cloud-Dienste), und in Vermögenswerten, die von Dienstanbietern mit Zugriff auf das Unternehmensnetzwerk verwendet werden. Während Log4j am wahrscheinlichsten in Java-basierten Apps erscheint, kann es durch Abhängigkeiten und Integrationen auch in Nicht-Java-Apps vorhanden sein.

In Java-Apps werden Bibliotheken wie Log4j oft in Java-Archivdateien oder „JAR-Dateien“ gepackt. JAR-Dateien können andere JAR-Dateien enthalten, die wiederum ihre eigenen JAR-Dateien usw. enthalten können. 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.

So finden Sie es 

Experten empfehlen die Verwendung einer Kombination verschiedener Techniken zum Auffinden von Log4j-Schwachstellen.

Manuelle Suche. Sicherheitsteams können manuell nach Log4j-Schwachstellen 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 Tools verwenden Bedrohungsanalyse um betroffene Vermögenswerte zu identifizieren. Beispielsweise hat die Cybersecurity and Infrastructure Security Agency (CISA) eine Liste von Software zusammengestellt, die bekanntermaßen unter Log4Shell leidet. Die Liste ist verfügbar auf GitHub.

Auf Linux-, Microsoft Windows- und macOS-Betriebssystemen können Sicherheitsteams mithilfe der Befehlszeilenschnittstelle Dateiverzeichnisse nach Instanzen von Log4j durchsuchen.

Tools zum Scannen von Sicherheitslücken. Nach der Entdeckung von Log4Shell haben einige Organisationen kostenlose Tools veröffentlicht, die darauf ausgelegt sind, Log4j-Schwachstellen zu finden. Beispiele beinhalten Palantirs Log4j-Sniffer und Der Scanner des CERT-Koordinierungszentrums, unter vielen anderen.

Zwar sind immer noch spezielle Scanner verfügbar, viele Standard-Sicherheitslösungen mögen jedoch Schwachstellenscanner, Angriffsflächenmanagement (ASM) Plattformen und Endpunkterkennung und Reaktion (EDR)-Lösungen können jetzt Log4j-Schwachstellen erkennen.

Da sich Log4Shell tief in Abhängigkeitsketten verstecken kann, können Sicherheitsteams automatisierte Scans durch praktischere Methoden ergänzen, z Penetrationstests.

Bedrohungsjagd. Laut CISAEs ist bekannt, dass Angreifer Log4Shell verwenden, um in ein Netzwerk einzudringen und dann die von ihnen kompromittierten Assets zu patchen, um ihre Spuren zu verwischen. Aus diesem Grund wird den Sicherheitsteams empfohlen, davon auszugehen, dass bereits ein Verstoß stattgefunden hat aktiv jagen auf Anzeichen einer Log4Shell-Ausnutzung.

Cybersicherheitstools wie Sicherheitsinformations- und Veranstaltungsmanagementt (SIEM)-Lösungen und erweiterte Erkennung und Reaktion (XDR)-Plattformen können dabei helfen, ungewöhnliche Aktivitäten im Zusammenhang mit Log4Shell zu erkennen, wie etwa seltsame Protokolleinträge oder verdächtige Verkehrsmuster. Sicherheitsteams sollten voll durchstarten Vorfallreaktion und Untersuchungsverfahren für jeden möglichen Hinweis auf Log4Shell, wenn man bedenkt, wie schwerwiegend die Folgen eines Angriffs sein können.

So beheben Sie Log4j-Schwachstellen

Sicherheitsteams haben bei der Behebung von Log4j-Schwachstellen mehrere Möglichkeiten.

Der beste Fall: Patchen anfälliger Systeme  

Um Log4Shell und damit verbundene Fehler vollständig zu beheben, müssen Unternehmen alle Instanzen von Log4j in ihren Netzwerken auf die neueste Version (oder zumindest auf Version 2.17.1) aktualisieren. Die neuesten Versionen von Log4j entfernen die Funktionen, die Angreifer ausnutzen können, und sie entfernen die Unterstützung für häufig missbrauchte Protokolle wie LDAP.

Es ist kein einziger, systemweiter Patch verfügbar und das Aktualisieren von Java selbst behebt das Problem nicht. Sicherheitsteams müssen jede Instanz von Log4j in jedem betroffenen Asset aktualisieren. 

Andere Schadensbegrenzungsmaßnahmen

Da sind sich Sicherheitsforscher einig Patching ist die ideale Lösung. Wenn ein Patchen nicht möglich ist, können Unternehmen andere Abhilfemaßnahmen ergreifen, um die Wahrscheinlichkeit eines Angriffs zu minimieren.

Nachrichtensuche in anfälligen Apps wird nicht zugelassen. Angreifer nutzen eine Funktion von Log4j namens „Message Lookup Substitutions“, um bösartige Befehle an anfällige Apps zu senden. Sicherheitsteams können diese Funktion manuell verbieten, indem sie die Systemeigenschaft „Log4j2.formatMsgNoLookups“ auf „true“ ändern oder den Wert der Umgebungsvariablen „LOG4J_FORMAT_MSG_NO_LOOKUPS“ auf „true“ setzen.  

Das Entfernen der Funktion zum Ersetzen der Nachrichtensuche erschwert zwar den Angriff von Angreifern, ist aber nicht narrensicher. Böswillige Akteure können CVE-2021-45046 weiterhin verwenden, um böswillige JNDI-Suchanfragen an Apps mit nicht standardmäßigen Einstellungen zu senden.

Entfernen der JNDIlookup-Klasse aus anfälligen Apps. In Log4j regelt die JNDIlookup-Klasse, wie der Logger JNDI-Lookups verarbeitet. Wenn diese Klasse aus dem Klassenverzeichnis von Log4j entfernt wird, können keine JNDI-Suchen mehr durchgeführt werden.

Apache stellt fest, 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

Obwohl diese Methode effektiver ist als das Verbieten von Nachrichtensuchen, hindert sie Angreifer nicht daran, andere Ausnutzungsversuche zu unternehmen, wie etwa Denial-of-Service-Angriffe durch rekursive Suchen auszulösen.

Blockieren potenziellen Log4Shell-Angriffsdatenverkehrs. Sicherheitsteams können verwenden Firewalls für Webanwendungen (WAFs), Systeme zur Erkennung und Verhinderung von Einbrüchen (IDPS), EDRs und andere Cybersicherheitstools, um den Datenverkehr zu und von von Angreifern kontrollierten Servern abzufangen, indem häufig verwendete Protokolle wie LDAP oder RMI blockiert werden. Auch Sicherheitsteams können blockieren Mit Angriffen verbundene IP-Adressen oder die Zeichenfolgen, die Angreifer häufig in böswilligen Anfragen verwenden, wie „jndi“, „ldap“ und „rmi“.

Allerdings können Angreifer diese Abwehrmaßnahmen umgehen, indem sie neue Protokolle und IP-Adressen verwenden oder bösartige Zeichenfolgen verschleiern.

Quarantäne betroffener Vermögenswerte. 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, besteht darin, anfällige Vermögenswerte in einem isolierten Netzwerksegment zu platzieren, auf das nicht direkt über das Internet zugegriffen werden kann. Für zusätzlichen Schutz kann eine WAF um dieses Netzwerksegment herum platziert werden.

Log4Shell in Schach halten

Eines der kniffligen Dinge bei der Behebung von Log4Shell ist, dass es nicht immer gepatcht bleibt. Im November 2022, Tenable berichtete dass 29 % der Assets, die immer noch für Log4Shell anfällig sind, „Wiederholungen“ waren, was bedeutet, dass sie gepatcht wurden, der Fehler jedoch erneut auftrat. Es kommt zu Wiederholungen, wenn Entwickler versehentlich Softwarebibliotheken verwenden, die ungepatchte 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 mehrere Ebenen tief in JAR-Dateien liegen.

Formal umsetzen Schwachstellenmanagement und Patch-Management Programme können Sicherheitsteams eine effektivere Möglichkeit bieten, Assets auf das Wiederauftreten von Log4j-Schwachstellen zu überwachen. Regelmäßige Schwachstellenscans und Penetrationstests können dabei helfen, schnell neue Schwachstellen zu erkennen, ob Log4Shell oder auf andere Weise. Durch das Patch-Management wird sichergestellt, dass neue Schwachstellen geschlossen werden, sobald die Anbieter Korrekturen veröffentlichen.   

Weitere Hilfe bei der Bekämpfung von Log4Shell und anderen Zero-Day-Schwachstellen

Hacker nutzen zunehmend automatisierte Tools, um Zero-Day-Schwachstellen wie Log4Shell problemlos auszunutzen – und eine Flut von Ransomware-Angriffen und anderen Cyberbedrohungen zu starten. Sicherheitsteams, die mit herkömmlichen Ansätzen zur Endpunktsicherheit arbeiten, sind mit Alarmmüdigkeit, komplexen Tools und langwierigen Untersuchungen konfrontiert – und haben Schwierigkeiten, Schritt zu halten.

IBM Security® QRadar® EDR, ehemals ReaQta, bekämpft bekannte und unbekannte Endpunktbedrohungen nahezu in Echtzeit mit benutzerfreundlicher intelligenter Automatisierung, die kaum oder gar keine menschliche Interaktion erfordert. Mit QRadar EDR können Analysten schnelle, fundierte Entscheidungen treffen und sich mithilfe der automatisierten Alarmverwaltung auf die Bedrohungen konzentrieren, die am wichtigsten sind. Fortschrittliche KI-Funktionen für kontinuierliches Lernen und eine benutzerfreundliche Oberfläche geben dem Sicherheitspersonal wieder die Kontrolle und helfen, die Geschäftskontinuität zu gewährleisten.

Entdecken Sie IBM Security QRadar EDR