Log4Shell, die Ursachen, und die Folgen

Log4Shell – eine IT-Apokalpyse?

Anfang Dezember ging ein Erdbeben durch die IT-Sicherheitswelt. Das praktisch omnipräsente Programmier-Framework Log4j habe eine Sicherheitslücke, hieß es, integriert seit Ende November, die nun der Öffentlichkeit bekannt gemacht werde. Damit wäre innerhalb von Programmen, bei denen Teile auf Log4j basieren, Remote Code Execution möglich; also die Ausführung von fremdem Code auf anderen Rechnern. „Fast die Apokalypse“, schrieb die Washington Post. Das Technikmagazin Ars Technika sprach von der „schwersten Sicherheitslücke der IT-Geschichte“.

Endanwender, insbesondere die, bei denen Geld oder gar die Existenz auf dem Spiel steht, sind bis heute verunsichert. Wir bei K&K nehmen uns daher nochmal etwas vorweihnachtliche Zeit, um einige Fragen zu beantworten. Was ist da passiert? Was sollte man als Unternehmen jetzt beachten? Und was sind die Implikationen für quelloffene Software? Ist das das Ende von Open Source?

Was passiert ist – und wie es passieren konnte

Um zu verstehen, was Log4Shell anrichten konnte, muss man verstehen, was Log4j eigentlich macht. Wie der Name schon zu verstehen gibt, handelt es sich dabei nicht um ein komplettes Programm, sondern um eine Programmkomponente – ein offen zugängliches Schnipsel, das man in ein größeres Projekt einbinden kann. Da dieser Schnipsel erprobt und kostenfrei zugänglich war, haben viele Softwareprojekte auf Log4j gesetzt, anstatt für das von ihm abgedeckte Feature eigenen Code zu schreiben.

Der Schnipsel ist, einfach ausgedrückt, für die Erstellung eines Programmlogbuchs zuständig. Wenn ein bestimmtes Programm läuft, zeichnet Log4j in platzsparender Form auf, wie eine Session mit dem Programm ausgesehen hat. Was für Sachen wurden zu welcher Zeit gemacht, wie springt der User im Code herum?

War man mit einem von Log4j mitgeloggtem Programm nun allerdings in einer Anwendung unterwegs, die im Internet stattfindet, und in der man Text, zum Beispiel per Chat, zu einem User schicken kann, wurde der Inhalt dieses Chats vom Log4j mitgeloggt. Das ist an sich erstmal kein Problem, wird ja alles am Ende verschlüsselt und gelöscht, aber für eine bestimmte Zeit ist der Text des Chats beim Anwender als Datei auf dem Rechner. Wird nun anstatt ein simples „hallo“ per Chat Programmiercode geschickt, kann dieser unter Umständen auf dem Rechner des Empfängers ausgeführt werden – ohne dass der sich dagegen wehren kann. Diesen Vorgang nennt man „Remote Code Execution“ (dts. Fernausführung von Code), und ist der Super-GAU unter den Sicherheitslücken.

IT-Ingenieur-2

Der Kern ist geschmolzen – und jetzt?

Die Sicherheitslücke wurde Ende November 2021 gefunden und subsequent noch vor Veröffentlichung geschlossen. Also alles gut? Nicht ganz. Es ist nicht klar, wer zu welchem Ausmaß vor dem Fix von Log4Shell wusste, und wie viele Kriminelle darunter waren. Immerhin kann man, wenn man Code auf einem anderen Rechner ausführen kann, seine Spuren sehr effektiv verwischen.

Und Code konnte man auf vielen Systemen ausführen; Log4j ist enorm weit verbreitet, und fast jedes System hat Anwendungen, bei denen dieses Framework zum Einsatz kommt. Alleine, dass AWS (Amazon Web Services) Log4j nutzt, wäre genug für einen GAU, hosten sie doch die Mehrzahl aller aktuellen Webseiten. Zusätzlich dazu sind aber noch Videospiele (Minecraft, Steam), Cloudservices (iCloud), und Network-Security-Anbieter (Cloudflare) betroffen gewesen.

Die wirklichen Auswirkungen wird man wohl erst später spüren. Die abgegriffenen Daten können beispielsweise für Ransomware-Attacken oder personalisierte Erpressungen genutzt werden. Derartige Angriffe sind jetzt schon gängige und traurige Praxis, und es ist unklar, wie viele Daten gestohlen, und wie viele Programme via Log4Shell in Unternehmenssysteme geschleust wurden.

Für Ihr Unternehmen können Sie nur bedingt vorbeugen. Es ist jetzt wichtiger denn je, alle Programme zu updaten, damit auch wirklich überall Log4j auf dem neuesten Stand – also ohne Sicherheitslücke – ist. Außerdem sollten Sie sich um ein von Ihrem Kernsystem unabhängiges Sicherheitsbackup Gedanken machen, um gegen mögliche Ransomware-Angriffe besser geschützt zu sein. Zusätzlich gilt, jetzt mehr denn je auf Human Engineering und Netzwerksicherheit zu achten – Sie wissen nicht, was Kriminelle möglicherweise alles über Sie in Erfahrung gebracht haben.

Das Ende von Open Source?

Eine große Diskussion rund um Log4j fand bezüglich des Open Source-Standards des Frameworks und den damit verbundenen Implikationen für quelloffene Software statt. Tatsache ist: Log4j wird von einer kleinen Gruppe aus Freiwilligen gepflegt und entwickelt, die eine drastische Sicherheitslücke übersehen haben. Durch die kostenlose Verteilung des Frameworks gelangte diese Lücke in unzählige Systeme.

Soll man also auf Open Source verzichten? Wir von K&K sagen hier ganz klar: Nein! Eine derartige Lücke hätte in einem kommerziellen Programm genauso auftauchen können, und viele Open Source Frameworks sind so allgegenwärtig, dass sie das Rückgrat der kommerziellen Softwareentwicklung darstellen. Tatsache ist, ohne offene Frameworks könnten wir gar nicht arbeiten.

Daher müssen derartige Lücken anderweitig vermieden werden. Eine verstärkte Förderung von Open Source-Entwicklung könnte dafür sorgen, dass mehr Entwickler – und damit auch mehr Augen – an verwundbaren Frameworks arbeiten. Man wäre dann nicht mehr auf die Fehlbarkeit von zwei, drei hochqualifizierten, aber immer noch menschlichen, Programmierern angewiesen. Man könnte außerdem Open Source-Software mit dezidierten Teams stärker auf Sicherheitslücken abklopfen, um diese schneller finden zu können.

Kurz gesagt: Log4Shell sollte ein Weckruf und keine Grabesglocke sein. Open Source-Software ist aus unserem Alltag nicht mehr wegzudenken, und das ist auch gut so, denn sie hat viele Vorteile und ist im Schnitt sogar sicherer. Aber derartige Sicherheitslücken dürfen sich nicht wiederholen. Deshalb brauchen wir um jeden Preis mehr wachsame Augen auf die Programmschnipsel, die wir in unserem Alltag benutzen.

Bis dahin gilt: Aufpassen, Updates aufspielen, und vor allem, keine Panik – alles wird gut!

Adrian Döring

Adrian Döring