Log4Shell: Der Log4j-Schwachstellen-Notfall anschaulich erklärt

Seit dem 1. Dezember 2021 wird eine Schwachstelle, die mit der Open-Source-Logging-Bibliothek Apache Log4j 2 verknüpft ist, aktiv ausgenutzt, was sich auf unzählige digitale Produkte und Dienstleistungen weltweit auswirkt.

Um Ihnen zu helfen, sich schnell über dieses Ereignis, seine Auswirkungen und die Reaktion darauf zu informieren, haben wir die wichtigen Details von Log4Shell in diesem Beitrag zusammengefasst.

Eine Zusammenfassung der Log4Shell-Schwachstelle

Eine kritische Sicherheitslücke im Log4j-Framework besteht darin, dass Cyberkriminelle anfällige Systeme mit nur einer einzigen Injektion von bösartigem Code kompromittieren können.

Die Schwachstelle steht im Zusammenhang mit dem Benutzeraktivitätsprotokollierer Log4J - einer Protokollierungsbibliothek, die von der Apache Software Foundation kostenlos verteilt wird.

Java wird in einer Vielzahl von digitalen Produkten implementiert, darunter Cloud-Lösungen, Webserver und Apps, wodurch jedes dieser Produkte anfällig für die Ausnutzung durch die Log4Shell-Schwachstelle ist.

Da diese Sicherheitslücke so weit verbreitet ist und die meisten Unternehmen nicht wissen, dass sie davon betroffen sind, ist in der Welt der Cyberkriminellen derzeit ein Exploit-Rausch im Gange. Sicherheitsforscher haben stündlich etwa 10 Millionen Log4Shell-Exploit-Versuche identifiziert.

Der Einzelhandel leidet unter der höchsten Anzahl von Angriffen, gefolgt von Technologie, Finanzdienstleistungen und Fertigungsdienstleistungen.

Auch Gesundheitsdienstleister sind in höchster Alarmbereitschaft, da die Branche seit langem dafür bekannt ist, Cyberangriffen ausgesetzt zu sein.

Die folgende Karte zeigt die Regionen, in denen Log4Shell-Ausnutzungsversuche unternommen wurden, und die Dichte dieser Angriffe. Die Regionen mit den höchsten Zielländern sind die Vereinigten Staaten, das Vereinigte Königreich, Deutschland, die Türkei und die Niederlande.

So beheben Sie das Log4j-Problem

Die Aktualität dieser Schwachstelle, gepaart mit ihrem maximalen CVSS-Score von 10, bedeutet, dass es einige Zeit dauern wird, bis ein zuverlässiger Patch für diese Schwachstelle entwickelt wird.

In der Zwischenzeit sollten Reaktionsteams dieses Schutz- und Behebungsprotokoll befolgen, um die Sicherheitsanfälligkeit zu verwalten.

1. Update auf die neueste Version der Log4j Library

Die schnellste und derzeit effektivste Reaktion auf die Risikominderung besteht darin, alle Instanzen von Log4j auf die neueste Version zu aktualisieren - Log4j 2.17.1 (laden Sie die neueste Apache Log4j-Version hier herunter).

Laut Apache ist die Schwachstelle CVE-2021-45105 in der neuesten Bibliotheksversion behoben. Dies sollte zukünftige Angriffe verhindern, aber es wird keine Schäden beheben, die vor dem Bibliotheksupgrade verursacht wurden.

Da diese Schwachstelle so weit verbreitet ist, ist es am sichersten, davon auszugehen, dass Ihr Ökosystem vor einem Bibliotheks-Upgrade kompromittiert wurde, und sofort Reaktionen auf Datenschutzvorfälle einzuleiten.

Selbst Entitäten, die keine Apache-Protokolldienste verwenden, sollten von einer Datenschutzverletzung ausgehen, da sich die Auswirkungen dieses Zero-Day-Paars möglicherweise auf die gesamte Angriffsfläche auswirken können.

Erfahren Sie mehr über die Mentalität der Annahme von Datenschutzverletzungen.

Zusätzlich zu einer Mentalität der Annahme von Sicherheitsverletzungen sollten alle Serverprotokolle auf Indicators of Compromise (IOC) überprüft werden, wie in den folgenden Ressourcen beschrieben:

• GitHub-Ressource 1
• GitHub-Ressource 2
• GitHub-Ressource 3
• Greynoise-Ressource

UpGuard hat einen Domänen- und IP-Scanner entwickelt, der Entitäten, die von CVE-2021-44228 betroffen sind, schnell erkennt.

Der Scanner sendet eine Zeichenfolge in der URL einer HTTP GET-Anforderung an jede Domäne und IP-Adresse, die gescannt wird.

Anfällige Log4j-Bibliotheken werden bestätigt, wenn eine harmlose LDAP-Verbindung zu einem sicheren Server hergestellt wird.

Wenn alle ausgehenden Verbindungen blockiert sind, wird die Quelle fehlgeschlagener Verbindungsversuche mit dem sicheren LDAP-Server von UpGuard in Ihrem ausgehenden Proxy/Ihrer Firewall als anfällig für den Zero-Day-Angriff bestätigt.

Um den UpGuard Log4j Vulnerability Scanner in Aktion zu sehen, klicken Sie hier.

3. Java-Systemeigenschaften ändern

Wenn ein Upgrade auf die neueste Log4j-Version nicht möglich ist, sollten Sicherheitsteams für die Versionen 2.10 bis 2.14.1 sofort die folgende Reaktion implementieren:

Legen Sie entweder die folgende Systemeigenschaft auf true fest:

log4j2.formatMsgNoLookups

Oder setzen Sie die folgende Umgebungsvariable auf true:

LOG4J_FORMAT_MSG_NO_LOOKUPS

4. Deaktivieren Sie JNDI

Schuld an dieser kritischen Schwachstelle ist in erster Linie ein Designfehler im JNDI Lookup-Plugin. JNDI erleichtert die Codeausführung auf der Grundlage von Daten, die im Protokoll gefunden werden - Daten, die leicht manipuliert werden können, da sie vom Logger ohne Bereinigung akzeptiert werden.

Kürzlich wurde entdeckt, dass das JNDI-Lookup-Plugin seit seiner Veröffentlichung im Jahr 2013 immer das Senden von ungeparsten Informationen an die Log4j-Bibliothek ermöglicht hat.

Aus diesem Grund kann CVE-2021-44228 durch eine Single-String-Injection ausgenutzt werden.

Nach der Injektion betrachtet der Logger den in die Zeichenfolge eingebetteten Vorgang als Teil seiner ursprünglichen Codebasis und führt ihn sofort aus.

Durch das Deaktivieren der JndiLookup-Klasse kann die Protokollierung keine Aktionen basierend auf den im Protokoll gefundenen Daten ausführen. JNDI ist in Version 2.16.0 von Log4j standardmäßig deaktiviert

Anfällige Versionen von Log4j können auch gesichert werden, indem die JndiLookup-Klasse aus dem folgenden Klassenpfad entfernt wird:

zip -q -d log4j-core- *.jar org /apache/logging /log4j /core/lookup /JndiLookup.class

5. Senden Sie den Apache Log4j-Fragebogen an die Anbieter

Der Apache Log4j-Fragebogen von UpGuard hilft Sicherheitsteams, Drittanbieter zu entdecken, die Software oder Cloud-Dienste nutzen, die von der Log4j-Schwachstelle betroffen sind, entweder direkt oder über Lieferketten.

Um diesen Fragebogen in Aktion zu sehen, klicken Sie hier.

6. Aktualisieren Sie alle Firewalls und Intrusion Prevention-Systeme

Aktualisieren Sie alle Next-Generation-Firewalls, Web Application Firewalls und Intrusion Prevention-Systeme mit den neuesten Regeln und Signaturen. Die Patches könnten LDAP- und RMI-Datenverkehr filtern oder blockieren, der versucht, bösartige LDAP-Server zu erreichen.

7. Implementieren Sie die Multi-Faktor-Authentifizierung

Allgemeine Hygienepraktiken wie Multi-Faktor-Authentifizierung und strenge VPN-Richtlinien könnten den Erfolg von Datenschutzverletzungen behindern, wenn es einem Angreifer gelingt, über die Apache Log4j-Schwachstelle Netzwerkzugriff zu erhalten.

8. Verwenden Sie den Huntress Log4Shell Vulnerability Tester

Huntress hat ein Scan-Tool entwickelt, mit dem getestet werden kann, ob häufig protokollierte Prozesse oder Daten, die über APIs übergeben werden, von der Log4Shell-Schwachstelle betroffen sind. Der Quellcode kann hier von GitHub heruntergeladen werden.

Wenn Sie beide Scanner verwenden, haben Sie eine größere Chance, die Auswirkungen der Log4j-Schwachstelle auf die Grenzen zu entdecken.

Weitere Empfehlungen für Schutzmaßnahmen gegen diese Zero-Day-Bedrohung finden Sie in diesem Beitrag der Cybersecurity and Infrastructure Security Agency (CISA).

Was ist CVE-2021-44228?

Die ursprüngliche Apache Log4j-Schwachstelle (CVE-2021-44228), auch bekannt als Log4Shell, ist eine Cybersicherheitsschwachstelle in der Apache Log4j 2 Java-Bibliothek.

Bei dieser Sicherheitslücke handelt es sich um eine Remote Code Execution-Schwachstelle (Remote Code Execution, RCE) - eine der kritischsten Sicherheitslücken.

Da die ursprüngliche Log 4j-Schwachstelle mit CVSS 10 die kritischste Bedrohungseinstufung aufweist - eine Bewertung, die selten vergeben wird - ist es unwahrscheinlich, dass ein einziger Patch-Versuch alle Sicherheitsprobleme des Loggers löst, insbesondere wenn fast jeder Cyberkriminelle auf der Welt versucht, die Abwehr eines der größten Exploits des Internetzeitalters zu umgehen.

Es wurden vier Patches versucht, und bisher wurde festgestellt, dass zwei von ihnen Sicherheitslücken enthalten. Jeder neuen Schwachstelle wird eine separate CVE-Identität zugewiesen, die vom ursprünglichen Zero-Day-Exploit ausgeht.

Nachfolgend finden Sie eine aktuelle chronologische Liste von CVEs, die mit der Log4j-Schwachstelle verbunden sind:

• CVE-2021-44228 - dies ist die Tracking-Identität für den ursprünglichen Log4j-Exploit
• CVE-2021-45046 - die Tracking-Identität für die Schwachstelle, die mit dem ersten Log4j-Patch (Version 2.15.0) verbunden ist. Laut dem Sicherheitshinweis von Apache wurde festgestellt, dass Version 2.15.0 Denial-of-Service-Angriffe erleichtert, indem sie es Angreifern ermöglicht, bösartige Eingabedaten mithilfe eines JNDI-Lookup-Musters zu erstellen.
• CVE-2021-45105 - die Tracking-Identität für die Schwachstelle im Zusammenhang mit dem zweiten Log4j-Patch (Version 2.16.0), nachdem festgestellt wurde, dass sie Angreifern die Kontrolle über Thread-Kontextzuordnungsdaten ermöglicht, um einen Denial-of-Service-Angriff zu verursachen, wenn eine manipulierte Zeichenfolge interpretiert wird.
• CVE-2021-44832 - die Tracking-Identität für die Schwachstelle, die alle Versionen von Apache Log4j 2 (außer 2.32 und 2.12.4) betrifft. Diese Sicherheitslücke setzt alle anfälligen Versionen dem Risiko von Remote Code Injection (RCE) aus

Alle oben genannten Sicherheitsrisiken werden in der neuesten Log4J-Version - Version 2.17.1 - behoben (Version 2.17.1 hier herunterladen).

Weitere Informationen finden Sie in der vollständigen Offenlegung von Apache hier.

Wie funktioniert der Log4j-Cyberangriff?

Die Log4Shell-Schwachstelle ermöglicht es Hackern, beliebigen Code aus der Ferne in ein Zielnetzwerk einzuschleusen und die vollständige Kontrolle darüber zu übernehmen.

Um die Sequenz von Cyberangriffen zu verstehen, ist es wichtig, zunächst zu verstehen, wie Logger funktionieren.

Ohne eine Logger-Bibliothek wie Log4j werden Informationen von Servern sofort nach der Erfassung archiviert.

Wenn protokollierte Daten jedoch aktiv analysiert werden oder wenn bestimmte Aktionen als Reaktion auf bestimmte Protokolldaten erforderlich sind, können Java-Softwareentwickler eine Bibliothek wie Log4j verwenden, um Protokolle zu analysieren, bevor sie archiviert werden.

Jedes Unternehmen, das eine anfällige Log4j-Bibliothek verwendet, um Protokolldaten in seinen Backend-Systemen zu analysieren, ist anfällig für einen Log4j-Cyberangriff.

Diese Protokollierung ist in der Lage, Code basierend auf Eingaben auszuführen, und da die Schwachstelle es Angreifern ermöglicht, Eingabedaten zu manipulieren, könnte die Protokollierung gezwungen sein, bösartigen Code auszuführen.

Technisch gesehen ruft die anfällige Log4j-Bibliothek, wenn ihr eine speziell gestaltete Zeichenkette übergeben wird, einen LDAP-Server auf, lädt den im LDAP-Verzeichnis gehosteten Code herunter und führt diesen Code dann aus. Auf diese Weise können Cyberkriminelle einen bösartigen LDAP-Server erstellen, der Code speichert, der darauf ausgelegt ist, jeden Server zu übernehmen, auf dem er ausgeführt wird, und dann Anwendungen/Datenbanken/APIs die Zeichenfolge senden, die auf ihren Code verweist.

Warum ist Log4Shell so wichtig?

CVE-2021-44228 wird von vielen Sicherheitsexperten als eine der schlimmsten Gefährdungen in der Geschichte der digitalen Technologie angesehen.

Diese kühne Stimmung wird durch zwei Faktoren gestützt:

1. CVE-2021-44228 ist extrem einfach auszunutzen

Um die Schwachstelle auszunutzen, muss ein Bedrohungsakteur lediglich eine Zeichenfolge in ein allgemeines Protokollereignis einfügen, um dann eine bösartige Nutzlast einzuschleusen.

Dieser Prozess erfordert nur sehr wenig Geschick und seit der Entdeckung der Schwachstelle am 5. Dezember 2021 haben bereits viele Ausnutzungsversuche stattgefunden.

Um die Geschwindigkeit der Ausnutzung zu sehen, werfen Sie einen Blick auf den folgenden Proof-of-Concept, der einen Angriff auf einen Minecraft-Server demonstriert.

2. Jede Java-Software könnte betroffen sein

Da es sich bei Log4j um eine häufig verwendete Java-Protokollierungsbibliothek handelt, kann sich diese Schwachstelle möglicherweise auf alle Anwendungen und Software auswirken, die Java implementieren.

Es ist schwierig, die schiere Anzahl potenziell betroffener Systeme zu quantifizieren. Eine Schätzung von einigen Milliarden Fällen würde als konservativ angesehen werden.

Dies liegt daran, dass Java in viele digitale Produkte und Dienstleistungen eingebettet ist, darunter:

• Internet-Router
• Unternehmenssoftware
• Microsoft-, Amazon-, AWS- und Twitter-Server

Sogar Telefone sind potenziell verwundbar. Obwohl sie Java nicht direkt ausführen, kommunizieren ihre Backend-Systeme wahrscheinlich über APis mit der Log4j-Bibliothek. Ein bösartiger String, der an ein iPhone gesendet wird, könnte also in sein Backend injiziert werden, was zu einer Kompromittierung führt.

Software mit Apache Log4j-Sicherheitslücken muss nicht einmal direkt dem Internet ausgesetzt sein, um ausgenutzt zu werden.

Bösartige Zeichenfolgen können sogar in Backend-Software eindringen, auf der anfällige Apache Log4j-Versionen ausgeführt werden, selbst wenn die mit dem Internet verbundene Webanwendung nicht in Java codiert ist.

Selbst wenn keine Ihrer Webanwendungen und Backend-Software anfällige Log4j-Versionen ausführt, könnten dies bei Ihren Drittanbietern der Fall sein, was Ihr Ökosystem dann dem Potenzial von Sicherheitsverletzungen durch Dritte aussetzt.

Die enorme Vielfalt an Angriffsvektoren und die Einfachheit ihrer Kompromittierung führen zu einem Exploit-Wahnsinn unter Cyberkriminellen.

Laut der Sicherheitsfirma Check Point wurden in weniger als 24 Stunden über 60 Variationen des ursprünglichen Exploits entdeckt, was bedeutet, dass Cyberkriminelle ihre Exploit-Frameworks in Erwartung kommender Patches erweitern.

Wenn Malware in LDAP-Server eingeschleust wird, könnte die Schwachstelle CVE-2021-44228 zu einer Flutwelle von kolossalen Datenschutzverletzungen und Ransomware-Angriffen führen, die einige der größten Sicherheitsverletzungen, die wir bisher gesehen haben, in den Schatten stellen würde.

Es gibt zwei historische Sicherheitsverletzungen, die mit den potenziellen Auswirkungen der Apache Log4j-Schwachstelle verglichen werden können.

• Die Datenpanne bei Equifax wurde durch die Apache Struts-Schwachstelle CVE-2017-5638 erleichtert, von der 147 Millionen Menschen betroffen waren.
• ShellShock (bekannt als Bashdoor) ist eine Familie von Sicherheitsfehlern, die sich auf die Unix Bash Shell auswirken. Wenn ShellShock-Fehler ausgenutzt werden, können sie Angriffe ermöglichen, um Bash zur Ausführung bösartiger Befehle zu zwingen. Die ähnlichen Attribute zwischen Bashdoor und Log4Shell deuten darauf hin, dass die beiden Cyberrisiken Teil derselben Familie von Schwachstellen sein könnten.

Welche Versionen von Log4j 2 sind betroffen?

Alle Versionen von Log4j vor Version 2.17.0 sind potenziell vom Log4j-Exploit betroffen. Jede Entität, die Log 4j verwendet, muss sofort auf die neueste Apache-Bibliotheksversion - 2.17.1 - aktualisieren.

Log4j Version 2.17.1 kann hier heruntergeladen werden.

Log4j 1 wird nicht mehr unterstützt, so dass seine Schwachstellen mit zukünftigen Patch-Versionen nicht mehr behoben werden. Alle Endpunktinstanzen dieser Version sollten sofort auf Version 2.17.1 aktualisiert werden

Welche Produkte sind betroffen?

Die Top 10 der Anbieter, die von Log4Shell betroffen sind, sind unten aufgeführt. Jede aufgeführte Entität enthält Links zu einer Dokumentation, in der die Sicherheitsreaktionen des betroffenen Anbieters erläutert werden.

• Lehmziegel
• AWS (Englisch)
• CISCO
• IBM
• F-Secure
• Broadcom (Englisch)
• Fortinet
• FortiGuard
• Okta
• VMware (Englisch)

Eine vollständige Liste der Produkte und Cloud-Dienste, die von der Log4j-Schwachstelle betroffen sind, finden Sie in diesem Beitrag. Wenn Ihr Unternehmen eines dieser Produkte verwendet, stellen Sie sicher, dass Sie es sofort mit den neuesten Patches aktualisieren.

Selbst wenn keine dieser Lösungen intern verwendet wird, können Sie dennoch gefährdet sein. Wenn einer Ihrer Anbieter eine Lösung verwendet, die von der Log4Shell-Schwachstelle betroffen ist, könnte Ihr Unternehmen Opfer eines Supply-Chain-Angriffs werden.

Vendor Risk Management-Strategien helfen dabei, das Potenzial solcher Sicherheitsverletzungen von Drittanbietern durch Lösungen zur Überwachung der Angriffsfläche und Sicherheitsfragebögen zu bewerten, die sich speziell mit Cyberbedrohungen wie dem Zero-Day-Exploit von Log4Shell befassen.