Skip to main content

Log4Shell-Exploit schnell finden und beheben – mit Snyk

Artikel von
Headshot of Ariel Ornstein

Ariel Ornstein

blog feature log4j vulnerability red

13. Dezember 2021

0 Min. Lesezeit

Hinweis 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 anfällig für Remote Code Execution ist. Die Schwachstelle wurde als CVE-2021-44832 identifiziert. Wir empfehlen, auf die neueste Version zu aktualisieren, die derzeit 2.17.1 ist. Mehr dazu hier.

Hinweis der Redaktion (18. Dez. 2021, 18:55 Uhr GMT): Die Lage rund um Log4j verändert sich schnell, und wir aktualisieren unsere Blogbeiträge, sobald neue Informationen verfügbar sind. Wir empfehlen ein Upgrade auf Version 2.17.1 oder höher. Diese Version enthält Sicherheitskorrekturen für zwei Schwachstellen zur Remote Code Execution, 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). Mehr dazu hier.

Selbst wenn Sie sich noch so sehr auf ein ruhiges Wochenende gefreut haben, wurde dieser Plan wahrscheinlich mindestens einmal durch die neue Log4Shell-Zero-Day-Schwachstelle durchkreuzt, die am Freitag (10. Dezember 2021) bekannt gegeben wurde.

Die neue Schwachstelle wurde in der Open-Source-Java-Bibliothek log4j-core gefunden, einer Komponente des beliebten Java-Logging-Frameworks Log4J. Sie erhielt die Kennung CVE-2021-44228, wurde mit einem CVSS-Score von 10 als kritisch eingestuft und weist einen hohen Reifegrad des Exploits auf, da es eindeutige Hinweise auf Angriffe in freier Wildbahn gibt.

Alle Versionen ab 2.0-beta9 bis einschließlich 2.14.1 sind von der neuen Schwachstelle betroffen. Behoben wurde sie in der neuesten Version (2.16.0), die am Tag der Bekanntgabe veröffentlicht wurde. 

Snyk hat die neue Schwachstelle schnell in die Snyk Intel Vulnerability Database aufgenommen, damit Kunden, Partner und die Community ihre JVM-Anwendungen und Container scannen und dringend eine Korrektur für diese Schwachstelle anwenden können – mit Snyk Open Source und Snyk Container.

So unterstützt Snyk Sie dabei, Log4Shell zu finden und zu beheben

Eine der ersten Fragen lautet meist: Wie stark sind meine Systeme dieser Schwachstelle ausgesetzt?

Mit Snyk finden Sie es heraus: Sie sehen, ob Sie anfällige Versionen des Pakets verwenden und wo diese zum Einsatz kommen. Außerdem unterstützt Snyk Sie dabei, die Schwachstellen in Ihrem gesamten SDLC zu beheben.

Wir zeigen Ihnen, wie Sie mit Snyk herausfinden, ob Sie von Log4Shell betroffen sind – direkt beim Programmieren, über unsere SCM-Integrationen oder per Benachrichtigung durch unseren kontinuierlichen Monitoring-Service. Außerdem erfahren Sie, wie Sie unseren Reporting-Service und unsere API für Untersuchungen in großem Umfang nutzen.

Snyk-CLI-Befehl für nicht verwalteten, nicht deklarierten Code: snyk log4shell

Die Snyk CLI bietet einen neuen Befehl mit einem klaren Zweck: Spuren der von der Log4Shell-Schwachstelle betroffenen Log4j-Bibliothek zu finden. snyk log4shell testet Ihr kompiliertes Java-Projekt und findet Spuren der anfälligen Bibliothek – auch wenn sie nicht in den Manifestdateien deklariert ist. Erfahren Sie mehr über snyk log4shell und die Verwendung in Ihren Projekten.

Log4Shell-Schwachstellen direkt beim Programmieren finden

Um die Schwachstelle so schnell wie möglich zu finden, können Entwickler unsere IDE-Plugins und unsere CLI nutzen, mit denen Sie kostenlos loslegen können. Die Scan-Ergebnisse umfassen alle von Snyk gefundenen Schwachstellen. Für jede Schwachstelle erfahren Sie, wie sie in die Anwendung gelangt ist (als direkte oder transitive Abhängigkeit) und wie Sie sie beheben können.

Das Snyk IntelliJ-Plugin kennzeichnet eine Schwachstelle zur willkürlichen Codeausführung in Log4j und zeigt Anweisungen zur Behebung an, einschließlich eines Upgrades auf Version 2.15.0.
Ein Screenshot des IntelliJ-IDE-Plugins von Snyk mit Inline-Anweisungen zur Behebung der Sicherheitslücke.

Die Snyk CLI (achten Sie darauf, die neueste Version v1.792.0 zu verwenden) zeigt eine spezielle Warnmeldung an, damit die Schwachstelle besonders sichtbar ist, falls sie gefunden wird. Anleitungen zur Installation und Aktualisierung der Snyk CLI finden Sie in unserer Dokumentation:

Terminalausgabe der Snyk CLI mit zwei Log4j-Sicherheitslücken sowie empfohlenen Upgrade- und Behebungsschritten.
Schwachstellen mit der Snyk CLI finden und Anweisungen zur Behebung erhalten.

Scannen nach als JAR-Datei hinzugefügtem log4j-core

Wenn Sie keinen Paketmanager wie Maven verwenden, kann Snyk die Schwachstelle auch in JAR-Dateien erkennen. Führen Sie dazu einfach den Befehl snyk test --scan-all-unmanaged aus, um alle JAR-Dateien im aktuellen Ordner zu scannen. (Das funktioniert auch mit dem Befehl snyk monitor, um das Projekt kontinuierlich zu überwachen.)

Terminal mit den Ergebnissen eines Snyk-Abhängigkeitsscans: zwei Log4j-Schwachstellen und die Empfehlung, von Version 2.14.1 auf 2.16.0 zu aktualisieren.

Log4j-Schwachstellen in Ihren Projekten mit den SCM-Integrationen von Snyk testen

Mit wenigen Klicks können Sie alle von Snyk unterstützten Projekte importieren, auf Open-Source-Schwachstellen testen und sofort Einblicke gewinnen – etwa dazu, welche Schwachstellen vorhanden sind, wie sie ins Projekt gelangt sind und wie Sie sie beheben können:

Repository-Oberfläche mit dem Projekt arielorn-demos und ausgewählten Repositories, darunter distributed-app, java-goof, goof, java-reachability-playground und
Schwachstellenbericht für Apache Log4j mit willkürlicher Codeausführung, kritischem Schweregrad, Bewertung 1000 und Details zur Behebung.

Snyk stellt umfangreiche Informationen zu den gefundenen Schwachstellen bereit. Diese sind entscheidend, um zu verstehen, wie sich eine Schwachstelle beheben lässt und welche Schwachstellen vorrangig Aufmerksamkeit erfordern.

Der Priority Score von Snyk wird anhand verschiedener Signale berechnet: zum Beispiel, ob es einen Exploit in freier Wildbahn gibt, eine Korrektur verfügbar ist oder die Schwachstelle auf Twitter im Trend liegt. Mithilfe dieses Scores können Sie die Liste der Schwachstellen schnell durchsehen und Korrekturen entsprechend priorisieren. Bei Log4Shell ist der Priority Score nachvollziehbarerweise hoch. Wenn Sie den Mauszeiger über den Score bewegen, wird dies erklärt.

Der Abhängigkeitsbaum des Projekts zeigt genau, wie eine Schwachstelle in die Anwendung gelangt ist – direkt oder als transitive Abhängigkeit:

Abhängigkeitsbaum, gefiltert nach Sicherheitslücken; hervorgehoben ist org.apache.logging.log4j:log4j-core@2.3 unter den anfälligen Java-Abhängigkeiten.

Kontinuierliche Überwachung, um künftige Log4j-Schwachstellen zu verhindern

Wenn Sie Ihre Projekte bereits vor Bekanntgabe der neuen Schwachstelle importiert hatten, wurde Ihr Projekt automatisch im Rahmen unseres täglichen Testzyklus geprüft – sofern die Standardeinstellungen nicht geändert wurden. Wenn Sie Benachrichtigungen aktiviert haben, sollten Sie bereits eine Meldung erhalten haben, ob die Schwachstelle in einem Ihrer Projekte gefunden wurde.

Automatischer Log4Shell-Fix per PR/MR

Wenn Snyk Ihr Repository bereits vor Bekanntgabe der neuen Schwachstelle überwacht hat, hat Snyk automatisch einen Pull-/Merge-Request zur Behebung erstellt. Dieser aktualisiert log4j-core auf eine nicht anfällige Version.

Snyk-Pull-Request mit einem Maven-Abhängigkeits-Upgrade, das die Remote-Codeausführungsschwachstelle in Log4j behebt: von Version 2.3 auf 2.15.0.

Wenn Sie das Projekt gerade erst importiert oder automatische Fix-PRs nicht aktiviert haben, können Sie den Fix manuell auf der Projektseite als PR erstellen. 

Schwachstellen-Dashboard mit einer Sicherheitslücke zur beliebigen Codeausführung in Apache Log4j, kritischem Schweregrad und hervorgehobenem Button „Diese Schwachstelle beheben“.

Log4Shell in allen Services Ihres Unternehmens erkennen und beheben

Wenn Sie Kunde sind und Zugriff auf unsere API und unseren Reporting-Service haben, können Sie sich damit einen Überblick darüber verschaffen, wo die Abhängigkeit log4j-core in all Ihren überwachten Open-Source-Projekten verwendet wird.

Mit den Reports von Snyk Projekte finden, die log4j-core verwenden

In der Stückliste von Snyk, die Sie im Tab „Abhängigkeiten“ Ihrer Gruppen- und Organisationsreports finden, können Sie nach Verwendungen von log4j-core suchen. Öffnen Sie den Filter Abhängigkeiten, geben Sie den Namen der Abhängigkeit ein (log4j-core) und wählen Sie ihn aus, um die Ergebnisse auf dieses Paket einzugrenzen. Wenn keine Ergebnisse angezeigt werden, ist diese Abhängigkeit in den von Snyk überwachten Projekten nicht vorhanden.

Snyk-Berichte: Der Tab „Abhängigkeiten“ ist nach „log4j“ gefiltert; org.apache.logging.log4j:log4j-core@2.3 ist ausgewählt
Ein Screenshot der Suche nach `log4j-core` im Tab „Abhängigkeiten“ der Snyk-Berichte.

Wenn Sie die Abhängigkeit finden, sehen Sie genau, wo sie verwendet wird. Klicken Sie auf den Link Projekte, um eine Liste aller Projekte aufzurufen, die log4j-core als Abhängigkeit verwenden. Klicken Sie anschließend auf das gewünschte Projekt. Dort finden Sie Anweisungen zur Behebung. Wenn ein Upgrade-Pfad verfügbar ist, können Sie auch einen Pull-/Merge-Request zur Behebung erstellen.

Bereich für Abhängigkeitsprojekte für org.apache.logging.log4j:log4j-core@2.3 mit zwei Projekten, GitHub- und CI-/CLI-Quellen sowie der Anzahl der Probleme.

Mit der Snyk API Projekte finden, die log4j-core verwenden

Sie können auch unsere API verwenden, um herauszufinden, wo die Abhängigkeit log4j-core genutzt wird. Mit dem Endpunkt Dependencies by organization können Sie alle verwendeten Abhängigkeiten auflisten und erfahren, wo sie zum Einsatz kommen. Mit verschiedenen Filtern, etwa nach Programmiersprache (in diesem Fall Java) oder Schweregrad, können Sie die Ergebnisse eingrenzen. Wenn Sie eine Gruppe mit mehreren Organisationen haben und diese alle durchgehen möchten, verwenden Sie den Endpunkt List all organizations in a group.

Code-Screenshot mit einem JSON-Datensatz für Apache Log4j Version 2.3, in dem die Anzahl kritischer Probleme und zugehörige Maven-Projekte hervorgehoben sind

Die Antwort enthält eine Liste aller Projekte, die das betreffende Paket enthalten. Anschließend können Sie die Projekte in der Benutzeroberfläche aufrufen und die Schwachstellen beheben oder über andere APIs Anweisungen zur Behebung abrufen.

Lassen Sie sich von Snyk unterstützen!

Mit Snyk starten Sie kostenlos – schnell und einfach. Legen Sie noch heute los: Wir helfen Ihnen herauszufinden, wo Sie das anfällige Paket log4j-core (und weitere) verwenden, und unterstützen Sie dabei, die Schwachstellen unkompliziert zu beheben, damit Sie Ihr Wochenende genießen können!

Starten Sie mit Capture the Flag

Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Herausforderungen lösen.

Weiterlesen

Blog

Frontier-Modelle fanden die Schwachstellen. Nur der Angreifer fand die Angriffsketten.

Die statische Analyse fand die Schwachstellen, doch erst Live-Angriffstests bewiesen, wie sie sich zu Angriffen verketten lassen. Ein Vergleich von Evo COS, Claude Security und Claude Code Security.

feature insights context
Blog

Autonome Angriffe sind bereits Realität. Die Verteidigung muss Schritt halten.

Autonome Angreifer verkürzen das Zeitfenster für die Verteidigung. Erfahren Sie, wie kontinuierliches Erkennen, Beheben, Validieren und Verhindern Sicherheitsteams helfen kann, Schritt zu halten.

Blog

Warum KI-Coding-Agenten immer wieder fehlerhafte Zugriffskontrollen schreiben

KI-Coding-Agenten können Autorisierungslogik erzeugen, die kompiliert und die Prüfung besteht, dabei aber die Daten eines Mandanten für einen anderen offenlegt. Erfahren Sie, warum fehlerhafte Zugriffskontrollen schwer zu erkennen sind und wie Sie sie verhindern.