Die Sicherheitslücke in der Log4j-Anwendung von Java ist eine der gefährlichsten Schwachstellen seit Jahren. Durch die Prominenz der Anwendung war fast jede Webapplikation ein potenzielles Ziel. Mit Patches und Workarounds haben IT-Abteilung und Security-Dienstleister die gröbsten Schäden eingedämmt. Unternehmen sollten solche Szenarien jedoch weiterhin ernst nehmen und die richtigen Schlüsse ziehen.
Anfang Dezember 2021 kam es zu einem digitalen Super-GAU. In einer sehr weit verbreiteten Java-Bibliothek wurde eine Sicherheitslücke entdeckt. Da die Bibliothek in irgendeiner Form in sehr vielen Java Anwendung zum Einsatz kommt, war das Schadenspotential immens.
Meldungen über den möglichen Exploit verbreiteten sich in kürzester Zeit im Internet. Security-Experten reagierten schnell und begannen umgehend damit, an Patches und Workarounds zu arbeiten. Als Massenmedien wie die Tagesschau oder der Spiegel über die Log4j-Schwachstelle berichteten, wurde auch der breiten Öffentlichkeit klar, wie ernst die Lage war.
Warum die Log4j-Lücke so gefährlich ist
Log4j ist ein Werkzeug in Java, das Log-Daten sammeln und weiterleiten kann. Wenn ein Hacker eine Information, die das Werkzeug aufsammelt, auf eine bestimmte Art formuliert, kann er es dazu bringen, beliebigen Code auszuführen. Der Hacker kann sich damit Root-Rechte auf dem System verschaffen, auf dem Log4j läuft.
Das Tückische: Selbst wenn Nutzer den Logger nicht aktiv einsetzen, sind sie keinesfalls vor der Schwachstelle sicher. Denn die Bibliothek wird meist als Teil eines Java-Pakets installiert, kann also auch ungenutzt im System ruhen und es damit angreifbar machen.
Da viele Unternehmen nicht wissen, ob und wo sie betroffen sein könnten, ist diese Schwachstelle besonders gefährlich. So verbergen sich Java-Anwendungen etwa in den Programmen vieler Softwareanbieter, bei denen Unternehmen einkaufen. Doch auch wenn die Hersteller schnell Patches entwickelt hatten: Hunderte Server mit Anwendungen von dutzenden Herstellern im Eiltempo auf die Verwendung von log4j zu testen und entsprechend zu Patchen, ist schier unmöglich. Alle betroffenen Systeme aufzuspüren und abzusichern, wird Verantwortliche auch noch einige Zeit beschäftigen.
Wer mit einem MSSP arbeitet, war im Vorteil
Firmen, die mit einem Managed Security Service Provider (MSSP) arbeiten, profitierten von schnellen Reaktionszeiten. Der Provider kennt die Systeme des Unternehmens und beschäftigt sich tagtäglich damit, sie abzusichern. Ein erfahrener Security-Dienstleister weiß, wie hoch das Gefahrenpotenzial im individuellen Fall ist. Es sind zum Beispiel nicht alle Systeme dem Internet exponiert. Selbst wenn die Anwendung dort installiert ist, ist stehen sie nicht in der ersten Reihe und sind für Angreifer zweite Wahl. Dieses Wissen ist wichtig, da sich Ressourcen dorthin verlagern lassen, wo sie am meisten gebraucht werden.
Zudem kann sich ein MSSP ganz auf die Schwachstelle konzentrieren. Experten aus allen Abteilungen arbeiten daran, den Kunden zu schützen. Zudem arbeiten MSSPs mit wenigen Herstellern und Lösungen, die sie standardisiert betreiben. Durch die Nähe zum Hersteller und die Standardisierung hat ein MSSP sehr schnell den Überblick über die Verwundbarkeit der Systeme, die er für und beim Kunden betreibt. Patches können dann schnell und in der Fläche ausgebracht werden. Die digitale Infrastruktur ist weniger heterogen als bei einem Unternehmen, das sich um alles selbst kümmert.
Aus eigener Erfahrung können wir bei indevis sagen, dass wir schnell wussten, welche Systeme anfällig für die Schwachstelle waren. Auf unseren Managed Services Systemen und Plattformen sind selbstverständlich mittlerweile sämtliche Komponenten gepatcht. Auch unseren On-prem-Kunden konnten wir dadurch schnell helfen. So ging es zeitnah von Alarmstufe rot wieder in Richtung grün.
Aus der Katastrophe lernen
Die Java-Sicherheitslücke hat Parallelen zu Naturkatastrophen. Man weiß nie, wann so etwas wieder passiert. Ganz verhindern lassen sich solche Lücken auch in Zukunft nicht. Und dann, wenn es passiert ist, dauert es immer etwas, bis sie „geflickt“ sind. Nichtsdestotrotz können und sollten immer Lehren daraus gezogen werden.
Für die Zukunft bedeutet das: Unternehmen sollten wissen, was auf ihren Servern liegt. Denn dann lässt sich das Gefahrenpotenzial einer Schwachstelle schnell richtig einschätzen. Das kann Teil eines Schwachstellen-Management-Plans sein. Hat man den Ist-Zustand erfasst, hilft eine CMDB (Configuration Management Database) sofort, potenziell angreifbare Systeme zu ermitteln. Ist diese Datenbank gut gepflegt, verschafft das einem Unternehmen einen entscheidenden Zeitvorteil bei der Gefahrenabwehr.
Zusammengefasst: Je mehr Informationen ich über das habe, was ich tue, desto besser kann ich es schützen.
Wann die nächste große Sicherheitslücke aufgedeckt wird, weiß niemand. Überlegt man in Richtung Schadenspotenzial, könnte es ein umfangreicher Cloud-Hack sein. Uns allen ist bewusst, welche fatalen Auswirkungen ein solcher Angriff hätte. Sicherheit sollte daher auch oder gerade in der Cloud oberste Priorität haben.
