TL;DR: Wer auf der Suche nach einer kurzen Zusammenfassung der Geschehnisse rund um die (höchstwahrscheinliche) Backdoor in xz, CVE-2024-3094, ist, möge einen Blick auf diese durch den Sicherheitsforscher Thomas Roccia erstellte Grafik werfen. Darin sind die wichtigsten Details zusammengefasst, die in den folgenden Absätze wesentlich ausführlicher beleuchtet werden.

Alternativ hätte dieser Blogpost auch einen deutlich knackigeren Titel haben können - "CVE-2024-3094", um jene geht es in diesem Beitrag nämlich. Diese Sicherheitslücke in einer populären Implementation des "xz"-Dateiformates, welche mit an Sicherheit grenzender Wahrscheinlichkeit keine einfache Schwachstelle, sondern eine bewusst platzierte Hintertür ist, hat in den vergangenen Tagen durchaus für Aufregung gesorgt.

Diese Hektik und Nervosität war berechtigt, wenngleich die IT-Sicherheitsgemeinschaft in der initialen Erregung meiner Meinung nach einen wirklich besorgniserregenden Aspekt der ganzen Sache ziemlich ignoriert hat. Aber der Reihe nach ..

Was ist passiert?

Der Entwickler Andreas Freud entdeckte am 29.03.2024 beinahe zufällig eine schwerwiegende Sicherheitslücke in liblzma, einem Teil von xz. Während einiger lokaler Benchmarks im Rahmen anderer Arbeit fielen ihm einige Merkwürdigkeiten in Zusammenhang mit dem auf seinem System installierten SSH-Daemon auf, welcher ungewöhnlich viel CPU-Leistung verbrauchte. Weitere Untersuchungen deuteten darauf hin, dass liblzma der Ursprung der Leistungsprobleme sei, und führten - aufgrund einer sehr glücklichen Verkettung einer Vielzahl von Zufällen - schlussendlich zur Entdeckung der Schwachstelle.

Bereits nach kurzer Zeit stellte sich heraus, dass die Sicherheitslücke sehr wahrscheinlich nicht durch unbeabsichtigte Fehler von Entwickler:innen verursacht wurde, sondern dass es sich um eine durch bösartige Akteure bewusst platzierte Hintertür handelte.

Auffällig, und besonders beunruhigend, ist die Tatsache, dass es aktuell nicht danach aussieht, als wären die Systeme einer Person mit Zugriffsrechten auf die Versionskontrolle des xz-Projekts kompromittiert worden. Stattdessen scheint es sich hier um einen von langer Hand vorbereiteten Angriff handeln, bei dem die Angreifer:innen in der Lage waren, sich unter Vortäuschung falscher Tatsachen Commit-Rechte zu erschleichen. Eine detaillierte Ausführung dieses Aspektes des Angriffes würde den Rahmen dieser Veröffentlichung sprengen; der Entwickler Evan Boehs hat eine gute, vorläufige Zeitleiste auf seiner Webseite veröffentlicht.

Die durch den Bedrohungsakteur platzierte Hintertür ist technisch beeindruckend, und das nicht nur, weil ich selbst kein Entwickler bin und mein Kopf während des Lesens der verschiedenen Analysen zu rauchen begonnen hat. Aber die Tatsache, dass es mehrere Stufen gibt, sie auf eine Art und Weise geschrieben wurde, die es nahezu unmöglich macht, effektiv danach zu scannen, und dass die Analyse trotz der enormen Aufmerksamkeit von allen Seiten der Community noch nicht komplett ist, spricht für mich eine eindeutige Sprache.

Der oder die Verantwortliche/n hat signifikanten Aufwand betrieben, um sein Ziel zu erreichen, unabhängig davon, ob es um zeitliche oder monetäre Ressourcen geht. Wir reden hier von einem Bedrohungsakteur, der über mehrere Jahre hinweg im Einzelnen unauffällige Änderungen an verschiedenen, quelloffenen Softwareprojekten erreicht oder durchgeführt hat, um schlussendlich eine technisch hochkomplexe Hintertür in xz einbauen zu können, die ihm unter Umständen unauffälligen Fernzugriff auf hunderttausende Systeme auf der ganzen Welt ermöglicht hätte.

Wir wissen aktuell nicht, wer dahintersteckt. Aber die Kombination aus der technischen Komplexität und der operativen Disziplin, bzw. dem operativen Aufwand über Jahre hinweg, sind für mich Indizien, die in Richtung eines staatlich gesteuerten, oder zumindest staatlich unterstützten, Bedrohungsakteurs deuten. Mit der Annahme stehe ich nicht gänzlich alleine auf weiter Flur, auch Leute mit deutlich mehr Ahnung als ich sehen das ähnlich.

Die Situation hat sich rasch entwickelt, und seit dem ersten Kommentar von Andreas Freud letzten Freitag wurden viele Informationen zusammengetragen. Trotzdem sind die Untersuchungen noch lange nicht abgeschlossen, und es ist nicht auszuschliessen, dass in den nächsten Tagen noch weitere Erkenntnisse folgen.

Was bedeutet das für mich?

Benutzer:innen, auf deren Systemen Debian Testing, Debian Sid und Debian Experimental, Fedora 41 (und 40, unter bestimmten Umständen), Fedora Rawhide, Kali Linux und Arch Linux (unter bestimmten Umständen), openSUSE Tumbleweed oder openSUSE MicroOS eingesetzt wird, sind dringend dazu angehalten, bereits zur Verfügung stehende Sicherheitsaktualisierungen einzuspielen.

Die genannten Distributionen bzw. Versionen sind diejenigen, deren Versionen von xz gesichert von der Schwachstelle betroffen sind. Es gibt jedoch einige andere Distributionen bzw. Versionen, die aufgrund ihrer Release-Politik von der Sicherheitslücke betroffen sein könnten, bzw. die in den nächsten Tagen noch davon betroffen werden könnten.

Auf repology.org findet sich eine Auflistung, welche Distribution aktuell welche Version von xz in den Paketquellen hat. Nachdem auch in den Repositories des Paketmanagers Nix zeitweise eine verwundbare Version beinhaltet war ist nicht auszuschliessen, dass nicht auch macOS-Installationen betroffen sein könnten.

Ich habe hier bewusst Benutzer:innen angesprochen, und nicht Unternehmen oder Organisationen. Jene unter diesen, die (in der breiten Masse, im produktiven Einsatz) auf "Bleeding Edge" setzen .. mutig. Deutlich mutiger als ich, und ihr wisst hoffentlich, was ihr da tut, und wie ihr die Situation handhabt.

Bisher gibt es keine Anzeichen dafür, dass die Sicherheitslücke breitflächig ausgenutzt worden wäre. Laut einem Blogpost des Sicherheitsunternehmens Wiz (welches Cloud Security-Dienstleistungen anbietet) finden sich verwundbare Versionen von xz nur auf ungefähr 2% der Systeme in ihrem Zuständigkeitsbereich. Auch wenn sich diese Zahl natürlich nicht 1:1 auf das gesamte Internet übertragen lässt, so dient sie zumindest als ein Indikator dafür, dass eine Verwundbarkeit kein absolutes Massenphänomen ist.

Diese These wird auch von den ersten Resultaten der Analyse der Sicherheitslücke unterstützt. Diese legen nahe, dass sich die Schwachstelle, bzw. deren Ausnutzung, primär gegen bestimmte Distributionen (Debian, Red Hat und etwaige Derivate) richten sollte, und auch hier nur gegen Systeme, die gewisse Kriterien erfüllen.

Soll heissen: Aus praktischer Sicht ist in den allermeisten Fällen kein Grund zur Panik gegeben, und die Schwachstelle kann mit den üblichen Prozessen abgehandelt werden, die auch bei der Handhabung anderer Sicherheitslücken zum Einsatz kommen. Für Nutzer:innen bedeutet das also, schnellstmöglich den Updatemechanismus des installierten Betriebssystems bedienen.

Was *bedeutet* das?

Dennoch: Nur, weil bisher keine Informationen über etwaige Ausnutzung(en) der Schwachstelle an die Öffentlichkeit gelangt sind heisst das nicht notwendigerweise, dass das nicht passiert ist. Das ist aber nicht der eigentliche, wichtige Punkt an der ganzen Angelegenheit.

Auch wenn eine kritische Sicherheitslücke, die eine so verbreitete Implementierung eines grundlegenden Protokolls des modernen Internets, bzw. eine so verbreitete Programmbibliothek, betrifft, natürlich eine hässliche Sache ist, so wäre das alleine noch kein Grund dafür, dass meine Kolleg:innen Teile des Osterwochenendes im Dienst verbringen durften. Oder Auslöser dafür, dass ich hier in die Tasten hauen würde. Man schaue sich einfach unsere Warnungen der letzten Monate an.

Der eigentliche Punkt, das wirklich besorgniserregende an der Situation ist, dass wir es hier mit einem Supply Chain-Angriff zu tun haben, der von einem kompetenten, über in jeder Hinsicht signifikante Ressourcen verfügenden bösartigen Akteur durchgeführt worden ist.

Auch wenn das abschliessende Urteil noch aussteht, und noch nicht mit hundertprozentiger Sicherheit erwiesen ist, so sieht es für den Moment dennoch sehr stark danach aus, als wäre das einer der komplexesten, besten Angriffe auf Lieferketten, den wir in langer Zeit gesehen haben. Und der, wie in einem der ersten Absätze erwähnt, hauptsächlich durch Zufall entdeckt worden ist.

Plus: Der dafür verantwortliche Bedrohungsakteur hat einen, zumindest wenn man die Supply Chain-Angriffe betrachtet, die medial bekannt geworden sind, ungewöhnlichen Weg gewählt. Er hat sich nicht dafür entschieden, mittels offensiver Computermittel sein Ziel zu erreichen. Sondern hat analoge Mittel und Wege für digitale Erfolge genutzt.

Angreifer:innen haben bereits vor längerer Zeit verstanden, dass Sicherheitsexpert:innen ein lukratives Ziel sind. Einerseits aus offensichtlichen Gründen - das System eine:r Mitarbeiter:in eines SOC zu kompromittieren erlaubt unter Umständen weitreichenden Zugriff, ein Einbruch in den Computer einer Sicherheitsforscher:in kann gegebenenfalls wertvolle Informationen liefern, mit der sich die eigene OPSEC der Kriminellen stärken lässt, und so weiter.

Aber: Sicherheitsexpert:innen selbst anzugreifen kann für Täter:innen ebenfalls lohnend sein. Dass IT-Sicherheit ein stressiges Berufsfeld ist muss ich der Leserschaft dieses Blogs wohl nicht erklären. Zu viele Aufgaben, zu wenige Ressourcen, und in sehr vielen Fällen ist man gezwungen, reaktiv zu agieren, weil proaktive Schritte Unterstützung aus dem Management benötigt hätte.

Wenn man bereits gestresst ist, und dann noch durch Angreifer:innen belästigt wird, man selbst oder die Liebsten durch die Kriminellen bedroht werden, dann kann dies eine massive, zusätzliche Belastung sein.

Meiner (sehr persönlichen, subjektiven) Meinung nach haben sich die Angreifer:innen im aktuellen Fall von xz ebenfalls Stress und psychologische Last zu Nutze gemacht, allerdings auf eine heimlichere, perfidere Art und Weise.

Der Hauptentwickler hinter xz, Lasse Collin (dessen Statement zu der aktuellen Causa sich hier finden lässt) war lange Zeit der einzige Entwickler dieser Software, die ein fundamental wichtiger Bestandteil der meisten modernen, verbreiteten Linux-Distributionen ist. Ein sich fast schon aufdrängendes Beispiel für den Wahrheitsgehalt eines sehr bekannten XKCD.

Die Geschwindigkeit, mit der Entwicklungsfortschritte erzielt wurden, waren dementsprechend gering. Insbesondere auch, weil Lasse Collin durch Probleme mit seiner mentalen Gesundheit und anderen privaten Einflüssen stellenweise signifikant eingeschränkt war - etwas, das er auf projektbezogenen Mailinglisten offen angesprochen hat:

I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we'll see.

Besagter Jia Tan hatte sich einige Monate zuvor das erste Mal auf der Mailingliste des Projektes zu Wort gemeldet, mit einem Patch für xz - ein Patch, dessen Inkludierung rasch von einer weiteren, bisher ebenfalls unbekannten Person, gefordert wurde. Eine Forderung, die im Monatstakt wiederholt wurde.

Zumindest ein weiterer, bisher ebenso nicht in Erscheinung getretener, Teilnehmer auf der Mailingliste bekräftigte den Wunsch nach Akzeptanz des Patches. Die Forderungen gingen irgendwann dazu über, dass der ursprüngliche Entwickler aufgefordert wurde, einen weiteren Maintainer zu ernennen, während ihm im selben Atemzug vorgeworfen wurde, sich nicht mehr für das Projekt zu interessieren. Ein Vorwurf, der jemanden, der bereits mit psychischen Problemen zu kämpfen hat, sicherlich hart treffen würde.

Relativ kurze Zeit nach diesen Nachrichten liefert Jia Tan seinen ersten direkten Beitrag zu xz, und steuert in den darauffolgenden Monaten regelmässig Patches bei. Ab Jänner 2023 scheint es besagter Person gelungen zu sein, das vollständige Vertrauen von Lasse Collin zu erlangen, da ab diesem Zeitpunkt nicht nur Patches beigesteuert werden, sondern diese auch direkt in die Codebasis eingepflegt werden.

Dem Bedrohungsakteur ist es gelungen, einen Angriffsvektor auszunutzen, für den vorrangig quelloffene Projekte anfällig sind. Die Bedingungen, unter denen die Entwickler:innen bzw. Verantwortlichen solcher Projekte agieren sind ideal um auszubrennen. Was es Kriminellen ermöglicht, sich in eine Position zu bringen, in der es vergleichsweise einfach ist, sich als der "Retter in der Not" zu präsentieren. Und diese damit, in weiterer Folge, die Möglichkeit bekommen, heimlich still und leise in vermeintlich vertrauenswürdiger Software Schadcode zu platzieren. Wieder einmal beisst uns die verbreitete Unwilligkeit von Unternehmen, quelloffene Software adäquat zu unterstützen, in das metaphorische Hinterteil.

Der österreichische Journalist Andreas Proschofsky hat es in einem Artikel zu der Thematik besser zusammengefasst, als ich es je könnte:

Doch diese Freude dürfte von kurzer Dauer sein, wirft die Episode doch einige unerfreuliche Fragen auf. Etwa, wie es im Jahr 2024 noch immer sein kann, dass auf vielen Millionen Rechnern eingesetzte Komponenten bis heute von schwer überarbeiteten Hobby-Entwicklern gewartet werden. Obwohl durchaus bekannt ist, dass genau solche Projekte zu einem immer größeren Ziel für Angreifer werden.

Auf jeder Konferenz, bei der es auch nur am Rande um IT-Sicherheit geht wird die Thematik der Sicherheit digitaler Lieferketten breitgetreten, es gibt eine Vielzahl von (in ihrem Nutzen fragwürdigen) Workshops zu dem Thema, in Diskussionen zu Cybersicherheitsgesetzen wird Supply Chain-Sicherheit angesprochen.

Dennoch ändert sich nichts daran, dass kritische Teile unserer digitalen Infrastruktur von überarbeiteten Freiwilligen entwickelt und gewartet werden, die ausser Beschwerden und Druck herzlich wenig willkommen.

Deswegen gehe ich mit dem Blickwinkel, dass die Entdeckung der und der Umgang mit der Schwachstelle ein Erfolg war, nicht d'accord. Eine Mischung aus Zufall, Glück und intensivem persönlichem Einsatz waren der Grund dafür, dass es Angreifer:innen nicht gelungen ist, eine Hintertür in einer enorm wichtigen Softwarepaket zu verstecken. Wir können und dürfen uns nicht darauf verlassen, dass uns das beim nächsten Mal wieder gelingt.

Dieser Angriff hat gezeigt, dass die bestehenden Mechanismen, mit denen wir uns vor Angriffen auf Lieferketten im Open Source-Bereich schützen wollen, nicht (oder nicht gut genug) funktionieren. Wir müssen hier besser werden, sonst haben wir in der nahesten Zukunft noch mehr Probleme, als wir jetzt bereits haben.

Die Verantwortung für diese notwendige Verbesserung darf allerdings nicht alleine auf den Schultern der Entwickler:innen liegen. Die enorme mentale Belastung selbiger war für die Durchführung des Angriffes gegen xz ein wichtiger Faktor, den Zuständigen jetzt noch mehr Verantwortung und Stress aufzuhalsen wird nicht zielführend sein.