Fragen und Antworten zu Log4j Log4Shell-Sicherheitslücken
In unserem jüngsten Webinar, Log4j Log4Shell Vulnerability Explained: All You Need To Know, hat unser Senior Director Security Research, Shachar Menashe, Informationen über das Sicherheitsproblem geteilt und darüber, wie man es erkennt und behebt.
Wir freuen uns, Ihnen in den folgenden Fragen und Antworten zusätzliche Informationen zu geben, die auf den während des Webinars gestellten Fragen basieren.
Das Log4j-Sicherheitsproblem
Wie wird der log4j-Exploit ausgeführt?
JFrog hat einen umfassenden Blog-Beitrag veröffentlicht, in dem die Sicherheitslücke im Detail erklärt wird. Siehe Abschnitt: „Was verursacht die Log4j Log4Shell-Sicherheitslücke?“
Ich habe gehört, dass der log4j-API-Aufruf ebenfalls anfällig ist. Warum konzentrieren Sie sich nur auf den Kern?
Die log4j-api ist nicht anfällig, nur log4j-core ist anfällig.
Wie verhält sich die log4j log4shell-Sicherheitslücke im Vergleich zu Shellshock hinsichtlich der globalen Auswirkungen?
Sowohl bei log4shell als auch bei Shellshock handelt es sich um Sicherheitslücken für die Remotecodeausführung, die sich auf eine Vielzahl von Systemen auswirken. Shellshock ist eine Sicherheitslücke in Bash (einer sehr verbreiteten Linux-Shell), die eine Anwendung ist, während log4shell eine Sicherheitslücke in der log4j-Bibliothek ist. Aus mehreren Gründen stellt das log4j-Sicherheitsproblem eine größere Herausforderung dar, wenn es darum geht, die Bedrohung zu mindern.
Um Shellshock zu erkennen, reichte es aus, auf dem lokalen System zu prüfen, ob eine anfällige Version von Bash installiert war; Bash selbst wird normalerweise nicht mit Abhängigkeiten von Drittanbietern bereitgestellt.
Das log4shell-Sicherheitsproblem ist viel schwieriger zu erkennen, da log4j eine Bibliothek ist, so dass die Erkennung die Überprüfung aller direkten und indirekten (transitiven/rekursiven) Abhängigkeiten erfordert. Darüber hinaus ist der Angriffsvektor für log4shell häufiger (Protokollierung von unsauberen Eingaben) als der von Shellshock (Weitergabe von unsauberen Eingaben an die Bash-Umgebung).
Log4shell ist auch schwieriger zu reparieren – da es sich um eine Bibliothek handelt, wurden mehrere APIs in neueren Versionen geändert, was bedeutet, dass ein Softwarehersteller möglicherweise den First-Party-Code ändern muss, der direkt mit log4j interagiert, und nicht nur log4j selbst aktualisieren muss.
Schließlich erfordern neuere Versionen von log4j eine neuere Version von Java (Java 8 gegenüber dem alten Java 6/7), was bedeutet, dass der Softwarehersteller möglicherweise auch die Java-Komponente aktualisieren muss, was wiederum zu Inkompatibilitäten mit anderer Java-basierter Software auf dem System führen kann.
Was ist mit log4j-Version 1, die nicht anfällig ist? Wird sie von der Welle der Aufmerksamkeit für log4j-Version 2 betroffen sein?
Der aktuelle Exploit gefährdet die Version 1 nicht. Allerdings könnten Angreifer jetzt mehr Aufwand bei der Erforschung der log4j-Komponente betreiben, um weitere Sicherheitslücken zu finden.
Lösungen, um Log4j zu finden und zu beheben
Haben Sie spezielle Tools, mit denen ich feststellen kann, ob ich irgendwelche log4j-Pakete in meinen Repositories habe?
Ja! Zunächst einmal haben unsere Kunden, die die JFrog DevOps-Plattform als zentralen Teil ihres geschäftskritischen Software-Entwicklungszyklus (SDLC) nutzen, bereits alles, was sie brauchen, um die Log4j-Sicherheitslücke schnell zu beheben.
Mit Ihren gesammelten Paketen, Binärdateien, Images und Metadaten unter dem Binär-Repository-Management von Artifactory können Sie Artefakte und Builds suchen, um jede Verwendung des log4j-Pakets, auch in Form von transitiven Abhängigkeiten, in Ihrer gesamten Software-Lieferkette festzustellen. Und Sie können Xray-Richtlinien und Überwachungen erstellen, um alle weiteren Builds, die anfällige Versionen des log4j-Pakets verwenden, von der Produktion auszuschließen.
Für die Entwicklergemeinschaft insgesamt hat JFrog auch eine Reihe von hilfreichen Open Source-Tools veröffentlicht, um die log4j-Verwendung sowohl im Quellcode als auch in Binärdateien in lokalen Verzeichnissen zu ermitteln.
Angenommen, wir verwenden eine Komponente eines Drittanbieters, die eine Kompilierzeitabhängigkeit von log4j aufweist. Gibt es eine Möglichkeit, wie wir log4j loswerden können, während wir diese Komponente verwenden?
Dies ist nur dann ein Problem, wenn das Paket eine anfällige Version von log4j nutzt. Wenn dies der Fall ist, müssen Sie sich eine korrigierte Version der Drittanbieterkomponente beschaffen. Wenn Sie den Quellcode haben, können Sie es selbst mit der korrigierten log4j-Version kompilieren.
Ist jede Abhängigkeit, die auf log4j verweist, anfällig für diesen Angriff, auch wenn sie eine API-Bibliothek wie Spring Framework verwendet, die auf die log4j-Bibliothek als Abhängigkeit verweist?
Es kommt auf den konkreten Fall an und darauf, welche Teile der log4j-Bibliothek verwendet werden. Während log4j-core anfällig ist, ist log4j-api NICHT anfällig.
Um möglichst umfassende Ergebnisse zu erzielen, empfehlen wir die Verwendung eines Scanning-Tools für die Software Composition Analysis (SCA) wie JFrog Xray, um die Sicherheitslücken in all Ihren Software-Abhängigkeiten zu identifizieren – einschließlich derer, die mit log4j zusammenhängen, aber auch viele, viele andere.
Wenn Ihnen das nicht zur Verfügung steht, können Sie die OSS-Tools verwenden, die JFrog für die Community erstellt hat, um insbesondere die log4j-Nutzung in Quellcode und Binärdateien zu ermitteln (siehe oben).
Wenn Xray feststellt, dass ein Artefakt anfällig für log4shell ist: Gibt es eine Möglichkeit, die Nutzer dieses Artefakts zu bestimmen – d.h. Artifactory zu verwenden, um zu verfolgen, welche Dienste/Benutzer auf das anfällige Artefakt zugegriffen bzw. es heruntergeladen haben, so dass diese spezifischen Dienste analysiert werden können?
Absolut! Hierfür wurde die JFrog Platform entwickelt. Sie können Xray und Artifactory verwenden, um Nutzer von anfälligen Artefakten zu identifizieren und ihre Verwendung mit den folgenden Methoden zu kontrollieren:
- Durchsuchen Ihrer Repositories nach der Verwendung von log4j-Paketen
- Suche nach CVE-2021-44228
- Ausführen einer Build-Info-Abfrage in Artifactory, um alle Builds aufzulisten, die die log4j-core-Bibliothek als Abhängigkeit verwenden
- Definieren einer Xray-Richtlinie, um einen Verstoß zu melden oder den Download des anfälligen Pakets zu blockieren
Weitere Details finden Sie in unserem Blogbeitrag Your Log4shell Remediation Cookbook Using the JFrog Platform, in dem mehrere Methoden beschrieben werden, um die log4shell-Sicherheitslücke festzustellen, zu blockieren und zu beheben.
Kann ich eine Demo von Xray für die Erkennung von statischen und transitiven Abhängigkeiten ansehen?
Sehr gerne! Bitte kontaktieren Sie uns für eine Demo von Xray und wir werden einen Termin vereinbaren, um Ihnen zu zeigen, wie Sie durch alle Schichten der Abhängigkeiten eines Artefakts sehen können.
