Log4Shell-Lücke: Was macht sie so gefährlich und was kann man dagegen tun?

Lesezeit

3 Minuten

zuletzt aktualisiert

13

.

 

September

 

2024

>

>

Log4Shell-Lücke: Was macht sie so gefährlich und was kann man dagegen tun?

Ein neues Schreckgespenst in der IT-Welt

Will man es harmlos ausdrücken, spukt wieder einmal ein neues Schreckgespenst durch die Security-Welt der IT. Die Java-Bibliothek log4j droht ein ernsthaftes Problem für unzählige Systeme und Programme zu werden (National Vulnerability Database -NVD- CVE-2021-44228). Betroffen sind die Java-log4j-Bibliotheken ab der Version 2.0.1 bis 2.14.x (Version 2.15.0 ist bereits gefixt, enthält aber weitere Sicherheitslücken, Version 1.x ist nicht betroffen). Mittlerweile steht auch die Version 2.16.0 zur Verfügung, welche unbedingt verwendet werden sollte. Ein Update auf die neueste Version ist, wo immer möglich, dringendst empfohlen.

Um Irrtümer zu vermeiden – die log4j ist eine Bibliothek der Apache Software Foundation (Open Source Software), die nicht automatisch von jeder Java-Version genutzt oder mitinstalliert wird. Um log4j auf die neueste Version zu bringen, reicht es daher nicht aus, einfach die neueste und aktuelle Java-Version zu installieren. Die aktuelle Version der log4j-Bibliothek finden Sie auf der Webseite von Apache.

Auch das BSI (Bundesamt für Sicherheit in der Informationstechnik) hat bereits am Wochenende die Warnstufe Rot ausgerufen (IT-Bedrohungslage 4). Dies bedeutet, dass die IT-Bedrohungslage als extrem kritisch eingestuft wird. Als Folge davon sind sowohl der Ausfall vieler Dienste als auch der Regelbetrieb nicht möglich.

Der Einsatz einer betroffenen Java-Version bedeutet nicht zwangsläufig, dass das Problem vorhanden ist. Das Programm oder das Gerät, das diese Versionen nutzt, muss auch die Protokoll-Funktion aktiviert haben. Wird diese Funktion nicht genutzt, ist man auf diesem Gerät oder System erstmal sicher. Das Problem dabei ist aber, dass man nicht einfach so überprüfen kann, ob die Java-Funktion verwendet wird oder nicht. Eine etwaige Protokollierung kann auch anders erfolgen und muss nicht zwangsweise über die Java-Bibliothek log4j laufen.

Um es kurz zu umschreiben: Die betroffenen Geräte oder Programme müssen nicht einmal selbst direkter Teil des Angriffs sein. Denn wird von einem System die Log-Funktion der Java-Bibliothek log4j eingesetzt, protokolliert diese nicht nur die Geschehnisse, sondern versucht den Protokolltext auch zu interpretieren. Dabei kann es sich um Software handeln, die zum Beispiel mit dieser Log-Bibliothek E-Mails protokolliert, wie etwa ein internes Ticketsystem.

Hier kann durch den Interpreter ein externer Server kontaktiert werden, von dem aus das Gerät Java-Code akzeptiert.

Eine genauere Analyse des Problems finden Sie auch bei den IT-Spezialisten von heise.de.

Docusnap ist nicht von dem Problem betroffen

Auch unsere Docusnap-Experten haben sich als Erstes daran gemacht, mögliche Angriffspunkte in Docusnap zu überprüfen. Daher dürfen wir an dieser Stelle gleich vorweg mitteilen, dass Docusnap nicht von der Schwachstelle betroffen ist. Weder die Serverkomponenten noch das Frontend sind durch die Attacken angreifbar. Diese Java-Technologie wird in unserer Dokumentationssoftware nicht verwendet.

Java ist sehr stark verbreitet

Auch wenn wir als Entwickler von Docusnap nicht direkt davon betroffen sind und sich keiner unserer Kunden diesbezüglich Sorgen machen muss, besteht in den eigenen IT-Netzwerken und IT-Systemen eine reale Gefahr durch die Vielfalt und enorme Anzahl an eingesetzten Systemen und Programmen. Selbst große und verbreitete Anbieter, wie zum Beispiel VMware, verwenden betroffene Java-Bibliotheken zur Protokollierung.

Ob ein System tatsächlich betroffen und dadurch verwundbar ist, versuchen die Hersteller der Geräte und Software aktuell abzuklären. Dies kann unter Umständen Wochen oder gar Monate dauern. Und dabei ist es nicht garantiert, dass auch alle älteren Geräte, die diese Log-Funktion von Java nutzen, in nächster Zukunft ein Update erhalten oder überhaupt in diversen Listen gefunden werden.

Dadurch verbreitet sich derzeit sehr viel Unsicherheit unter den IT-Verantwortlichen und es stellen sich wichtige Fragen: Können wir unseren Systemen trauen? Sind unsere Systeme betroffen? Und wenn ja, wie spüren wir diese auf?

Die von einigen bei solchen Vorfällen an den Tag gelegte Vorgehensweise, nämlich das Aussitzen der Gefahr, ist wie schon bei den Exchange-Exploits vom Frühjahr keine gute Idee.

Erste Maßnahme – Bestandsaufnahme: Was haben wir alles im Einsatz?

Bei einer professionell geführten IT-Abteilung existieren zumindest eine genaue Dokumentation und eine Inventarisierung aller eingesetzten IT-Systeme. Als ersten Schritt gilt es nämlich festzustellen, welche Geräte im eigenen IT-Netzwerk (und auch in den einzelnen Standorten) im Einsatz sind. Dabei sind nicht nur der Hersteller und die Gerätebezeichnung nötig, sondern in diesem Fall auch die Versionsnummern der Geräte-Firmware ausschlaggebend. Sind diese Informationen nicht in der Dokumentation verfügbar, beginnt auch schon die erste Maßnahme für die IT-Verantwortlichen. Die Feststellung, welche Geräte sich mit welcher Firmware im Einsatz befindet.

Verwendet Ihre IT dabei eine professionelle Dokumentationssoftware wie Docusnap, kann dies leicht mittels eines Berichts ausgelesen werden. Docusnap verfügt durch die automatische Inventarisierung immer über die aktuellsten Daten aller erreichbaren Geräte im Netzwerk. Dort werden nicht nur Geräteinformationen wie Name und IP-Adresse gespeichert, sondern eben auch die Firmware-Daten des Geräts.

Der nächste Schritt

Und jetzt wird es tatsächlich heikel und aufwändig. Für jedes Gerät muss festgestellt werden, ob es Java verwendet, beziehungsweise ob es die betroffene Log-Funktion der Java-Bibliotheken mit den betroffenen Versionen nutzt.

Handelt es sich dabei um Computer oder Server, ist dies oft noch leicht selbst nachzuvollziehen. Denn die betroffene Java-Bibliothek befindet sich in den JAR-Archiven von Java. Diese können mit speziellen Tools wie zum Beispiel dem log4j-detector durchsucht und aufgespürt werden. Dabei kann es sein, dass auf einem System für unterschiedliche Programme auch unterschiedliche Versionen der log4j-Bibliothek installiert sind. Dies wird von jedem Softwareanbieter unterschiedlich gehandhabt.

Mehr Schwierigkeiten bei IT-Geräten

Handelt es sich dabei um eine Appliance (also Hardware mit darauf vom Hersteller eingesetzter Software als Komplettsystem), wird es schwieriger. In der Regel hat man dort keinen Zugriff auf die internen Pakete oder Systeme. Hier muss man sich auf den Hersteller verlassen, dass dieser auch wirklich zeitnah und verlässlich alle Geräte auf dieses Problem hin überprüft – und in weiterer Folge ein Update bereitstellt. Im Gegensatz zum lokal installierten Java kann dort die Programmbibliothek schließlich auch nicht einfach ausgetauscht werden.

Test durch externe Dienste

Oder man testet die Dienste gezielt, in dem man den passenden String an das protokollierende Java-Gerät schickt. Da man dabei in der Regel aber keine Rückmeldung bekommt, hilft der Dienst CanaryTokens. Hier kann ein entsprechender Text für das log4j-Problem generiert werden, mit dem sich das damit betroffene Gerät überprüfen lässt. CanaryTokens kontrolliert, ob Java-Code abgerufen wird oder nicht.

Mit Docusnap log4j-Dateien auf Windows- und Linux-Systemen finden

Docusnap kann beim Aufspüren der Sicherheitslücke eine Menge Arbeit und vor allem kostbare Zeit einsparen. Durch die zuverlässige Suche auf allen Windows- und Linux-Systemen können möglichst schnell Gegenmaßnahmen auf den betroffenen Systemen gesetzt werden.

Docusnap Software Übersicht System
Docusnap Software Übersicht System

In unserem ausführlichen HowTo zeigen wir Ihnen, wie Sie mit Hilfe von Docusnap das log4j-Problem identifizieren und entsprechend handeln können.

Werden in Ihrem Netzwerk auch Linux-Systeme verwendet, installieren Sie bitte den Docusnap-Patch von Dezember 2021 (Version 11.0.1928.21348). Damit wird die erforderliche Erweiterung für Linux-Systeme hinzugefügt. Für die Suche auf Windows-Systemen ist keine Aktualisierung von Docusnap erforderlich.

Docusnap Software-Bericht Linux
Docusnap Software-Bericht Linux

Update vom 15. März 2022 – Mittlerweile wurde durch einen Patch in Docusnap die Suche erweitert. Es können jetzt beliebige Dateien und Softwareinstallationen auf allen Systemen gefunden werden.

Mehr Informationen in unserem Blogartikel „Systemübergreifende Datei- und Softwaresuche in Docusnap“.

Fazit

Auch die modernste Software und die neueste Hardware schützen nicht vor zukünftigen Sicherheitslücken. Allerdings kann man sich schon von Grund auf bestmöglich davor schützen und im Ernstfall, wie jetzt gerade, mit möglichst effektiven Mitteln dagegen vorgehen. Die wichtigste Waffe gegen diese Bedrohungen sind die lückenlosen und aktuellsten Daten und Informationen über das eigene IT-Netzwerk, das mittels der professionellen Dokumentationssoftware Docusnap eine rasche Abklärung der Situation ermöglicht.

Sie setzen Docusnap noch nicht ein, möchten sich in Zukunft aber eine deutliche Entspannung bei Sicherheitsproblemen dieser Art ermöglichen? Dann testen Sie doch einfach unsere 30-tägige Demo-Version – kostenfrei, unverbindlich und im vollen Funktionsumfang.

Zusatzinformationen

Hier finden Sie weitere Informationen zum Thema

Stefan Effenberger

IT-Dokumentation-Experte

Nächster Artikel