Log4Shell: Schneller aufspüren und beheben mit Snyk

Anmerkung der Redaktion(28. Dezember 2021, 20:35 Uhr MEZ):Eine neue Meldung des Teams von Log4j weist auf die Anfälligkeit von Version 2.17.0 gegenüber der Remote-Ausführung von Code hin (erfasst unter CVE-2021-44832). Ein Upgrade auf die derzeit aktuelle Version 2.17.1 wird dringend empfohlen. Näheres dazu finden Sie hier.

Anmerkung der Redaktion (18. Dezember 2021, 19:55 Uhr MEZ):Die Bedrohungslage rund um Log4j überschlägt sich weiterhin. Wir arbeiten mit Hochdruck daran, unsere Blogs mit neuesten Meldungen und Erkenntnissen zur Thematik zu aktualisieren. Es wird dringend empfohlen, ein Upgrade auf Log4j 2.17.1 oder höher vorzunehmen. Diese Version beinhaltet Fixes sowohl für die zwei Schwachstellen gegenüber der Remote-Ausführung von Code, die in Version 2.15.0 (CVE-2021-44228) und 2.16.0 (CVE-2021-45046) behoben wurden, als auch für die jüngst bekannt gewordene DoS-Schwachstelle (CVE-2021-45105). Näheres dazu finden Sie hier.

Was auch immer Sie sich für dieses Wochenende vorgestellt hatten – als am Freitag, 10. Dezember 2021, mitLog4Shell eine neue Zero-Day-Schwachstelle bekannt wurde, gingen diese Pläne vermutlich eher weniger auf.

Der Name verrät es bereits: Es geht um Log4J und damit um eines der am weitesten verbreiteten Logging-Frameworks für Java. Genauer gesagt um eine Schwachstelle in einer seiner Komponenten: der Open-Source-Bibliothek log4j-core. Die unter CVE-2021-44228 erfasste Schwachstelle wurde mit dem CVSS-Höchstwert von 10 als kritisch eingestuft. Aufgrund eindeutiger Belege für eine aktive Ausnutzung erhält sie zudem den höchsten Exploit-Reifegrad.

Betroffen sind alle Versionen von 2.0-beta9 bis 2.14.1\. Ein Fix wurde mit Version 2.16.0 am gleichen Tag bereitgestellt, an dem die Schwachstelle veröffentlicht wurde. 

Auch wir haben die entsprechende Security Intelligence direkt in unsererSchwachstellen-Datenbank erfasst. Unsere Kunden und Partner wie auch die gesamte Entwickler-Community können diese zur Hilfe nehmen, um ihre JVM-Anwendungen und -Container auf die Schwachstelle zu scannen und einen Ad-hoc-Fix mit Snyk Open Source und Snyk Container zu implementieren.

So erkennen und beheben Sie Log4Shell mit Snyk

Die erste und wohl wichtigste Frage besteht darin, zu welchem Grad Sie von der Schwachstelle betroffen sind.

Genau hier setzt Snyk an: Die Lösung gibt Ihnen nicht nur Aufschluss darüber, ob oder an welchen Punkten Sie anfällige Versionen des Pakets nutzen, sondern ermöglicht Ihnen auch die Umsetzung von Fixes über Ihr gesamtes SDLC hinweg.

Im Folgenden zeigen wir auf, wie Sie mit Snyk direkt am Code, mittels SCM-Integrationen oder per Alert über unseren Service für durchgängiges Monitoring feststellen können, ob Sie gegenüber Log4Shell anfällig sind. Dabei gehen wir auch darauf ein, wie sich dies mit unserem Reporting-Service und der Snyk API umfassend skalierbar umsetzen lässt.

Erkennung von nicht verwaltetem bzw. nicht deklariertem Code über die Snyk CLI mit dem Befehl snyk log4shell

Die Snyk CLI wurde mit snyk log4shell um einen Befehl ergänzt, über den sich Traces von gegenüber der Log4Shell-Schwachstelle anfälligen Log4j-Bibliotheken innerhalb Ihrer Java-Builds aufdecken lassen. Dies selbst dann, wenn die Bibliothek nicht in den Manifest-Dateien deklariert ist. Näheres hierzu finden Sie auf unserer Seite mit Informationen zu snyk log4shell und seiner Anwendung in Ihren Projekten.

Log4Shell-Erkennung direkt am Code

Der schnellste Weg zur Erkennung der Schwachstelle führt mit unseren IDE-Plug-ins und der Snyk CLI über Ihre Entwickler. Beide sind zum Einstieg kostenlos nutzbar und liefern Scan-Ergebnisse, die neben sämtlichen in der Anwendung erkannten Schwachstellen auch aufzeigen, wie sie ihren Weg in diese gefunden haben (also über direkte oder indirekte Abhängigkeiten). Zudem geben sie auch direkt klare Anweisungen zur Behebung.

Wie hier am Beispiel des Snyk Plug-ins für IntelliJ zu sehen, erhalten Entwickler Anweisungen zur Behebung der Schwachstelle direkt in der IDE.

Bei Erkennung der Log4J-Schwachstelle über die Snyk CLI wird dies anhand einer speziellen Warnmeldung hervorgehoben. Dies allerdings erst ab Version 1.792.0 – achten Sie also darauf, dass Sie hier auf dem aktuellen Stand sind. (Näheres zur Installation und zum Update der Snyk CLI finden Sie in unseren Docs.)

Erkennung von Schwachstellen und Fixing-Empfehlungen, wie sie sich mit Snyk CLI darstellen.

Erkennung von log4j-core innerhalb von JAR-Dateien

Falls Sie keinen Package-Manager wie beispielsweise Maven nutzen, können Sie mit Snyk auch JAR-Dateien auf die Schwachstelle scannen. Über den Befehl snyk test --scan-all-unmanaged führen Sie den Scan auf alle JAR-Dateien im aktuellen Ordner aus. (Für durchgängiges Monitoring Ihres Projekts können Sie den Befehl auch in Verbindung mit snyk monitor anstelle von snyk test verwenden.)

Projekt-Scans auf Log4J-Schwachstellen anhand der SCM-Integrationen von Snyk

Alle von Snyk unterstützten Projekte lassen sich mit wenigen Klicks importieren und auf Open-Source-Schwachstellen scannen. Von erkannten Schwachstellen und ihrem Ursprung bis hin zu ihrer Behebung erhalten Sie so auf Anhieb umfassende Insights:

Snyk gibt Ihnen detailgenaue Informationen zu allen erkannten Schwachstellen an die Hand, die nicht nur für ihre Behebung ungemein wichtig sind, sondern ganz generell für ein priorisiertes Fixing der drängendsten Problemstellungen.

Orientieren können Sie sich dabei am Priority Score, den Snyk anhand diverser Kriterien ermittelt. So etwa, ob von der jeweiligen Schwachstelle bereits ein aktiver Exploit bekannt ist, ob ein Fix für sie verfügbar ist und in welchem Umfang die Schwachstelle auf Twitter (bzw. heute X) thematisiert wird. Über den Priority Score können Sie die Liste der Schwachstellen schnell durchgehen und Fixes entsprechend priorisieren. Bei Log4Shell fällt der Wert logischerweise hoch aus, was durch Bewegen des Mauszeigers über den Wert noch näher erläutert wird.

Sämtliche Abhängigkeiten in Ihrem Projekt werden zudem in einer Baumstruktur dargestellt. So können Sie direkt nachvollziehen, ob eine Schwachstelle den Weg in Ihr Projekt über eine direkte oder indirekte Abhängigkeit gefunden hat.

Durchgängiges Monitoring zur Prävention künftiger Log4j-Schwachstellen

Projekte, deren Import in Snyk bereits vor Bekanntwerden der neuen Schwachstelle erfolgt ist, wurden im Rahmen unseres täglichen Scan-Cycle automatisch darauf untersucht (sofern die zugehörige Standardkonfiguration nicht geändert wurde). Bei Aktivierung von Benachrichtigungen informiert Snyk dabei auch direkt darüber, ob die Schwachstelle in einem Projekt festgestellt wurde.

Auto-Fixing von Log4Shell via Pull- oder Merge-Request

Bei Repositories, für die Monitoring mit Snyk bereits vor Bekanntwerden der Schwachstelle eingerichtet wurde, wurde automatisch ein Pull-/Merge-Request zum Upgrade von log4j-core auf eine sichere Version ausgelöst.

Falls Sie Ihr Projekt gerade erst importiert oder automatische Fixing-PRs nicht aktiviert haben, können Sie die Erstellung der Fixing-PR manuell über die Projektseite vornehmen. 

Projektübergreifende Erkennung und Behebung von Log4Shell

Kunden mit Zugriff auf unsere API und unseren Reporting-Service können bei all dem noch einen Schritt weiter gehen. Denn damit können Sie für sämtliche Open-Source-Projekte, die durch Monitoring mit Snyk abgedeckt sind, ein klares Bild davon erhalten, wo die log4j-core-Abhängigkeit bei ihnen genutzt wird.

Aufspüren von log4j-core in Projekten mit Snyk Reporting

In den Reports Ihrer Gruppe oder auf Organisationsebene finden Sie einen Tab zu Abhängigkeiten. Von dort aus können Sie über die Software-BOM von Snyk einen Suchlauf danach durchführen, wo log4j-core bei Ihnen genutzt wird. Öffnen Sie dazu den Filter Dependencies, geben Sie log4j-core für den Namen der Abhängigkeit ein und wählen Sie sie aus, um die Suchergebnisse auf dieses Paket einzugrenzen. Keine Suchergebnisse bedeuten, dass die Abhängigkeit nicht in den Projekten aufzufinden ist, die durch Monitoring mit Snyk abgedeckt sind.

Im Tab für Abhängigkeiten der Snyk Reporting-Ansicht suchen Sie einfach nach `log4j-core`.

Wird die Abhängigkeit jedoch gefunden, können Sie direkt erkennen, wo genau sie genutzt wird. Über den Link Projects erhalten Sie dabei eine Liste der Projekte, in die log4j-core als Abhängigkeit eingebunden ist. Durch Klicken auf die einzelnen Projekte erhalten Sie Anweisungen zur Behebung. Sofern ein Upgrade-Pfad besteht, können Sie hier außerdem ein Pull-/Merge-Request zum Fixing einrichten.

Aufspüren von log4j-core in Ihren Projekten mit der Snyk API

Auch unsere API ist bei der Erkennung von Abhängigkeiten zu log4jcore äußerst hilfreich. So können Sie über den Endpunkt für Abhängigkeiten nach Organisation direkt feststellen, wo diese genau genutzt werden. Anhand von Filtern etwa für die Programmiersprache (relevant in diesem Fall wäre Java), den Schweregrad und diverse andere Kriterien lassen sich die Ergebnisse zudem weiter eingrenzen. Der Endpunkt für alle Organisationen in einer Gruppe weitet das Ganze dann auf mehrere Projekte innerhalb eines Funktionsbereichs aus.

Ausgegeben werden damit verschiedene Details einschließlich einer Liste aller Projekte, die das anfällige Paket beinhalten. Diese können Sie nun über die Snyk UI einsehen und beheben oder auch weitere APIs einbinden, die passende Anweisungen zum Fixing liefern.

Immer sicher und auf Kurs mit Snyk

Zum Einstieg kostenlos, unkompliziert und effizient in der Nutzung: Setzen Sie auf Snyk, um nicht nur schnell zu erkennen, ob Sie das anfällige log4j-core-Paket (oder andere unsichere Kandidaten) nutzen, sondern das Problem auch mühelos beheben – und damit auch Ihr nächstes Wochenende besser planen können.