Log4j: Warum die Sicherheitslücke die vernetzte Welt noch auf Jahre beschäftigen wird

Warum ist die Log4j Sicherheitslücke so bedrohlich?

Diese Sicherheitslücke ist aufgrund der Art der Verbreitung von Log4j so besonders und gleichzeitig gefährlich. Log4j ist ein Java-Framework, das eine einzelne Funktion bereitstellt. Hierbei handelt es sich um das Loggen von Anwendungsmeldungen. Log4j hat sich als de-facto Standard für die Aufzeichnung von Anwendungsmeldungen etabliert. Viele Anwendungen benötigen eine solche Funktion.

Gleichzeitig ist Log4j Open-Source. Viele Programmierer greifen auf solche Open-Source-Komponenten zurück, um die gewünschte Funktion in ihrem Endprodukt bereitzustellen. Dies spart Zeit und liefert zuverlässige Funktionen. Aus diesem Grund ist das Framework in einer großen Zahl von Programmen integriert. Damit nicht genug, ist Log4j auch direkt in zahlreichen Hardwarekomponenten integriert, als Teil der Basisfunktionen der Firmware. Das Logging von Meldungen ist eine der Funktionen, die zahlreiche Geräte benötigen. Dazu gehören unter anderem Router und Hardware in Netzwerken generell sowie auch IoT- und Embedded-Systeme. Erschwerend kommt hinzu, dass Log4j seit 2013 existiert. Dementsprechend weit reicht die Sicherheitslücke zurück und alle Systeme, die ab diesem Zeitpunkt auf das Log4j-Framework zurückgegriffen haben, sind betroffen.

Die Integration des Java-Frameworks in eine Vielzahl vor Programmen und Hardware sorgt dabei für die eigentliche Gefahr. Für Nutzer ist es unmöglich festzustellen, ob Log4j Teil der genutzten Software ist oder nicht. Dies betrifft vor allem Unternehmen und Organisationen. Die eigene IT-Infrastruktur besteht aus einer sehr großen Anzahl an verschiedenen Softwareplattformen und Hardwaresystemen. Da Log4j keine eigenständige Software ist, wie beispielsweise Microsoft Office oder ein FTP-Client, stehen die Administratoren in Organisationen vor der unmöglichen Aufgabe, herauszufinden, ob Log4j Teil der eingesetzten Systeme ist.

Warum ist das Updaten von Log4j so schwer?

Die meisten Sicherheitslücken in Programmen sind innerhalb weniger Tage nach Bekanntwerden geschlossen. Der Hersteller der Software bringt einen Patch heraus, der sich in vielen Fällen sogar automatisch selbst installiert.

Zuständig für Log4j ist das Apache-Projekt und dieses hat ebenfalls in kürzester Zeit die Lücke in Log4j geschlossen. Das Update 2.15.0 erschien im Dezember 2021 und unterbindet die Sicherheitslücke in dem Framework.

Jedoch müssen alle Anwendungen, die Log4j als Komponente integriert haben, eine Aktualisierung vornehmen und dieses Update dann verteilen, da Log4j keine eigenständige Software ist. Das bedeutet, dass Programme weiterhin angreifbar sind, wenn sie die veraltete Log4j-Bibliothek beinhalten.

Stellen die Herausgeber der Software kein Update bereit, bleibt die veraltete Log4j-Version im Einsatz. Administratoren stehen deshalb aktuell vor der Aufgabe, Systeme zu identifizieren, die Log4j nutzen. In der Praxis ist dies schwerer, als auf den ersten Blick erscheint. Wer über die Paketverwaltung nach „log4j-core“ sucht, erhält zwar einen Überblick über die vorhandenen Bibliotheken und deren Versionen. Dann gibt es die Möglichkeit, nach Updates für diese Software zu suchen oder die betreffenden Programme zu deaktivieren.

In einigen Fällen haben die Herausgeber jedoch auch modifizierte Versionen eingesetzt und diese umbenannt. Dann liefert eine Suche keine Ergebnisse. Hinzu kommt erschwerend, dass die moderne IT-Infrastruktur sehr fragmentiert ist. Eine besondere Herausforderung sind Microservices, die in Containern laufen. Diese verfügen über eigene Bibliotheken, die in dieser Umgebung laufen. Zwar ist der Schaden bei einem Angriff auf einzelne Anwendungen in isolierten Containern begrenzt, jedoch sorgt ein erfolgreicher Angriff auch hier für eine Störung des Betriebs oder kann folgenschwere Datenverluste mit sich bringen. Abhängig von der Anwendung haben Cyberkriminelle so auch die Möglichkeit, wertvolle oder personenbezogene Daten zu entwenden.

Der Anbieter der Container-Software Docker hat bereits am 11. Dezember 2021 ein Plugin herausgebracht, mit dem sich die eigenen Container nach einer Log4j-Installation durchsuchen lassen. Jedoch findet dieser Scan die Bibliotheken nur dann, wenn diese nicht in einem Java-Archiv verpackt sind. Aus diesen Gründen liefert die Suche nach der Log4j-Version kein absolut verlässliches Ergebnis, ist jedoch ein erster und wichtiger Schritt bei der Identifizierung von verwundbaren Plattformen.

Somit haben Administratoren bei Software noch die Möglichkeit, auf die Situation zu reagieren. Größere Sorgen bereiten Netzwerkkomponenten mit integrierter Software. Bei diesen besteht in der Regel kein Zugriff auf die Software. Somit sind Nutzer auf Updates des Herstellers angewiesen. Cisco, die für professionelle Netzwerktechnik bekannt sind, haben bereits erste Patches für die eigene Hardware herausgebracht, ebenso Ubiquiti. Beide Hersteller haben gleichzeitig bestätigt, dass eigene Produkte betroffen und anfällig sind. Bei einigen Produkten von Cisco wird es jedoch noch bis in das Jahr 2022 dauern, bis Sicherheitsupdates zur Verfügung stehen.

An dieser Stelle zeigt sich die ganze Dimension der Sicherheitslücke. Betroffen sind nämlich alle Versionen von Log4j ab 2.0-beta9 bis zur Version 2.14.1. Dies deckt einen Zeitraum von September 2013 bis Dezember 2021 ab. Alle Software oder Hardware, die Log4j nutzt und während dieses Zeitraums von über acht Jahren veröffentlicht wurde, ist betroffen. In vielen Fällen veröffentlichen die Anbieter längst keine Updates mehr für die eigenen Produkte oder sie existieren gar nicht mehr. Dies kann beispielsweise auf ältere Netzwerktechnik zutreffen. Dann ist es unmöglich für Nutzer, die Sicherheitslücke zu schließen.

Was bedeutet die Lage für die Zukunft?

Aktuell lässt sich nicht abschätzen, wie viele Programme und Netzwerkkomponenten betroffen sind. Die manuelle Überprüfung ist zeitaufwendig, kompliziert und liefert kein verlässliches Ergebnis. Aus diesem Grund sind sich IT-Sicherheitsexperten einig, dass die Sicherheitslücke in Log4j noch viele Jahre lang als Tor für Cyberattacken ausgenutzt werden wird. Außerdem wurde der Exploit in erster Instanz von professionellen Hackern für gezielte Attacken genutzt. Dazu gehören beispielsweise die Datenspionage oder die heimliche Einrichtung einer Backdoor. Bleiben solche Aktionen unentdeckt, drohen in der Zukunft Attacken über die bereits gelegten Zugänge – unabhängig vom Log4j-Status.

Dadurch, dass der Angriffsvektor jetzt öffentlich bekannt ist, kennen nun obendrein alle Kriminellen die Methode. Somit ist damit zu rechnen, dass das Angriffsvolumen steigt und wahllos Nutzer den Attacken zum Opfer fallen. Bei Angriffen von regulären Cyberkriminellen ist es zudem wahrscheinlich, dass diese vermehrt auf Erpressungen mit Ransomware setzen, was zu deutlich höheren, direkten Schäden an der IT-Infrastruktur führt.

Welche Möglichkeiten gibt es, sich zu schützen?

Administratoren und Verantwortliche befinden sich in einem Wettlauf mit der Zeit und den Cyberkriminellen. Das Schadenspotenzial ist enorm, denn Angreifer haben über die Lücke die Möglichkeit, sich volle Zugangsrechte zu verschaffen und Ransomware-Attacken einzuleiten.

Im ersten Schritt ist es wichtig, Systeme für die Angriffsfrüherkennung einzusetzen, sofern dies noch nicht der Fall ist. Solche Lösungen scannen aktiv die Aktivitäten im Netzwerk und suchen nach auffälligen Aktionen. Dies geschieht permanent und in Echtzeit. Zu den Aktivitäten, die Systeme zur Angriffsfrüherkennung finden, gehören auch die Angriffsversuche auf die Log4j-Schwachstelle. Dies geschieht mit speziell modifizierten Zeichenketten, mit denen Angreifer die Sicherheitslücke ausnutzen. Ebenfalls greifen die Angreifer dann auf das Netzwerk zu und führen verdächtige Aktionen durch. Solche Aktivitäten sind in den Logs von Netzwerkgeräten und Programmen sichtbar. Eine manuelle Kontrolle ist jedoch aufgrund der Menge an Daten unmöglich. Software für die Angriffsfrüherkennung übernimmt diese Aufgabe und überwacht selbst komplexe Netzwerke in Echtzeit.

Der Active Cyber Defense Service (ACD) von secion ist eine solche Dienstleistungslösung. secion stellt diesen Service über das Netzwerk bereit. Eine lokale Installation oder Veränderungen an den Systemen sind somit nicht notwendig. Der ACD Service von secion kontrolliert alle Systeme innerhalb eines Netzwerks, von Datenbanken über Dienste für die Authentifizierung bis hin zu IoT-Geräten am Rande des Netzwerks und meldet identifizierte Anomalien. Das secion Analystenteam informiert bei Bedarf unverzüglich die zuständigen Personen in der IT Security des betreffenden Unternehmens. Auf diese Weise ist eine Aufdeckung von Angriffen nahezu in Echtzeit möglich, bevor Schaden entsteht - und ohne dass enorme Investitionen in der eigenen IT-Abteilung notwendig sind.

Die zweite Aufgabe ist es, möglichst viele der verwundbaren Systeme zu identifizieren. Dies ist zwar eine arbeitsintensive Aufgabe, es gibt jedoch aktuell keine Alternative dazu, um die betroffenen Systeme zu finden. Für den Test der eigenen Netzwerkkomponenten steht auf canarytokens.org eine Methode zur Verfügung. Hier lassen sich harmlose JNDI-Aufrufe, die wie die Angriffe auf die Log4j-Lücke aufgebaut sind, an die Netzwerkgeräte senden. Reagieren diese und sind somit verwundbar, ist es möglich, die Geräte sofort aus dem Betrieb zu entfernen. Eine vollständige Sicherheit bietet jedoch auch diese Methode nicht.

Brauchen Sie Unterstützung, um Ihre IT Security für 2022 aufzurüsten? Kontaktieren Sie uns!