Blog
Log4J - Ein 10-stufiger Plan zur Schadensbegrenzung
Es gibt bereits eine Menge Aufmerksamkeit für den #Log4J Schwachstellen. Während wir diesen Blog schreiben, sind die Nachrichten voll davon. Viele Kunden haben uns gefragt, was zu tun ist. In diesem Blog geben wir einige Ratschläge, wie Sie mit der Log4j-Schwachstelle und ähnlichen Schwachstellen in der Zukunft umgehen können.
Update: Welche Sicherheitslücken gibt es?
Der ursprüngliche Blog unten wurde geschrieben um CVE-2021-45046 und CVE-2021-44228geschrieben, bei denen die JNDI-Funktionalitäten von Log4J in einigen Fällen missbraucht werden konnten, um einen RCE zu erreichen (Ferngesteuert Code-Ausführung). Die damalige Empfehlung lautete, auf Version 2.12.2 zu aktualisieren, wenn Sie Java7 und Version 2.16.0 in allen anderen Fällen.
Jetzt wurde eine neue Sicherheitslücke entdeckt: CVE-2021-45105 . Dies ermöglicht einen DoS (Denial of Service)-Angriff auf Log4J, wenn Sie das log4j-core JAR in Kombination mit einer bestimmten Konfiguration verwenden, die "Context Lookups wie ${ctx:loginId}oder $${ctx:loginId}" gemäß dem Beitrag des Apache Log4J-Teams. Es gibt 2 Korrekturen für dieses Problem:
- Aktualisieren Sie das Log4J core JAR auf Version 2.17.0;
- Aktualisieren Sie Ihre Log4J-Konfiguration wie hier beschrieben hier vom Apache Log4J-Team beschrieben.
Wir empfehlen, ZUERST sicherzustellen, dass Sie keine Systeme haben, die mit einer Version von Log4J core unter Version 2.16.0 laufen. (oder 2.12.2 im Falle von Java7). Wenn Sie dies tun, patchen Sie sie auf die neueste verfügbare Version (2.17.0 für Java 8 und höher, 2.12.2 für Java 7).
Da die jüngsten Sicherheitsnachrichten die Aufmerksamkeit vieler Sicherheitsforscher auf verschiedene Open-Source-Bibliotheken gelenkt haben, gehen wir davon aus, dass bald weitere CVEs zu verschiedenen Bibliotheken gemeldet werden.
Was ist zuerst zu tun?
1. Prüfen Sie, ob Sie von der Sicherheitslücke betroffen sind
Es gibt verschiedene Möglichkeiten, wie Sie überprüfen können, ob Sie anfällig sind:
Mit Hilfe der statischen Analyse:
- Wenn Sie Software schreiben, die auf der Java Virtual Machine läuft (JVM) basierend auf Java/Scala/Kottlin/Groovy/Clojure schreiben, überprüfen Sie, ob Sie Log4J-core JAR mit einer Version unter 2.16.0 verwenden.
- Prüfen Sie, welche andere Software Sie einsetzen und ob diese Software laut der vom NCSC-NL veröffentlichten Liste anfällig ist. CISA.gov hat ein ähnliches Verzeichnis.
Mittels einer dynamischen Analyse:
- Es gibt verschiedene Tools, die das NCSC-NL in seinem Github-Repositorium sitory mit denen Sie feststellen können, ob Sie verwundbar sind. Schauen Sie, welche Ihnen in der jeweiligen Situation am besten gefällt.
2. Aufsetzen! Aufnäher! Aufnäher!
Wenn Sie verwundbare Software gefunden haben, patchen Sie sie! Wenn Sie Ihre eigene Software schreiben, bedeutet das: Aktualisieren Sie Log4J-core mindestens auf Version 2.16.0 (2.12.2 bei Verwendung von Java7).
Wenn Sie mit Software von Drittanbietern arbeiten, die eine verwundbare Version von Log4J enthält, aktualisieren Sie die betreffende Software oder befolgen Sie das von Ihrem Anbieter beschriebene Patch-Verfahren. Wenn kein Upgrade oder eine Anleitung verfügbar ist, wenden Sie sich an den Hersteller der Software und bitten Sie ihn um Unterstützung. Hilft auch das nicht? Lesen Sie weiter, um andere mögliche Lösungen zu prüfen.
3. Was ist, wenn Sie nicht patchen können?
Wenn Sie die Bibliothek nicht aktualisieren können, gibt es möglicherweise verschiedene Lösungen für dieses Problem:
- Um den Remote Execution-Angriff zu verhindern, entfernen Sie die Klasse aus der Anwendung, die das RCE-Problem tatsächlich verursacht. Oder besser gesagt: die die Schwachstelle einführt. In diesem Fall ist das die "JndiLookup.class". Datei. Diese Datei muss aus der JAR-Datei gelöscht werden. Sie können die Datei ganz einfach mit Hilfe von Tools wie Zip und 7-Zip löschen, da die JAR-Datei im Grunde eine "zip Datei" mit Java-Klassendateien und zusätzlichen Ressourcen. Eine Möglichkeit, dies zu tun, ist die Verwendung von 7-zip: "c:Program Files7-Zip7z.exe" d log4j-core-2.9.1.jar org/apache/logging/log4j/core/lookup/JndiLookup.class . Das Log4J-Team rätses, den folgenden Befehl auszuführen wowenn Sie einen Mac oder Linux verwenden: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class .
- Ein anderer Ansatz besteht darin, Konfigurationsänderungen an der Log4J-Bibliothek vorzunehmen, um die verwundbare Bibliothek wieder sicher zu machen. Diese erforderlichen Änderungen sind jedoch je nach Version der verwendeten Bibliothek unterschiedlich. Diese Konfigurationsänderungen sind nicht immer wirksam und haben manchmal unerwünschte Nebeneffekte. Am besten lesen Sie darüber nach hier.
- Schalten Sie das anfällige System offline und versuchen Sie, eine Umgehung für die vom System bereitgestellte Funktionalität zu finden, bis ein Patch verfügbar ist.
- Es gibt Laufzeit-Patches wie z.B. log4j-jndi-be-gone die in einen Prozess injiziert werden können und das Laden der JNDI-relevanten Klassen verhindern. Dies erfordert keine Änderungen an den Anwendungsdateien, falls diese signiert sind oder anderweitig nicht bearbeitet werden können. Außerdem entfernen diese Tools die Sicherheitslücke, falls diese aufgrund einer Fehlkonfiguration aus einem anderen Verzeichnis abgegriffen wird. (Klasse Pfad).
Aber was ist mit den WAFs? Wir hören manchmal, dass die Verwendung einer Web-Anwendungs-Firewall empfohlen wird. (WAF) um Angreifer daran zu hindern, die Sicherheitslücke auszunutzen. Auch wenn eine WAF als Tiefenverteidigung hilfreich sein kann, sollte sie nicht Ihre primäre und einzige Verteidigung sein. Eine WAF hilft dabei, einen Angreifer aufzuhalten: Wenn sie richtig konfiguriert ist, kann sie viele der derzeit in freier Wildbahn gefundenen Angriffe aufhalten. Ein raffinierter Angreifer könnte jedoch immer noch in der Lage sein, die WAF zu umgehen. Daher kann eine WAF als zeitweilige Überbrückung dienen, solange Sie verwundbare Komponenten haben, aber wir empfehlen, sie als zweite Verteidigungsschicht zu verwenden. Die unter 2 & 3 beschriebenen Maßnahmen sollten Ihre primäre Verteidigung sein.
Ein kleiner Hinweis: Wenn Sie Ihre eigene Software schreiben und JAR-Shading verwenden
Jar-Shading ist eine Technik, die manchmal von den Entwicklern von Bibliotheken/Tools angewendet wird. Bei diesem Verfahren werden mehrere - oft unterstützende - JAR-Dateien zusammen gepackt, die dann umbenannt werden, um sicherzustellen, dass die Autoren der Bibliothek/des Werkzeugs eine bessere Kontrolle über die verwendeten Abhängigkeiten haben. Das bedeutet, dass die verwundbare Log4J JAR-Datei in der Bibliothek/dem Tool vorhanden sein kann, ohne dass sie in der Bibliothek/dem Tool enthalten ist. sierkannt werden, wenn der Name geändert wird. In diesem Fall können Lösungen wie das bereits erwähnte log4j-jndi-be-gone könnte ebenfalls helfen.
Was ist als nächstes zu tun?
Es gibt ein paar Dinge, auf die Sie achten müssen:
4. Sicherheit und Ereignisüberwachung
Stellen Sie sicher, dass Sie über ein geeignetes System zur Protokollierung und Überwachung von Sicherheitsereignissen (SEM) verfügen. Stellen Sie sicher, dass Sie in der Lage sind, zu erkennen, wenn der Log4Shell-Exploit auf Ihr System angewandt wird, und stellen Sie sicher, dass Sie merkwürdiges Verhalten auf Ihrem System im Umfang erkennen können. Möchten Sie mit SEM beginnen? Es gibt viele ausgereifte Lösungen in Ihrem Cloudprovider und ausgereifte Open-Source-Tools für Ihren Stack.
5. Bereiten Sie sich auf Incident Response
Seien Sie immer bereit, auf Zwischenfälle zu reagieren. Stellen Sie sicher, dass Sie ein Laufbuch und einen Anruf haben -Baum bereit, wenn Sicherheitsvorfälle passieren. Wenn Sie glauben/feststellen, dass Ihre Anwendungslandschaft erfolgreich ausgenutzt wird, wenden Sie sich an ein professionelles Incident Response Team.
Was ist mit der Zukunft?
Es gibt ein paar Dinge, die Sie tun können, um Ihre Reaktion auf ähnliche zukünftige Ereignisse zu beschleunigen:
6. Wissen Sie immer, was Sie ausführen: die Software-Stückliste
Stellen Sie sicher, dass Sie wissen, was Sie auf Ihrer Plattform einsetzen. Die Software-Stückliste (SBoM) beschreibt alle verschiedenen Softwarekomponenten, auf denen Ihr System basiert. Wenn Sie Ihr SBoM aktiv mit Tools wie OWASP dependencyTrackwird es einfacher zu wissen, ob die von Ihnen verwendete Software anfällig ist. Außerdem gibt es großartige Open-Source-Tools, wie das OWASP Dependency Checker, Trivy, Clairund viele andere, die Sie als Teil Ihrer CI/CD-Pipeline verwenden können, um zu erkennen, ob die Software, die Sie erstellen, bekannte Sicherheitslücken aufweist.
7. Shalten Sie sich auf dem Laufenden automatisch
Wenn Sie Ihre eigene Software schreiben oder komponieren: Verwenden Sie Tools wie DependaBot, Renovieren Sie, Snyk, usw. um automatisch Pull/Merge-Requests und Kompatibilitätsbewertungen zu erstellen. Es ist viel einfacher, einen Patch auf ein System anzuwenden, wenn es eine aktuelle Version einer Bibliothek verwendet. Einige dieser Tools liefern einen Kompatibilitätsscore und Hinweise, wie Sie Änderungen vornehmen können.
8. Verstehen Sie die Risiken Ihrer eigenen Anwendungslandschaft: Dokument und Bedrohungsmodell
Wenn Schwachstellen in Ihrem System auftauchen, ist es gut zu verstehen, welche Risiken damit verbunden sind, wenn diese ausgenutzt werden. Zu diesem Zweck kann es hilfreich sein, die Gesamtarchitektur Ihrer Anwendungslandschaft zu dokumentieren und eine aktive Bedrohungsmodellierung durchzuführen.
9. Isolieren Sie Ihre Anwendungen und Dienste
Software wird immer Schwachstellen enthalten. Aus diesem Grund müssen Sie Ihre Software isolieren, um sicherzustellen, dass die Ausnutzung einer Schwachstelle nicht automatisch bedeutet, dass das gesamte System gefährdet ist. Die Isolierung kann auf verschiedene Weise erfolgen:
- Implementieren Sie eine Netzwerksegregation und -trennung. Stellen Sie sicher, dass die Ein- und Ausgänge gefiltert werden und dass der Netzwerkverkehr protokolliert wird, damit er von der SEM-Software analysiert werden kann.
- Schränken Sie die Laufzeitfähigkeiten von Komponenten ein: Stellen Sie sicher, dass sie keine privilegierten Aktionen ausführen müssen, und sorgen Sie für eine angemessene Containerisierung.
10. Bleiben Sie tadellos: arbeiten Sie zusammen und entwickeln Sie sich weiter
Die Erstellung von Software, die Wartung von Software und der Betrieb der komplexen Systeme, die wir heute verwenden, sind keine leichte Aufgabe. Das bedeutet, dass Fehler gemacht werden und unvorhergesehene Dinge werden passieren. Diese Ereignisse können oft zu Sicherheitsvorfällen führen, wenn sie nicht frühzeitig erkannt werden.
Als Antwort auf diehese Um auf diese Ereignisse schnell reagieren zu können, ist es wichtig, in einer Kultur der Tadellosigkeit zusammenzuarbeiten, um eine ständige Kommunikation über die gemachten Fehler zu gewährleisten. Es kommt darauf an, wie Sie auf unvorhergesehene Ereignisse reagieren und wie Sie das Gelernte umsetzen. So verbessern Sie Ihre Widerstandsfähigkeit als Person, als Team und als Organisation.
Update 18. Dezember :
Abschnitt "Update: Welche Sicherheitslücken gibt es?" hinzugefügt. U Aktualisierung der Abschnitte 2, 3 und 7: Der Wortlaut wurde etwas klarer formuliert, die verschiedenen CVEs wurden hinzugefügt, um eine klare Unterscheidung zwischen den jeweiligen Problemen zu treffen, und der Schwerpunkt wurde auf das Upgrade auf Version v2.16.0 gelegt. (oder v2.12.2 für Java 7) und weniger auf das in v2.17.0/v12.12.3 behobene DoS-Problem.
Verfasst von
Jeroen Willemsen
Typical security jack-of-all-trades. Hands-on security architect with a nack for security, automation, and risk management. Jeroen has been involved in various OWASP projects. He enjoys a pentest every now and then, while helping organizations to get secure enough. Jeroen is often engaged in knowledge sharing through talks, blogs, projects at github, and trainings. Want to reach out? Check his allmylinks page.
Unsere Ideen
Weitere Blogs
Contact
Let’s discuss how we can support your journey.