Log4j-Schwachstelle Log4Shell
Jackpot für Kriminelle
Fortsetzung des Artikels von Teil 1
Sisyphusarbeit
Das ist leichter gesagt als getan: Das Schließen einer so verbreiteten Lücke ist ein Vorhaben, das IT-Organisationen über Wochen und Monate hinweg beschäftigen kann. Wie ernst die Lage ist, zeigt der Umstand, dass in den USA die Federal Trade Commission (FTC) dortige Unternehmen zum schnellstmöglichen Patchen aufruft und droht: „Die FTC beabsichtigt, ihre rechtlichen Befugnisse voll auszuschöpfen, um gegen Unternehmen vorzugehen, die keine angemessenen Maßnahmen ergreifen, um Verbraucherdaten künftig vor der Gefährdung durch Log4j oder ähnliche bekannte Schwachstellen zu schützen.“ Diese Mahnung der US-Behörde war laut Tenable-Chef Yoran „längst überfällig“, denn: „Die Nichtbehebung von Log4j ist schlimmer, als wenn Sie Ihre Türen und Fenster unverschlossen lassen und einen Eindringling einladen, Ihre Regale zu plündern. Dadurch werden nämlich auch die Daten, die so viele Unternehmen über Einzelpersonen sammeln, gefährdet.“ Die Log4j-Schwachstelle nicht zu beheben, so Yoran, sei „geradezu die Definition von Fahrlässigkeit“.
Verantwortliche allerorten fragen sich: Haben wir Log4j im Einsatz? In der modernen DevOps-Welt mit Downloads von öffentlichen Repositories und zahllosen Abhängigkeiten der Komponenten ist die Antwort auf diese Frage laut Experten oft nicht sofort ersichtlich: „Die Schwierigkeit für viele Unternehmen besteht derzeit darin, zu identifizieren, ob sie Log4j im Einsatz haben und in welcher Konfiguration“, so Dr. Sebastian Schmerl, Director Security Services EMEA bei Arctic Wolf. „Das kann ohne aktives Monitoring, ein Software-Inventory oder ein Vulnerability-Scanning oftmals nicht einfach beantwortet werden.“ Das BSI stellt deshalb eine Anleitung zur Erkennung und Behebung der Schwachstelle bereit.
„Zuerst sollten Unternehmen prüfen, ob eine Version von Log4j vor 2.15.0 verwendet wird, auch in den Abhängigkeiten“, rät Jonathan Tanner, Security-Forscher bei Barracuda Networks. „Sowohl Maven als auch Gradle – beides auf Java basierende Build-Management-Tools – bieten die Möglichkeit, den gesamten Abhängigkeitsbaum für ein Projekt auszudrucken.“ Auf diese Weise lasse sich feststellen, ob eine verwundbare Version von Log4j im Einsatz ist oder nicht.
Mit dem Stopfen der Sicherheitslücke allein ist es dabei längst nicht getan – ähnliche Schwachstellen könnten schließlich jederzeit wieder auftreten. Zum reinen Nachbessern an den Java-Anwendungen gesellen sich deshalb diverse weiterreichende Konsquenzen. So hagelte es in den Wochen vor Weihnachten Kommentare, Empfehlungen und Hinweise von Security-Anbietern, wie man in dieser brenzligen Lage vorgehen sollte. Doch Verteidigungsmaßnahmen sind laut Lothar Hänsler, COO beim Wiener MSSP Radar Cyber Security, nicht so einfach umzusetzen: „Dies liegt unter anderem daran, dass alle Mitigationsstrategien Risiken und Nebenwirkungen für die Applikationen haben können, die von der Schwachstelle betroffen sind“, so Hänsler. Deshalb gebe es in Fachkreisen „unterschiedliche Sichtweisen zu den Mitigationsstrategien“.
Viele Anbieter nutzen die Gelegenheit, auf den Wert ihrer eigenen Security-Lösungen für diese Mitigationsstrategien hinzuweisen. In der Tat kann praktisch die gesamte Bandbreite der Security-Lösungen von der Code-Qualitätskontrolle im DevOps-Einsatz bis hin zu EDR, NDR und XDR (Endpoint/Network/Extended Detection und Response) zum Aufspüren von Angriffsversuchen hier ihre Schlagkraft unter Beweis stellen. Talos empfiehlt den Unternehmen darüber hinaus die Aktualisierung von Incident-Response-Plänen und Playbooks oder eine Tabletop-Übung, um ihre Reaktionsfähigkeit bei derlei Vorfällen zu testen.
Lesen Sie mehr zum Thema
