Die Log4j-Schwachstelle und ihre Auswirkungen auf die Software-Lieferkettensicherheit

Anmerkung der Redaktion (28. Dez. 2021, 19:35 Uhr GMT): Das Log4j-Team hat ein neues Sicherheitsupdate veröffentlicht. Dabei wurde festgestellt, dass Version 2.17.0 für die Ausführung von Remotecode anfällig ist. Die Schwachstelle wurde als CVE-2021-44832 identifiziert. Wir empfehlen, auf die neueste Version zu aktualisieren, die derzeit 2.17.1 ist. Weitere Informationen finden Sie hier.

Anmerkung der Redaktion (18. Dez. 2021, 18:55 Uhr GMT): Die Lage rund um Log4j verändert sich rasant, und wir aktualisieren unsere Blogs, sobald neue Informationen verfügbar sind. Es wird empfohlen, auf Version 2.17.1 oder höher zu aktualisieren. Diese Version enthält Sicherheitskorrekturen für zwei Schwachstellen zur Ausführung von Remotecode, die in 2.15.0 (CVE-2021-44228) und 2.16.0 (CVE-2021-45046) behoben wurden, sowie für die neueste DoS-Schwachstelle, die in 2.17.1 behoben wurde (CVE-2021-45105). Weitere Informationen finden Sie hier.

Sie wissen inzwischen wahrscheinlich bereits von der Schwachstelle, die als Log4Shell bekannt geworden ist und als CVE-2021-44228 identifiziert wurde – und arbeiten vermutlich schon an ihrer Behebung. Dabei handelt es sich um die Schwachstelle, die Sicherheitsforscher am Freitag, dem 10. Dezember 2021, für das Log4j-Logging-Framework von Apache offengelegt haben.

In diesem Artikel erfahren Sie mehr über einige wichtige Fakten zu Log4j und darüber, wie Sie sich und Ihr Unternehmen schützen können:

• Log4j ist eine kritische Schwachstelle, die sofortiges Handeln erfordert

• Log4j ist weit verbreitet und wird enorme Auswirkungen haben

• Log4j hat erhebliche Auswirkungen auf die Lieferkettensicherheit und lässt sich nur schwer beheben

• Es ist entscheidend, die Behebung der Log4j-Schwachstelle in einem ohnehin schon überfüllten Security-Backlog zu priorisieren

• Die schnelle Reaktion auf kritische Probleme wie Log4j ist entscheidend für das Unternehmen

Log4j ist eine kritische Schwachstelle, die sofortiges Handeln erfordert

Wir können gar nicht genug betonen, wie wichtig diese Log4j-Schwachstelle ist. Es handelt sich um eine kritische Sicherheitslücke mit einem CVSS-Wert von 10 (dem höchstmöglichen Wert), über die Angreifer in jeder anfälligen Umgebung aus der Ferne Code ausführen können. Das ist äußerst schwerwiegend und muss dringend behoben werden.

Lesen Sie die folgenden Abschnitte, um zu erfahren, welche Sofortmaßnahmen Sie ergreifen sollten, abhängig davon, welche Log4j-Versionen Sie derzeit in Ihren Anwendungen verwenden.

Ich verwende Log4j v1. Was sollte ich tun?

Das Risiko ist hier im Vergleich zur Schwachstelle in Version 2.x deutlich geringer. Unter sehr spezifischen Umständen ermöglicht Log4j v1 jedoch Lookups, ähnlich wie bei Log4j 2, die keinen Schutz vor LDAP oder anderen über JNDI aufgelösten Endpunkten bieten. Diese Angriffsvektoren (und möglicherweise weitere) können zu Angriffen mit Remotecodeausführung (RCE) führen. Wenn Sie eine Version von Log4j v1 verwenden, in der JMSAppender aktiviert ist, besteht möglicherweise eine Anfälligkeit. Wichtig ist, dass JMSAppender standardmäßig deaktiviert ist und daher in den meisten Anwendungen, die Log4j v1 verwenden, wahrscheinlich nicht aktiviert ist.

Dies ist ein kritisches, kürzlich veröffentlichtes Update, das erst am 13. Dezember 2021 gegen 17:00 Uhr UTC bereitgestellt wurde. Snyk erfasst es unter der Schwachstellen-ID SNYK-JAVA-LOG4J-2316893.

Daher empfehlen wir Ihnen, wenn möglich auf die neueste Version von Log4j v2 zu aktualisieren, die die kürzlich veröffentlichte Schwachstellenkorrektur enthält. Beachten Sie dazu bitte das offizielle Dokument von Apache zur Migration von Log4j v1. Wenn Sie kein Upgrade durchführen können, sollten Sie JMSAppender deaktivieren oder verhindern, dass Benutzereingaben dessen Konfiguration erreichen.

Ich verwende Log4j v2. Was sollte ich tun?

Wenn Sie Log4j Version 2.x verwenden, sollten Sie auf die neueste Log4j-v2-Version (derzeit 2.16.0) aktualisieren, in der die Schwachstelle behoben ist.

Ich verwende Log4j v1 oder v2, kann aber nicht schnell aktualisieren. Gibt es eine sofortige Übergangslösung?

Wenn ein Upgrade in naher Zukunft nicht möglich ist, lesen Sie bitte unseren Log4j-Artikel. Darin erfahren Sie, wie Sie die Schwachstelle durch das Festlegen von Systemeigenschaften und Java-Parametern beheben können.

Log4j ist weit verbreitet und wird enorme Auswirkungen haben

Logging ist allgegenwärtig

Bei der Entwicklung von Anwendungen protokollieren Entwicklerinnen und Entwickler fast immer Daten, um Informationen für Debugging, Analysen und Audits zu erfassen. Logs sind nicht nur für die tägliche Entwicklungsarbeit nützlich: Viele Security-Teams verlangen ebenfalls Logging, um Audit-Trails bereitzustellen. Anhand dieser lassen sich potenziell verdächtige Aktivitäten verfolgen und miteinander in Verbindung bringen.

Logging ist eine unverzichtbare Entwicklungspraxis

Dass Logging so allgegenwärtig ist und die Log4j-Schwachstelle durch das Protokollieren von Benutzereingaben ausgelöst werden kann, erhöht die Schwere des Angriffs erheblich und erweitert die potenziellen Angriffsvektoren. In sozialen Medien wurde beispielsweise öffentlich berichtet, dass Nutzerinnen und Nutzer damit begonnen haben, Log4j-Exploit-Payloads als E-Mail-Adressen und Benutzernamen in Webformularen zu verwenden.

Auch wenn wir die vollständigen Auswirkungen der Log4j-Schwachstelle erst in einiger Zeit kennen werden, gab es seit ihrer Veröffentlichung bereits Berichte über Hunderte von Versuchen, die Schwachstelle in freier Wildbahn auszunutzen – sowohl durch offenbar opportunistische Angriffe als auch durch ausgefeiltere Botnetze.

Die Log4j-Open-Source-Bibliothek ist weit verbreitet

Angesichts der großen Aufmerksamkeit für diese Schwachstelle ist es kaum überraschend, dass Log4j bei Anbietern, Open-Source-Projekten, Frameworks und wichtigen Projekten großer Stiftungen umfassend zum Einsatz kommt.

Neben den Millionen Java-Anwendungen, die Log4j verwenden, nutzen auch viele Projekte der Apache Software Foundation selbst Log4j, darunter Apache Solr, Apache Struts2, Apache Kafka, Apache Druid, Apache Flink, Apache Swift und weitere.

Auch viele andere beliebte Projekte verwenden die Bibliothek, darunter Redis, Elasticsearch, Spring Framework und Netty.

Sogar das Reverse-Engineering-Tool Ghidra der National Security Agency (NSA), das als Open-Source-Projekt veröffentlicht wurde, erwies sich als anfällig für diese Log4j-Schwachstelle.

Auch Anbieter insgesamt waren stark von dieser Schwachstelle betroffen. Dazu gehören auch eigene Dienste von AWS wie AWS CloudHSM und Amazon OpenSearch sowie möglicherweise weitere Serviceprodukte. Betroffen sind außerdem Red-Hat-Produkte wie Red Hat JBoss Fuse 7, Red Hat CodeReady Studio 12 und Red Hat OpenShift Logging. Wie Sie sich vorstellen können, sind auch viele andere Anbieter wie VMware, Cisco und weitere stark betroffen.

Auch bei der eigenen Nutzerbasis von Snyk haben wir erhebliche Auswirkungen festgestellt. Etwa ein Drittel der Snyk-Kunden ist von der Log4j-Schwachstelle betroffen. Das entspricht Zehntausenden Schwachstellen, die wir in Projekten erkannt haben, die in Snyk importiert oder dort überwacht werden.

Die Krise rund um die Log4j-Java-Bibliothek eines Drittanbieters unterstreicht, wie wichtig es ist, die Software-Stückliste (SBOM) im gesamten Unternehmen nachzuverfolgen und ein Tool zur Software Composition Analysis einzusetzen, mit dem Entwicklungs- und Security-Teams schnell reagieren können.

Log4j hat erhebliche Auswirkungen auf die Lieferkettensicherheit und lässt sich nur schwer beheben

Anhand unserer Daten zu den von Snyk importierten, überwachten und gescannten Projekten konnten wir fundierte Einblicke in die Nutzungsmuster der Log4j-Bibliothek in verschiedenen Projekten gewinnen.

Bisher haben wir festgestellt, dass 60 % der Java-Projekte, die wir bei Snyk überwachen und die die Log4j-Bibliothek verwenden, diese als indirekte Abhängigkeit einbinden. Indirekte Abhängigkeiten sind solche, die ein Projekt nicht direkt, sondern mittelbar verwendet. Das heißt: Eine Abhängigkeit Ihres Projekts verwendet Log4j, wodurch Sie anfällig werden, obwohl Sie Log4j nicht selbst einsetzen. Eine einfache Suche danach, ob Sie eine anfällige Log4j-Version verwenden, findet daher möglicherweise nicht alle Vorkommen der Bibliothek in Ihren Projekten. Sie benötigen ein Tool für Software Composition Analysis (SCA) wie Snyk, das einen tief verschachtelten Abhängigkeitsgraphen rekursiv durchsuchen und Versionen mit einer Schwachstellendatenbank abgleichen kann, um Risiken für die Lieferkettensicherheit zu ermitteln.

Tatsächlich haben wir im Bericht „State of Open Source Security 2020“ von Snyk erfahren – und bestätigt –, dass die meisten Schwachstellen im Java-, Ruby- und JavaScript-Ökosystem auf indirekte Abhängigkeiten zurückzuführen sind:

Das ist einer von vielen Gründen, warum Sie als Entwickler Sicherheitswerkzeuge wie Snyk verwenden sollten, um Schwachstellen in Ihren Projekten zu erkennen (zum Beispiel log4j): Es reicht nicht aus, lediglich zu wissen, ob Sie eine anfällige Abhängigkeit verwenden. Sie müssen auch rekursiv prüfen, ob Ihre Abhängigkeiten selbst anfällig sind.

All das zeigt, wie kompliziert die Behebung der neuen Log4j-Schwachstelle sein wird: Viele Open-Source-Bibliotheken müssen aktualisiert werden, damit Projekte, die von ihnen abhängen, nicht länger anfällig sind. Das wird einige Zeit in Anspruch nehmen.

Die Log4j-Schwachstelle stellt eine unmittelbare globale Bedrohung dar. Ähnlich wie bei der COVID-19-Pandemie, die weltweite Gesundheitsorganisationen und Unternehmen aus der medizinischen Forschung zur Zusammenarbeit gezwungen hat, erleben wir derzeit eine dringend notwendige Kooperation. Sie ist erforderlich, um das Gesamtrisiko durch die Log4j-Schwachstelle zu bewältigen und eine ganzheitliche Lösung für die Community bereitzustellen.

Es ist entscheidend, die Behebung der Log4j-Schwachstelle in einem ohnehin schon überfüllten Security-Backlog zu priorisieren

Für viele ist die Log4j-Schwachstelle ein weiteres dringendes Sicherheitsproblem, das in einem ohnehin schon überfüllten Backlog ausstehender Sicherheitsaufgaben behoben werden muss.

Angesichts zunehmender Sicherheitsschwachstellen in verschiedenen Sprachökosystemen, Fehlkonfigurationen, Open-Source-Komponenten von Betriebssystemen und weiterer Bedenken rund um die Anwendungssicherheit stellt sich die Frage: Wo sollten Security-Teams anfangen? Welche Schwachstelle ist am wichtigsten und dringendsten, wenn die Teams ohnehin schon unterbesetzt sind?

Priorisierung ist nicht nur ein entscheidender Faktor für die effektive Arbeit von Security-Teams, sondern auch ein wichtiges Mittel, um das Geschäftsrisiko insgesamt zu senken. Damit Security-Teams effektiv arbeiten können, müssen sie die Risiken von Sicherheitslücken verstehen – nicht nur für ein einzelnes Projekt, sondern mit einem ganzheitlichen Blick auf das gesamte Unternehmen.

Damit Entwicklungs- und Security-Teams schnell reagieren und Sicherheitsrisiken aus der Perspektive des gesamten Unternehmens bewerten können, haben wir in Snyk das Konzept der Prioritätswerte eingeführt.

Herkömmliche Sicherheitspraktiken stützen sich auf den CVSS-Wert einer Schwachstelle, der meist wenig Kontext bietet. Beim Prioritätswert von Snyk werden kontextbezogene Informationen berücksichtigt, etwa der Reifegrad verfügbarer Exploits, Trends in sozialen Medien, der zugewiesene CVE-Schweregrad, die Verfügbarkeit einer Korrektur und der Zeitpunkt der Offenlegung.

Unser Prioritätswert reicht von 0, dem niedrigsten Wert, bis 1000, dem höchstmöglichen Wert. Er zeigt an, welche Sicherheitslücken ein Unternehmen am dringendsten beheben muss. Die Log4j-Schwachstelle ist ein perfektes Beispiel dafür, wie unser Prioritätswert Teams dabei unterstützt, die Behebung richtig zu priorisieren. Das folgende Bild aus dem Snyk-Dashboard zeigt, wie die spezifische Log4j-CVE in einigen Fällen den höchstmöglichen Wert von 1000 erhielt – und zwar im Kontext Tausender Schwachstellen, die ein Unternehmen in Hunderten von Projekten über verschiedene Ökosysteme und Programmiersprachen hinweg bewältigen muss:

Guy Podjarny (Gründer und Präsident von Snyk) hat dieses Konzept weiter ausgeführt und den Unterschied zwischen wichtig und dringend erklärt und gezeigt, wie sich das auf die Priorisierung von Sicherheitsmaßnahmen auswirkt. Wir haben dieses Konzept sogar auf die Cloud-native Anwendungsentwicklung ausgeweitet, damit Teams mit kontextbezogener Priorisierung in ihren Kubernetes-Deployments bessere Einblicke erhalten.

Bei kritischen Problemen wie Log4j ist schnelles Handeln entscheidend für das Geschäft

Die Log4j-Sicherheitslücke hat Incident-Response-Teams dazu veranlasst, die Ursachen zu ermitteln und ihre Bestände an bereitgestellten Java-Anwendungen zu durchsuchen und zu bereinigen.

Zweifellos mussten Incident-Response-Teams bei kritischen Sicherheitslücken wie Log4j schnell reagieren. Diese Belastung betrifft jedoch auch Entwickler und AppSec-Teams, die für die Sicherheit ihrer Anwendungen verantwortlich sind.

Snyks Kern-DNA ist auf Entwicklerfreundlichkeit und Sicherheit mit Entwicklerfokus ausgerichtet. Entwicklern und Sicherheitsteams zu ermöglichen, Sicherheitslücken so schnell und mühelos wie möglich zu finden und zu beheben, ist für uns nicht nur ein wichtiges Ziel – genau darum geht es uns.

Während des Sicherheitschaos rund um die Behebung der Log4j-Sicherheitslücke hat es uns gefreut und demütig gemacht, dass andere mit Snyk erfolgreich waren, um die Sicherheitslücke zu beheben:

Es geht nicht nur darum, Sicherheitslücken proaktiv und automatisch für Entwickler zu beheben, sondern auch darum, Sicherheitsprobleme in all Ihren Quellcode-Repositories zu berücksichtigen – einschließlich der verstaubten Legacy-Projekte:

Ihre nächsten Schritte zur Behebung von Log4Shell

Am Ende dieses Tunnels ist Licht – Sie müssen nur ein paar Schritte darauf zugehen!

Snyk kann Sie auf vielfältige Weise unterstützen: vom Verständnis des Ausmaßes der Gefährdung in Ihren verschiedenen Anwendungen über frühzeitige Tests während Ihres gesamten SDLC bis hin zum Auslösen automatisierter Pull Requests mit Korrekturen, um erkannte Sicherheitslücken schnell zu beheben.

Wir empfehlen Ihnen dringend, unseren Leitfaden dazu zu lesen, wie Sie Log4Shell mit Snyk schnell finden und beheben. Er enthält praktische Tipps zur schnellen Behebung von Log4j-Sicherheitslücken in Ihren Projekten. Falls Sie es noch nicht getan haben, registrieren Sie sich kostenlos bei Snyk!

Da sich die Ereignisse weiterhin überschlagen, ist es immer ratsam, auf dem Laufenden zu bleiben. Wir werden weiterhin Updates über unseren Newsletter und diesen Blog veröffentlichen – bleiben Sie dran!

Und zum Abschluss mit etwas Leichterem: Zumindest hat diese kritische Sicherheitslücke für ein paar vertraute Lacher gesorgt. Der alte XKCD-Comic „Little Bobby Tables“ kommt einem in den Sinn (mit einigen neuen Änderungen, wie ursprünglich in den sozialen Medien geteilt):