Log4j

Alarmstufe Rot wegen Java-Lücke

13.12.2021 von Martin Bayer
Eine kritische Sicherheitslücke in der Java-Bibliothek Log4j macht zahllose Systeme angreifbar. Hacker nutzen die Schwachstelle bereits aus. Das ganze Ausmaß der Bedrohungslage ist laut BSI noch gar nicht abzusehen.
Das Ausmaß des Problems in Log4j ist noch gar nicht abzusehen. Viele Unternehmen könnte die Sicherheitslücke ins IT-Dunkel reißen.
Foto: Markus Gann - shutterstock.com

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die "Warnstufe rot" ausgerufen. Die kritische Schwachstelle "Log4Shell" in der weit verbreiteten Java-Bibliothek "Log4j" führe nach Einschätzung der Security-Experten zu einer extrem kritischen Bedrohungslage. Das BSI ist deshalb so beunruhigt, weil die betroffene Java-Bibliothek weit verbreitet ist und sich die Schwachstelle daher auf unzählige weitere Produkte auswirkt. Möglicherweise seien alle aus dem Internet erreichbaren Java-Anwendungen betroffen, die mit Hilfe von Log4j Teile der Nutzeranfragen protokollieren.

Darüber hinaus sei die Sicherheitslücke für Hacker einfach auszunutzen, warnt das BSI. Ein entsprechender Proof-of-Concept sei bereits im Netz öffentlich verfügbar. Zudem kursierten Skripte, die Systeme stichprobenartig auf Verwundbarkeit hin untersuchen. Gelingt es Cyberkriminellen Log4Shell auszunutzen, können sie auf den betroffenen Systemen beliebigen Code ausführen sowie diese vollständig übernehmen und kontrollieren.

Massen-Scans auf Log4j

Dem BSI zufolge seien welt- und deutschlandweit schon Massen-Scans sowie versuchte Kompromittierungen zu beobachten. Erste Angriffe seien bereits erfolgreich gewesen, beispielsweise Attacken mit Kryptominern. Hinweise deuteten zudem darauf hin, dass die Schwachstelle auch von Botnetzen ausgenutzt werde.

Die Sicherheitslücke in Log4j macht zahlreiche Anwendungen und Services anfällig für Hackerangriffe. Darunter finden sich Dienste von namhaften Anbietern wie Amazon, Apple, Google, VMware und Twitter. Darüber hinaus reißt Log4Shell Sicherheitslöcher in populäre Open-Source-Apache-Dienste wie Druid, Flink, Solr und Struts2.

Java-Wildwuchs erschwert Abwehr

Die Liste dürfte noch länger werden. Aus Sicht des BSI ist das ganze Ausmaß der Bedrohungslage noch längst nicht absehbar. Es sei zu erwarten, dass in den nächsten Tagen weitere Produkte als verwundbar erkannt würden. Das Problem liegt auch darin, dass in vielen Softwarearchitekturen Java-Komponenten in verschiedensten Bereichen eingebaut und dort tief integriert sind. Für die Anwenderunternehmen dürfte schon allein die Identifikation, welche Teile ihrer IT-Infrastruktur von der Sicherheitslücke betroffen sind, schwierig werden. Viele Betriebe wissen nicht einmal genau, in welchen Anwendungen und Diensten welche Java-Teile verwendet werden.

Für die betroffene Java-Bibliothek Log4j liegt mittlerweile ein Sicherheits-Update vor. Allerdings müssen alle Produkte, die Log4j verwenden, entsprechend gepatcht werden. Angesichts des Java-Wildwuchses in vielen Firmen ist das kein leichtes Unterfangen. Auch für die verschiedenen Apache-Projekte dürften in den nächsten Tagen abgesicherte Versionen vorliegen. Doch auch diese müssen erst einmal flächendeckend eingespielt werden.

Höchste Alarmbereitschaf wegen Log4j

Bis dahin gilt allerhöchste Alarmbereitschaft. Das BSI hat ein Dokument veröffentlicht (PDF), wie Unternehmen auf das Security-Problem reagieren sollten und wie erste Schutzmaßnahmen implementiert werden könnten. Grundsätzlich sollten Betriebe ihre Detektions- und Reaktionsfähigkeiten kurzfristig erhöhen, um die eigenen Systeme angemessen überwachen zu können, rät das Bundesamt. Das ist auch aus dem Grund wichtig, weil sich die Schwachstelle auch mit Schadcode direkt in der Server-Abfrage ausnutzen lässt, ohne dass Malware nachgeladen werden muss. Dies gefährde auch Grundschutz-konforme Systeme, die in der Regel keine Verbindung ins Internet aufbauen könnten, warnt das BSI.

Sobald Updates für einzelne Produkte verfügbar seien, sollten diese eingespielt werden, mahnen Sicherheitsexperten. Darüber hinaus sollten alle Systeme auf eine Kompromittierung untersucht werden, die verwundbar waren. Letzteres bedeutet, dass etliche Nacharbeiten erforderlich sein dürften. Schließlich muss sich eine Kompromittierung nicht unmittelbar offenbaren. Hacker könnten über Log4Shell Schadcode einschleusen, der sich irgendwo im betroffenen System versteckt und erst später aktiv wird und sein ganzes Schadpotenzial entfaltet.