Wie es zu dieser Sicherheitslücke gekommen ist und was Security-Teams jetzt tun müssen, um vorbereitet zu sein, erklären wir in diesem Artikel.
- Was ist überhaupt log4j?
- Was ist passiert?
- 3 Gründe, warum die Sicherheitslücke so gefährlich war
1 Log4j ist überall und keiner weiß wo
2 Keine Notfallpläne und fehlende Verantwortlichkeiten
3 Fehlende Übersicht über die Komponenten in der Software - Welche 3 Maßnahmen jetzt umgesetzt werden müssen
1. Was ist eigentlich Log4j?
Log4j ist eine Bibliothek in Java, welche zum Logging von Anwendungsmeldungen genutzt werden kann. Ähnlich wie in einem Logbuch, werden die gesammelten Informationen dort protokolliert und dokumentiert. Log4j findet sich in den allermeisten Java Programmen als De-Facto-Standard und ist dadurch auch innerhalb von Unternehmensanwendungen eine der meistgenutzten Programmbibliotheken.
2. Was ist passiert?
Entdeckt wurde die Sicherheitslücke zum ersten Mal auf Onlineservern des Microsoft Onlinespiels Minecraft. Seitdem ein Hacker die Informationen dazu veröffentlicht hat, sind IT-Sicherheitsfirmen und Java-Nutzer damit beschäftigt, die Sicherheitslücke in ihren Systemen zu beheben.
Die Schwachstelle Log4Shell in der Java Bibliothek, oder CVE-2021-44228, bietet dem Angreifer beliebig viele unterschiedliche Angriffsmöglichkeiten. So hatte er die Möglichkeit, einzelne Programme auszuführen oder zu manipulieren, aber auch das System komplett zu übernehmen. Dafür war keine Authentifizierung nötig und konnte problemlos aus der Ferne ausgeführt werden. Aus diesem Grund, und weil Log4J in vielen Unternehmen an mehreren Stellen verwendet wird, stufte die BSI die Schwachstelle als kritisch ein und sprach die IT-Bedrohungslage „Rot“ aus.
3. 3 Gründe, warum die Sicherheitslücke so gefährlich ist
In der weltweit verbreiteten Programm-Bibliothek wurde eine riesige Sicherheitslücke entdeckt, die im Extremfall eine komplette Übernahme des Systems zur Folge haben kann. Stand jetzt ist die große Angriffswelle zwar ausgeblieben, das eigentliche Problem aber ergibt sich durch die hochgradig dynamische Gefahrenlage. 3 Gründe haben dazu geführt, dass Log4j eine so große und verbreitete Gefahrensituation darstellt:
3.1 Log4j ist überall und keiner weiß wo
Die Log4j-Bibliothek hat sich zum De-Facto-Standard entwickelt. Als vielseitige, plattformübergreifende Bibliothek läuft sie auf verschiedenen Betriebssystemen wie Windows, Linux und macOS. Java – und damit Log4j – kommt beispielsweise bei Webcams, Navigationssystemen von Autos und in Parkuhren zum Einsatz. Das Problem: Viele IT-Administratoren wissen nicht, in welchen und wie vielen ihrer Applikationen Log4j verwendet wird. Diese fehlende Übersicht erschwert es dem Nutzer, Schwachstellen zu patchen und zu updaten um die Sicherheitslücke zu schließen.
3.2 Keine Notfallpläne und fehlende Verantwortlichkeiten
Die Implementation eines IT-Notfallplans ist ein Muss, wenn es um Sicherheitsangriffe geht. Ein IT-Notfallplan ist eine Sammlung von durchzuführenden Maßnahmen und Anweisungen und zeigt, wer was in welchem Fall zu tun hat. Bei Log4j galt es, innerhalb kürzester Zeit mögliche Einfallstore für Angreifer zu schließen, um einen Infiltration und Abfluss vertraulicher Daten zu verhindern. Der Notfallplan funktioniert hierbei wie eine Art Checkliste, die in zeitkritischen Situationen konkrete Anweisungen zum Handeln liefert und jede mögliche Eventualität mit einbezieht und absichert.
Geklärte Zuständigkeiten und ein festgelegter Prozess zur Problembeseitigung sind immens wichtig um Sicherheitslücken so schnell wie möglich zu schließen.
3.3 Fehlende Übersicht über die Komponenten in der Software
Bevor ein Projektteam die betroffene Software überarbeiten, eine Sicherheitslücke beheben oder einen Patch releasen kann, muss eine wichtige Frage beantwortet werden: In welchem Projekt ist die betroffene Software und wer ist für den Betrieb zuständig und kann den Patch erstellen?
Um diese Frage beantworten zu können, ist ein aktuelles Verzeichnis aller Inhalte und Komponenten in der verwendeten Software nötig, auch bekannt als Software-Bill-of-Materials.
Diese Übersicht allerdings fehlt bisher an den meisten Stellen. Der Sicherheitsvorfall Log4j und ähnliche, beispielsweise SolarWind 2020, haben dennoch einen großen Teil dazu beitragen, dass das Risikobewusstsein geschärft wurde. Seitdem sucht die Softwareindustrie verstärkt nach neuen Lösungsansätzen für die erfolgreiche und sichere Entwicklung und Wartung von Software.
Die Ursachen für eine mangelnde Dokumentation und Übersicht der Inhalte in verwendeter Software sind unterschiedlich. Die Vorteile, die eine verlässliche Auflistung der Komponenten im Sinne der Software-Bill-of-Materials mit sich bringt, sind weltweit und Unternehmensübergreifend klar ersichtlich und stehen außer Frage.
4. Welche 3 Maßnahmen es jetzt umzusetzen gilt
Was müssen IT-Spezialisten und Entwickler jetzt tun, um Angriffe von Dritten auf ihre Unternehmensinfrastruktur zu verhindern?
Weil die Pflege der eigenen Systeme konsequent durchgeführt werden muss, hat das Security-Experten Team von iteratec diese 3 wichtige Maßnahmen definiert, die jetzt schon helfen können, sich vor weiteren Sicherheitslücken zu schützen:
- Konsequente Systemhygiene umsetzen
Der wohl wichtigste Aspekt. Um sicherzustellen, dass Daten sauber, dedupliziert, organisiert und korrekt sind, braucht es Daten- und Systemhygiene. - Nofallplan bereithalten
Wer macht was und wann im Falle einer Sicherheitslücke? Die Antworten auf kritische Fragen zur Zuständigkeit und dem Ablauf in einer Gefahrensituation sind in einem Notfallplan festgelegt und verhindern, dass im Ernstfall wichtige Zeit verloren geht. - Security Know-How in das Unternehmen tragen
Damit jedes Projektteam selbst betroffene Systeme und Sicherheitslücken identifizieren kann, nimmt das Security-Team die Enabler-Position ein und stellt dem Unternehmen Informationen und Handlungsanweisungen bereit. In zeitkritischen Gefahrensituationen kann das eine erfolgsentscheidende Wirkung haben, dadurch dass keine Einschätzung des Einzelnen mehr nötig ist und das Projektteam den Patch selbstständig erstellen und releasen kann.
Weil es so simpel ist, remote ausführbaren Code über Log4j zu installieren, ist die Situation äußerst ernst. Angreifer nutzen Log4j als Einfallstor, um sich Zugriff zur Unternehmensinfrastruktur zu verschaffen. Die eigentlichen Angriffe können also noch folgen, weil Angreifer zunächst möglichst unauffällig einen Fuß in die Tür der Systeme gebracht haben. Unter Umständen können Angriffe, die in der nächsten Zeit starten, nicht mehr als Folge eines Eindringens über Log4j erkannt werden. Ein Grund mehr, sich jetzt mit den Maßnahmen zu befassen, die es Dritten erschweren, Zugriff auf geschützte Systeme zu erhalten.
Noch Fragen?