Warnstufe Rot – Die Log4Shell-Sicherheitslücke

In der IT-Sicherheit ist derzeit kaum ein Thema so heiß diskutiert, wie die Zero-Day-Sicherheitslücke „Log4Shell“ in der Java-Logging Bibliothek Log4J. In der Nacht vom 11. auf den 12. Dezember 2021 rief das Bundesamt für Sicherheit in der Informationstechnik (BSI) die Warnstufe Rot aus – und das nicht ohne Grund. Die Risiken für die Sicherheit informationstechnischer Systeme, die durch die Log4J-Lücke entstanden und entstehen, sind immens.

1. Was ist Log4J und was genau ist das Problem?

Log4J ist eine sehr weit verbreitete Java-Logging-Bibliothek der Apache Software Foundation. Log4J ist Bestandteil vieler bekannter Java-Anwendungen und wird in zahlreichen Diensten u. a. von Apple, Microsoft, Twitter, Amazon und Mozilla eingesetzt. (Nicht abschließende) Übersichten einiger betroffener Softwarehersteller und Anwendungen sind bereits auf GitHub verfügbar (hier und hier).

Durch die hochkritische Zero-Day-Sicherheitslücke Log4Shell, die durchaus wörtlich zu verstehen ist und mit „Logging, um einen direkten Zugriff aufs System zu erhalten“ übersetzt werden kann, ist es möglich, in der Log4J-Bibliothek auf den anfälligen Servern oder den anfälligen Anwendungen einen beliebigen Code einzufügen und auf diese Weise Daten aus dem betroffenen System zu exfiltrieren.

Das Problem kann immer dann auftreten, wenn eine Anwendung ein Ereignis in Log4J protokolliert. Denn hierbei wird nicht nur der jeweilige Eintrag protokolliert, sondern Java versucht, den jeweiligen Eintrag auch zu interpretieren. Beinhaltet nun der Eintrag einen Verweis auf Java-Schadcode, wird dieser von der Anwendung entgegengenommen und ausgeführt. Auf diese Weise ist es möglich, jede Art von Schadsoftware (z. B. Backdoor-Anwendungen, wie Cobald Strike Beacons) in das System zu schleusen und Daten aus dem System zu exfiltrieren.

Wie zu erwarten war, wurde diese Sicherheitslücke bereits diverse Male ausgenutzt (mehr dazu hier).

2. Woran kann man erkennen, dass man betroffen ist?

Da das Ausnutzen dieser Sicherheitslücke äußerst trivial ist, ist es dringend erforderlich, dass Systemadministratoren sich des Problems annehmen.

Um sich einen Überblick zu verschaffen, welche Anwendungen betroffen sein könnten, sollte bei den Herstellern bzw. Anbietern der Software oder Geräten angefragt werden.

Daneben gibt es auch technische Möglichkeiten, die Betroffenheit einzelner Anwendungen bzw. einzelner Geräte zu prüfen.

3. Haftungsfragen

Weit weniger trivial, als das Ausnutzen der Log4Shell-Sicherheitslücke ist allerdings die Beantwortung der Frage, wer für entstandene Schäden haftet.

Als Softwarehersteller bzw. Anbieter betroffener Software ist dringend zu empfehlen, die Kunden über das Vorliegen der Sicherheitslücke zu informieren und anzugeben, bis wann die Sicherheitslücke voraussichtlich geschlossen ist.

Zudem kann der Einsatz eines von der Log4Shell-Sicherheitslücke betroffenen Systems als ein Verstoß gegen einschlägige gesetzliche IT-Sicherheitsvorgaben verstanden werden.

Wie viel Zeit für das Einspielen solcher Patches bleibt, hängt nicht zuletzt von dem zwischen dem Hersteller/Anbieter und dem Kunden geschlossenen Vertrag ab. Sind im Vertrag keine besonderen Bestimmungen zur IT-Sicherheit vorhanden, schuldet der Hersteller/Anbieter lediglich eine IT-Sicherheit „mittlerer Art und Güte“. Insofern ließe sich durchaus vertreten, dass die Dauer, bis Patches eingespielt sein müssen, länger sein kann, als bei expliziten vertraglichen Regelungen zum Stand der IT-Sicherheit.

Daneben spielt etwa auch die Größe des betroffenen Unternehmens eine Rolle bei der Beurteilung des zu Verfügung stehenden Zeitraums zum Einspielen von Patches und demzufolge auch bei der Frage etwaige Schadensersatzansprüche.

Die Frage, in welchem Umfang der Verstoß gegen die o. g. Regelungen zum Stand der Technik tatsächlich zu Schadensersatzansprüchen führen können, kann daher nicht pauschal beantwortet werden und hängt stark vom Einzelfall ab. Grundsätzlich ist allerdings davon auszugehen, dass bei zeitnaher Information der betroffenen Kunden und zeitnaher Schließung der Sicherheitslücke keine Schadensersatzansprüche bestehen.

Sofern die Schließung der Sicherheitslücke allerdings nicht zeitnah möglich ist kann durchaus ein Verstoß gegen IT-sicherheitsrechtliche Vorschriften in Frage kommen, der dann auch Schadensersatzansprüche nach sich ziehen kann. In diesem Fall sollte dringend darüber nachgedacht werden, den Betrieb des betroffenen Systems, zumindest vorübergehend, einzustellen und erst dann wiederaufzunehmen, wenn die Sicherheitslücke geschlossen wurde.

Je nach vertraglicher Vereinbarung zwischen dem Hersteller bzw. Anbieter und dem Kunden können hierdurch beim Kunden oder dessen Kunden entstehende Schäden vom Hersteller bzw. Anbieter zurückgefordert werden.

Insbesondere im Hinblick auf IoT-Geräte kann sich dieses Problem ergeben. Wie unzureichend die Hersteller und Anbieter in dieser Hinsicht arbeiten, wurde zuletzt auch von der IoT Security Foundation (hier) angeprangert. In diesem Fall ist daher dringend eine Prüfung der vertraglichen Regelungen zum Thema IT-Sicherheit geboten, um die eigenen Handlungsoptionen abschließend beurteilen zu können.

4. Exfiltration personenbezogener Daten

Sofern es bereits zu Datenleaks gekommen ist und hiervon personenbezogene Daten betroffen sind, sollten umgehend die zuständigen Datenschutzaufsichtsbehörden über den Vorfall informiert werden. Nach Art. 33 DSGVO hat dies innerhalb von 72 Stunden nach Bekanntwerden des Vorfalls zu geschehen. Üblicherweise ist man nicht Verpflichtet, proaktiv nach unautorisierten Zugriffen zu suchen. Hier könnte die Sache jedoch aufgrund der großen Medienpräsenz und Kritikalität des Themas abweichend bewertet werden. Es lohnt sich also aktuell verstärkt, ungewöhnliche Zugriffe zu untersuchen und Logfiles entsprechend auszuwerten. Erfolgt die Meldung später als 72 Stunden nach Bekanntwerden des Vorfalls, ist der Meldung eine Begründung für die Verspätung beizufügen.

Sofern die Leaks personenbezogener Daten zu einem voraussichtlich hohen Risiko für die Rechte und Freiheiten natürlicher Personen geführt haben, ist darüber hinaus eine unverzügliche Mitteilung an die Betroffenen nach Art. 34 DSGVO erforderlich.