Bedrohungslage durch Log4J-Sicherheitslücke hält weiter an

Die Bedrohungslage durch die Log4j-Sicherheitslücke hält weiterhin an – wie kann das sein, nachdem am die Sicherheitslücke nun bereits seit Anfang Dezember bekannt ist und in der Softwarebibliothek selbst seit Ende Dezember (nach mehreren Anläufen) behoben ist?

Wir möchten in diesem Artikel zusammenfassen, was passiert ist und warum die IT-Branche noch lange damit beschäftigt sein wird. Am Ende möchten wir noch einige Handlungsempfehlungen geben, wie man abklären kann, ob man von der Schwachstelle betroffen ist und was man dagegen tun kann.

Log4J – Was ist das?

Log4J ist eine Protokollierungs-Software-Bibliothek für JAVA der Apache Foundation, welche in vielen Anwendungen integriert ist. Log4J dient in erster Linie dazu, Softwaremeldungen (Fehler- und Statusmeldungen, Anmeldeversuche etc.) aufzuzeichnen. Durch die Integration in vielen Programme und Programmteilen, welche wiederum von anderen Programmen verwendet werden, ist Log4J in einer Vielzahl von Standardsoftware zum Betrieb von Webservern, IoT-Devices und vielem mehr enthalten, meist ohne Wissen der jeweiligen Endnutzer.

Diese weite Verbreitung (geschätzt 3 Milliarden Systeme), die Schwere der Sicherheitslücke und die Tatsache, dass die Sicherheitslücke in jeder veröffentlichten Version der letzten Jahre enthalten war, sind auch der Grund für die hohe Einstufung der Kritikalität der Sicherheitslücke.

Die Integration in viele Softwareprodukte bedeutet, dass in vielen Fällen für den Endnutzer selbst keine Möglichkeit besteht, die Sicherheitslücke direkt zu beheben, sondern auf entsprechende Softwareupdate des Herstellers warten muss. Für viele Software-Produkte oder auch teilweise Netzwerk-Hardware (Router, Switches, NAS etc.), die evtl. schon mehrere Jahre alt sind und von der Herstellern nicht mehr gewartet werden, ist nicht klar, ob entsprechende Sicherheitsupdates überhaupt erscheinen werden.

Bin ich betroffen?

Extern erreichbare Systeme kann man mithilfe einer Vielzahl von nun erschienen Log4J-Scannern bekannter IT-Sicherheitsfirmen scannen. Auch kostenlose Scanner werden angeboten.

Für interne Systeme bieten die Sicherheitsfirmen auch entsprechende Offline-Scanner an.

Es sollte natürlich immer die Vertrauenswürdigkeit der entsprechenden Scanner geprüft werden, um sich hier nicht mit Schadsoftware zu infizieren – es wäre nicht das erste mal, dass sich hier sog. “Sicherheits-Software” aus unbekannten Quellen am Ende als Schadsoftware heraus stellt.

Was kann ich tun?

Viele Softwarehersteller haben bereits Updates oder Fixes für ihre Produkte veröffentlicht. Laut BSI hat sich deshalb das mit der Schwachstelle verbundene Sicherheitsrisiko seit seiner letzten Bewertung deutlich verringert. Dies ist wohl auch der hohen medialen Aufmerksamkeit, die diese Sicherheitslücke in den letzten Wochen genossen hat, zu verdanken.

Voraussetzung ist natürlich immer, dass die eigenen Systeme mit diesen Updates gepatcht werden. Die eigene IT-Abteilung oder der beauftragte IT-Dienstleister sollten hierzu Auskunft geben können.

Da die Schwachstelle international bereits ausgenutzt wird ist es höchste Zeit, sich des Thema anzunehmen, so es noch nicht geschehen ist – die ursprünglich vermutete Angriffswelle über Weihnachten, welche diese Sicherheitslücke ausnützt ist zwar nicht gekommen, es kann aber jederzeit soweit sein.

Für betroffene Systeme sollte man den Handlungsempfehlungen vertrauenswürdiger Stellen folgen:

CERT.at GmbH – https://www.cert.at/
Bundesamt für Sicherheit in der Informationstechnik – https://www.bsi.bund.de/
Cybersecurity & Infrastructur Security Agency – https://www.cisa.gov/uscert/

Wie wird es angesichts dieser Entwicklungen weitergehen?

IT-Sicherheitslücken wird es immer geben, solange Software entwickelt wird. Software-Entwicklung in der heutigen Zeit besteht zum Großteil aus dem Zusammenfügen von bestehenden Komponenten. Aufgrund der bereits bestehenden Komplexität dieser Bauteile ist einen umfassende Überprüfung dieser Softwarebibliotheken durch einzelne Entwickler kaum möglich.

Viele Open-Source-Projekte sind gut entwickelt und gepflegt, aber sie sind für Anfänger oft schwierig zu benutzen. Wenn Entwickler Funktionen aus Bibliotheken von Drittanbietern importieren, erkennen sie oft nicht, dass diese Funktionen möglicherweise anfällig für Angriffe sind. Insbesondere wird es schwierig, wenn sich wie im Fall von Log4J eine Lösung zu einem Quasi-Standard entwickelt und auf breiter Front eingesetzt wird. Gerade solche Standard-Software wird auch gerne zum Ziel für Angreifer, da es weitaus lohnender ist, auf weit verbreitete Sicherheitslücken zurückzugreifen, als sich mühsam den Weg in ein Einzelsystem zu erarbeiten.

Kurzfristig ist daher mit ähnlichen Sicherheitslücken zu rechnen und dahingehend muss auch die eigenen IT-Sicherheitsstrategie ausgerichtet sein. Es wird weiterhin notwendig sein, im Bereich IT-Security kurze Reaktionszeiten zu gewährleisten, wenn über die nächste Sicherheitslücke berichtet wird. Dahingehend ist es lohnend, oben genannten Stelle jedenfalls regelmäßig zu besuchen – wenn die Themen in den Mainstream-Medien aufschlagen, kann es unter umständen bereits zu spät sein.

Mittel- und langfristig ist sicherzustellen, dass bei der Verwendung von eigener und Dritt-Software darauf geachtet wird, dass diese nach Standards entwickelt wird, die im Entwicklungsprozess auch Dokumentation und Sicherheitsprüfungen sicherstellen, idealerweise nicht durch den Entwickler selbst, sondern durch Spezialisten, welche sich mit Sicherheitsfragen im Bereich der Softwareentwicklung auseinander setzen.

Auch wenn dann noch immer keine 100%ige-Sicherheit gewährleistet werden kann, stellt dieser Prozess sicher, dass im Falle einer entdeckten Lücke durch die Dokumentation dann schnell bzw. überhaupt reagiert werden kann.