Log4j ist und bleibt auch fast drei Monate nach ihrer Bekanntgabe eine gefährliche Schwachstelle. Und selbst wenn noch keine Angriffe laufen, sollten IT-Sicherheitsverantwortliche damit rechnen, dass die Cyberkriminellen Zugang zu IT-Systemen gefunden haben.
Für eine effektive Abwehr bevorstehender Attacken wird es in den kommenden Monaten daher nötig sein, sowohl unmittelbar Schwachstellen zu lokalisieren und zu schließen als auch die eigene IT und den Netzverkehr zu beobachten.
Hacker können über die weitverbreitete Log4J-Loginbibliothek aus der Ferne Code ausführen. Die am 9. Dezember 2021 bekanntgegebene Schwachstelle CVE-2021-44228 ist vor allem durch die weite Verbreitung des De-Facto-Standards Log4J in den verschiedensten Web-Anwendungen hochgefährlich.
Viele Unternehmen wissen nicht, ob und wo sie Log4j in ihren Systemen implementiert haben. So bemerkten die Bitdefender Labs schon im Dezember 2021 konkrete Aktionen der Cyber-Kriminellen, um etwa über Botnetze Kryptominer zu installieren oder auch neue Ransomware-Attacken zu starten.
Auch wenn die große Angriffswelle offenbar noch ausgeblieben ist, ist von einer hochgradig dynamischen Gefahrenlage auszugehen. Weil es so einfach ist, über Log4j remote ausführbaren Code zu installieren, liegt eine unmittelbare Gefahr vor. Zudem nutzen die Angreifer Log4J als Einfallstor, um sich Zugriff zum Unternehmensnetz zu verschaffen.
Es ist davon auszugehen, dass die eigentlichen Angriffe also noch folgen, weil Hacker zunächst möglichst unauffällig einen Fuß in die Tür der Unternehmensnetze gebracht haben. Viele der jetzt vorbereiteten Angriffe, die in der nächsten Zeit starten, werden unter Umständen nicht mehr als Folge eines Eindringens über Log4j erkannt werden.
Unsicherheit bei Herstellern und Unternehmen
Die Log4j-Bibliothek bietet an sich eine überaus nützliche und einfache Funktion, um Anfragen auf Systeme zu protokollieren und zu bearbeiten. Deshalb hat sie sich zum De-Facto-Standard entwickelt.
Als vielseitiges, plattformübergreifendes Framework läuft sie auf verschiedenen Betriebssystemen wie Windows, Linux, macOS und FreeBSD. Java – und damit Log4J – kommt beispielsweise bei Webcams, Navigationssystemen von Autos, Terminals, DVD-Playern, Set-Top-Boxen, Medizingeräten und sogar in Parkuhren zum Einsatz.
Daraus ergibt sich aber ein Problem: Viele IT-Administratoren werden nicht wissen, welche Applikationen ihr Unternehmensnetz über Log4j ans Internet anbindet. Nicht von ungefähr belegen die Daten der Bitdefender-Telemetrie, also die Informationen von installierten Bitdefender-Systemen, dass viele Sicherheitsteams mögliche eigene Schwachstellen angehen, um zu sehen, ob sie betroffen sind.
Und mit diesem mangelnden Überblick sind sie nicht allein. Auch Software-Anbieter oder Open-Source-Projekte wissen nicht, ob ihre Produkte bzw. Projekte die Schwachstelle in sich tragen. Sie müssen sich wie alle Unternehmen ein Bild vom Sicherheitsstatus machen und informieren jetzt ihre Kunden – oder werden dies demnächst fortlaufend tun.
Fünf Tipps für den „Log4J-Marathon“ der kommenden Monate
In dieser unklaren, sich ständig ändernden Gefahrenlage müssen IT-Sicherheitsverantwortliche in Unternehmen und Managed-Security-Provider im Dienst ihrer Kunden in den kommenden Monaten eine hohe Wachsamkeit an den Tag legen. Folgende Ratschläge helfen kurz- und langfristig, Risiken zu erkennen und Angriffe zu blockieren:
- Sofort patchen und updaten, wo die Lücke bereits bekannt ist
Unternehmen sollten unverzüglich alle für ihre Anwendungen vorliegenden Patches entsprechend den Hinweisen der Software-Anbieter einspielen. Dieser Grundsatz gilt jetzt mehr denn je.
- IT-Infrastruktur und Software-Stückliste inventarisieren
Administratoren sollten ihre gesamte Infrastruktur und jede Software einem Audit unterziehen. So können sie alle Systeme identifizieren, die ein Apache Lofj2 Logging Framework implementiert haben. Anschließend erfolgt dann aktuell das Update auf die Log4j-Version 2.17.1.
- Die Software Supply Chain auf Aktualisierungen überprüfen
Sobald die IT-Administratoren wissen, welche Systeme betroffen sind, sollten sie sich ständig informieren, ob die jeweiligen Open-Source-Software-Projekte. Stellen die Anbieter kommerzieller Software-Produkte Patches bereit. Welche Maßnahmen zum Schließen der Lücke empfehlen sie?
- Systeme ohne direkten Zugang zum Internet nicht vergessen
Oberste Priorität in der Sicherheitsinventur haben natürlich Applikationen und Systeme, die direkt ans Internet angebunden sind. Aber viele Hacker nutzen dieses Eingangstor lediglich als Ausgangspunkt für Seitwärtsbewegungen, um andere Systeme anzugreifen. Daher sollten die IT-Verantwortlichen Systeme ohne direkten Anschluss ans Internet ebenso wachsam beobachten und schützen.
- Zeit für eine gestaffelte Abwehr
Log4j auszunutzen ist der erste Schritt – einen Angriff zu starten, der nächste. Das gibt den IT-Administratoren unter Umständen noch Zeit, sich darauf vorzubereiten und zu vermeiden, dass aus einer Sicherheitslücke ein tatsächlicher Sicherheitsvorfall wird. Telemetrie-Daten zeigen, welche Cyber-Sicherheitsmodule verhindern, dass Angreifer die Schwachstelle ausnutzen.
Das fängt beim Schutz auf Netzwerkebene an: Threat Intelligence bietet Informationen zur Reputation von URLs oder IP-Adressen. Aber auch die statische Malware leistet ihren Beitrag und hat Kryptominer oder bekannten bösartigen Payload installiert. Das bietet nicht nur Schutz vor diesen Angriffen.
Administratoren und Managed Security Provider sollten auch davon ausgehen, dass diese Angriffe sich weiterverbreiten. Extended Detection and Response (XDR) erkennt Seitwärtsbewegungen von einem System zum nächsten. Fortschrittliche Verfahren zur Threat Detection erkennen verdächtiges Verhalten von Abläufen. Externe Experten eines Managed-Detection-and-Response-(MDR) Dienstes helfen, Risiken und Angriffe zu erkennen.
Die Abwehr von Angriffen über Log4j wird eine langfristige Aufgabe werden. Administratoren sollten in den kommenden Monaten sehr aufmerksam Zugriffe auf ihr Netz und das Geschehen im Netz beobachten. Jede Anomalie gilt es zu überprüfen. Insbesondere sollten IT-Administratoren und Managed-Service-Provider jedes Anzeichen auf Reverse TCP Shell ernst nehmen.