Aktenzeichen XZ ungelöst

Inhaltsverzeichnis

Man darf wohl ohne Übertreibung behaupten, dass etwas Derartiges nicht alle Tage passiert. Wahrscheinlich haben Sie zumindest am Rande mitbekommen, dass wir in den vergangenen zehn Tagen nur mit äußerst viel Glück einer der größten Katastrophen in der Geschichte des Internets knapp entkommen sind. Die Vorkommnisse lesen sich tatsächlich wie ein überaus spannender High-Tech-Kriminalroman. Doch was genau ist eigentlich geschehen? Wie konnte es dazu kommen? Welche Schritte sind nun erforderlich? Und vor allem: Wie lassen sich ähnliche Vorfälle in der Zukunft verhindern?

Ein Angriff auf XZ

Auf den ersten Blick schien es sich um einen Angriff auf das XZ-Projekt zu handeln, doch tatsächlich sind wir nur knapp einer digitalen Katastrophe unvorstellbaren Ausmaßes entkommen: Im Kern geht es bei dem Ganzen um nichts Geringeres als den Kampf um die digitale Weltherrschaft. Um zu verstehen, was genau passiert ist, werfen wir zunächst einen Blick auf einen kurzen historischen Abriss der Ereignisse.

Bevor wir damit jedoch beginnen, sollten wir kurz klären, was XZ eigentlich ist: Falls Ihnen das nichts sagt, XZ ist eine Sammlung von Werkzeugen zum Komprimieren von Dateien, ähnlich wie ZIP, und bezeichnet ebenso das dazugehörige Kompressionsformat. Im Gegensatz zu ZIP handelt es sich bei XZ jedoch nicht um ein Archivformat, das heißt, es werden nicht mehrere Dateien zu einer einzelnen zusammengefasst, sondern jede Datei wird für sich komprimiert. Wichtig zu erwähnen ist dabei auch, dass es eine zugehörige Bibliothek namens liblzma gibt. Das steht für "Lempel Ziv Markov Algorithm", also den Namen des Algorithmus, den XZ intern verwendet.

Alles beginnt im Jahr 2021

Springen wir in das Jahr 2021, denn der Ursprung der ganzen Geschichte reicht tatsächlich bereits drei Jahre zurück. Damals ereignete sich zwar zunächst eigentlich nichts, was besonders ins Auge fiele oder für Aufregung gesorgt hätte, jedoch legte im Laufe des Jahres jemand namens Jia Tan ein GitHub-Konto mit dem Benutzernamen JiaT75 an. Außerdem reichte Jia Tan einen Pull Request bei der Bibliothek libarchive ein, der darauf abzielte, eine Fehlermeldung zu verbessern.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Zumindest scheint das auf den ersten Blick der Zweck des Pull Requests gewesen zu sein. Bei genauerer Betrachtung des zugehörigen Commits fällt jedoch auf, dass nicht nur eine Fehlermeldung verbessert werden, sondern auch die Funktion zur Ausgabe, safe_fprintf, durch eine unsichere Variante, nämlich einfach nur fprintf, ersetzt werden sollte. Dieser Pull Request wurde ohne Einwände akzeptiert und hatte vermutlich keine weitreichenden Folgen. Doch vor dem Hintergrund der aktuellen Geschehnisse gerät der Vorgang erneut in den Fokus. Kurz gesagt: Jia Tan betritt die Bühne.

Jia Tan wendet sich XZ zu

Im darauffolgenden Jahr 2022 legt Jia Tan erstmalig einen Patch für XZ vor. Im Gegensatz zum üblichen Vorgehen wird dieser Patch allerdings nicht als Pull Request eingereicht, sondern über eine Mailingliste verteilt. Der Patch selbst ist eher unscheinbar und weckt wenig Interesse. Doch es ereignet sich etwas anderes, weit spannenderes: Eine zweite Person, die sich Jigar Kumar nennt, beginnt, den Entwickler von XZ zu drängen, den Patch so schnell wie möglich zu integrieren.

Der Druck steigt weiter an, als eine dritte Person, unter dem Namen Dennis Ens, ebenfalls auf eine rasche Übernahme des Patches drängt. Sowohl Jigar Kumar als auch Dennis Ens verschwinden nach diesen Ereignissen spurlos und hinterlassen keinerlei digitale Spuren. Beide Konten scheinen außerdem speziell für diesen einmaligen Zweck angelegt worden zu sein. Bemerkenswert dabei ist, dass alle drei E-Mail-Adressen einem ähnlichen Muster folgen.

Der Hauptentwickler von XZ, Lasse Collin, gibt dem Druck nach und nimmt den Patch auf. Es ist ein Paradebeispiel dafür, wie die Dinge oft laufen: Lasse Collin betreibt die Arbeit an XZ nebenbei. Wie so häufig ist die Beteiligung an Open-Source-Projekten für ihn als Einzelperson kaum nachhaltig. Die Last, die XZ mit sich bringt, ist für ihn allein eigentlich zu groß. Er ist überfordert und überarbeitet, wie er damals selbst schreibt.

Open Source ist (mal wieder) nicht nachhaltig

Leider ist diese Situation typisch für viele Entwicklerinnen und Entwickler weitverbreiteter Open-Source-Bibliotheken, die wesentlich zur kritischen Infrastruktur beitragen, ohne dass sich jemand ernsthaft um ihre finanzielle oder psychische Gesundheit kümmert. Open Source leidet unter einem gravierenden Nachhaltigkeitsproblem. Und es ist nicht das erste Mal, dass so etwas geschieht. Erinnern wir uns nur an die jüngste Sicherheitslücke in Log4J.

Im Klartext: Die Open-Source-Ideologie hat es über die Jahre und Jahrzehnte geschafft, den Wert unserer Zeit als Entwicklerinnen und Entwickler zu untergraben. Denn seien wir ehrlich: Für die meisten geht es bei Open Source nicht primär um den Zugang zum Quellcode, sondern um die Kostenfreiheit. Dass dabei Menschen wie Lasse Collin auf der Strecke bleiben können, wird als bedauerlicher, aber akzeptabler Kollateralschaden angesehen. Hauptsache, Open-Source-Software bleibt sowohl für die breite Masse als auch Unternehmen kostenfrei verfügbar …

Jia Tan bietet Hilfe an

Vor diesem Hintergrund überrascht es wenig, dass Lasse Collin die Unterstützung, die Jia Tan ihm anbietet, dankend annimmt. Denn endlich scheint einmal jemand bereit zu sein, nicht nur Forderungen zu stellen, sondern sich auch aktiv einzubringen. Dass er dabei unwissentlich einem umfassenden Social-Engineering-Angriff zum Opfer fällt, kann Collin zu diesem Zeitpunkt natürlich nicht erahnen. Und Jia Tan engagiert sich tatsächlich: Sie oder er wird zu einem regelmäßigen Mitwirkenden bei XZ, steigt im Laufe der Zeit sogar zum zweithäufigsten Beitragenden auf und wird 2022 schließlich zum offiziellen Co-Maintainer ernannt, mit den entsprechenden Berechtigungen.

Von dieser neu gewonnenen Vertrauensstellung macht Jia Tan erstmals am 7. Januar 2023 Gebrauch und integriert eigenständig Code in das XZ-Projekt. Von diesem Zeitpunkt an genießt Jia Tan das vollständige Vertrauen von Lasse Collin. Zwei Monate später, im März, wird die Kontaktadresse für XZ beim Open-Source-Sicherheitsscanner OSS-Fuzz auf Jia Tans Adresse umgestellt. Ab diesem Zeitpunkt gehen sicherheitsrelevante Benachrichtigungen, die XZ betreffen, primär an Jia Tan, Lasse Collin bleibt lediglich in CC.

Diese Änderung erweist sich wenige Monate später als bedeutsam, als eine neue Person, Hans Jansen, auf den Plan tritt. Hans Jansen schlägt eine Methode vor, um Prüfsummen schneller zu berechnen, indem der hierfür verwendete Algorithmus zur Laufzeit ausgetauscht werden kann – ein Konzept, das einem Plug-in-System ähnelt. Nach diesem Vorschlag verschwindet Hans Jansen zunächst wieder aus dem Geschehen, wird aber später erneut eine Rolle spielen.

Der Angriff wird vorbereitet

Jia Tan stimmt dem Änderungsvorschlag zunächst zu und erhält daraufhin prompt eine Sicherheitswarnung von OSS-Fuzz – Lasse Collin hingegen erhält diese Warnung nicht. Die Warnung ist gerechtfertigt, denn die vorgeschlagene Änderung würde es ermöglichen, Code nachträglich auszutauschen – eine Möglichkeit, die normalerweise vermieden werden sollte. Jia Tan wendet sich jedoch an OSS-Fuzz und behauptet, dass diese Änderung legitim sei und die Warnung somit unbegründet. Und OSS-Fuzz stimmt dieser Einschätzung schließlich zu. Damit ist in XZ nun theoretisch die Möglichkeit geschaffen, Code zur Laufzeit zu manipulieren.

Nach einer dreijährigen Vorbereitungsphase wird es dann im Jahr 2024 schließlich ernst: Jia Tan reicht bei XZ einen Pull Request ein, um scheinbar neue Testdateien hinzuzufügen. Konkret handelt es sich um zwei Binärdateien, deren Inhalt auf den ersten Blick nicht unmittelbar ersichtlich ist. Sie sollen angeblich dem Testen des Entpackungsvorgangs dienen, wobei eine der Dateien vermeintlich korrupt ist, die andere hingegen nicht.

Auf den ersten Blick mag dieses Vorgehen legitim erscheinen, da solche Testszenarien in der Praxis durchaus üblich sind. Andererseits lässt sich sicherlich darüber streiten, ob es eine gute Idee ist, direkt Binärdateien einzupflegen, oder ob diese nicht eher durch einen transparenten und nachvollziehbaren Prozess erzeugt werden sollten. Das eigentliche Problem besteht jedoch darin, dass diese "Test"-Dateien nicht einfach nur beliebige Binärdateien sind, sondern Skripte und ausführbaren Code enthalten. Beim Ausführen der Tests werden sie entpackt und in der Folge durch eine Reihe komplexer Befehle ausgeführt, was zu einer Manipulation des XZ-Builds führt. Ab diesem Zeitpunkt existieren somit kompromittierte Versionen von XZ.

Hans Jansen taucht wieder auf

Am 25. März 2024 taucht Hans Jansen schließlich erneut auf und setzt sich unter anderem beim Debian-Projekt dafür ein, auf die neue – und somit kompromittierte – Version von XZ umzusteigen. Das Debian-Projekt führt auch tatsächlich ein Upgrade durch, zunächst zwar nur in einer Vorabversion, aber Hans Jansen erzielt damit einen Erfolg. Auch andere Linux-Distributionen wie Kali-Linux, Arch-Linux und Fedora nehmen das Upgrade vor. Einige Distributionen, darunter Ubuntu, entscheiden sich gegen das Upgrade oder schieben eine Entscheidung auf. So gelangt die kompromittierte Version von XZ aber in eine Reihe von Linux-Distributionen.

Besagte Vorabversion von Debian fand nun ihren Weg zu Andres Freund, einem Mitarbeiter von Microsoft, der an der Entwicklung von PostgreSQL beteiligt ist. Er wollte einige seiner Änderungen an PostgreSQL testen und entschied sich daher für die neueste Debian-Version. Dadurch kam er bereits sehr früh mit dem Schadcode in Berührung – deutlich früher als die meisten Nutzer. Bei seinen Tests bemerkte er, dass der Login über SSH ungewöhnlich lange dauerte, nämlich eine dreiviertel Sekunde anstelle der üblichen Viertelsekunde.

Während die meisten Entwicklerinnen und Entwickler dies wahrscheinlich übersehen oder ignoriert hätten, wurde Freund skeptisch und begann, der Sache auf den Grund zu gehen. Seine Nachforschungen führten ihn immer tiefer in den Kaninchenbau, was mich persönlich an Clifford Stoll erinnert, der in den 1980er-Jahren aufgrund eines minimalen Abrechnungsfehlers den KGB-Hack aufdeckte. Schließlich geht Andres Freund am 29. März, also vier Tage später, mit seinen Erkenntnissen an die Öffentlichkeit.

Von XZ zu SSH

Nun stellt sich die Frage: Was genau ist das Problem und wo liegt die Gefahr? Es steht fest, dass XZ kompromittiert wurde, aber welche Auswirkungen hat das? Die Bedrohung ist tatsächlich nur indirekt mit XZ verbunden. Es ist wichtig zu verstehen, dass XZ unter Linux eine essenzielle Rolle spielt: So wird unter anderem der Kernel üblicherweise mit XZ komprimiert, ebenso das Initramfs und auch RPM- sowie DEB-Pakete. XZ ist somit schon früh im Systemstartprozess von Bedeutung.

Viele Linux-Distributionen verwenden heutzutage Systemd als Init-Prozess, der oft auch dazu dient, den SSH-Dienst zu starten. Die meisten Distributionen bieten dafür allerdings nicht die offizielle OpenSSH-Version an, sondern eigene, modifizierte Varianten mit zusätzlichen Funktionen. Die Integration von SSH mit Systemd ist eine solche typische Erweiterung. Hier setzt der Angriff an: Wenn Systemd startet, lädt es XZ, und XZ leitet – noch bevor SSH gestartet wird – die Funktion zur Authentifizierung von SSH-Schlüsseln auf sich um. Sobald SSH aktiviert wird, kommt die manipulierte Version zum Einsatz.

Und die hat es in sich: Die manipulierte Version der Authentifizierungsfunktion verhält sich zwar fast immer so, wie man es erwarten würde. Doch bei manchen SSH-Schlüsseln tritt ein Sonderfall in Kraft: Statt sie zu überprüfen, extrahiert der Backdoor-Code daraus Befehle, die er auf dem Zielsystem ausführt. Anstelle der regulären SSH-Authentifizierung muss dabei die Befehlssequenz eine digitale Signatur tragen, die nur die Angreifer erstellen können. Es ist tatsächlich ziemlich beeindruckend, dass so etwas überhaupt möglich ist. Der Clou dabei ist, dass sich SSH damit für praktisch alle Nutzerinnen und Nutzer vollkommen normal verhalten würde, nur nicht für Angreiferinnen oder Angreifer, die im Besitz des entsprechenden privaten Schlüssels wären. Das hätte die Sicherheitslücke extrem gut verbergen können.

Auf den letzten fünf Metern gescheitert

Das Besondere an diesem Angriff ist seine Komplexität. Er basiert darauf, die Lieferkette von SSH über mehrere Ebenen hinweg zu attackieren: Von XZ über liblzma und Systemd bis hin zu SSH. Ein solches Unterfangen erfordert umfassendes Spezialwissen aus verschiedenen internen Bereichen des Betriebssystems, der betroffenen Werkzeuge und insbesondere ihrer Wechselwirkungen. Die Vorbereitungen für diesen Angriff hatten eine lange Vorlaufzeit, beginnend im Jahr 2021, und es handelt sich um einen sogenannten NOBUS-Angriff ("Nobody but us"), bei dem ausschließlich die Angreiferin oder der Angreifer die Sicherheitslücke hätte ausnutzen können. Die Möglichkeit, in XZ dynamisch Code nachzuladen, legt sogar die Grundlage für weitere Exploits. Dies zeugt von einer komplexen und sorgfältig durchdachten Vorgehensweise.

Angesichts der hochtechnischen Natur dieses Angriffs stellt sich daher die Frage, warum er so schnell entdeckt wurde. Warum lief der SSH-Login merklich langsamer als üblich, was letztlich den ersten Verdacht bei Andres Freund weckte? Warum wurde dies, trotz des beträchtlichen Aufwands, der in die Planung des Angriffs floss, nicht umfassender getestet?

Mehr Glück als Verstand

Möglicherweise hatten wir alle einfach nur enormes Glück: Denn am 29. Februar, also vor gerade einmal fünf Wochen, wurde bei Systemd der Vorschlag eingebracht, das Laden von XZ zu einem deutlich späteren Zeitpunkt im Systemstartprozess zu initiieren, um diesen zu beschleunigen. Wäre dieser Vorschlag umgesetzt worden, hätte XZ nicht mehr die Möglichkeit gehabt, unbemerkt Veränderungen an SSH vorzunehmen.

Mit anderen Worten: Diese Änderung in Systemd hätte den sorgfältig über Jahre geplanten Angriff zunichtegemacht. Daher könnte es sein, dass die Angreifenden unter Druck gerieten, ihre Pläne vorzeitig in die Tat umzusetzen – selbst auf das Risiko hin, dass der Angriff bislang nicht ausgereift war. Dieser glückliche Zufall hat uns möglicherweise davor bewahrt, dass 80 bis 90 Prozent aller Server im Internet kompromittiert worden wären. Bedenkt man, dass Linux auf einem Großteil aller Server im Web und in der Cloud läuft, sind die potenziellen Konsequenzen kaum zu überschauen. Das hätte dann wirklich einer Übernahme der digitalen Weltherrschaft gleichkommen können, wie eine Szene aus "Fight Club", nur eben im echten Leben.

Was man aktuell weiß

Zum aktuellen Stand: Der spezifische Exploit wird noch von zahlreichen Expertinnen und Experten untersucht. Das GitHub-Repository von XZ ist momentan gesperrt, während der ursprüngliche Hauptentwickler, Lasse Collin, mit den Aufräumarbeiten beschäftigt ist. An dieser Stelle möchte ich noch einmal betonen, wie sehr mir Lasse Collin leidtut. Er hat viel Zeit und Engagement in die Entwicklung von etwas gesteckt, das der Allgemeinheit zugutekommt, nur um dann Opfer eines hinterlistigen Angriffs zu werden. Dass er einem so gut geplanten Social-Engineering-Angriff zum Opfer gefallen ist, kann und darf ihm nicht angelastet werden. Es ist zutiefst bedauerlich, dass jemand, der Gutes bewirken wollte, von anderen ausgenutzt wird, mit der erkennbaren Absicht, enormen Schaden anrichten zu wollen.

Ob die wahren Drahtzieher dieses komplexen Angriffs jemals ermittelt werden können, bleibt ungewiss. Es gibt Stimmen, die aufgrund der Komplexität und der langen Vorbereitungszeit auf die Beteiligung von Geheimdiensten verweisen. Allerdings könnte es genauso gut ein Einzelner mit ausgeprägter technischer Expertise und Durchhaltevermögen gewesen sein. Die bisher einzige Spur, ein IRC-Chat, den Jia Tan genutzt hat, führt zu einer IP-Adresse in Singapur, die jedoch zu einem VPN-Anbieter gehört – wahrscheinlich also eine Sackgasse. Eventuell könnte eines Tages eine Kombination aus Quellcodeanalyse, Auswertung der Tageszeiten und weiteren Indizien zu Erkenntnissen führen – allerdings halte ich das persönlich für eher unwahrscheinlich.

Welche Konsequenzen können wir ziehen?

Was lässt sich nun konkret unternehmen? Kurzfristig ist es sicherlich ratsam, alle verfügbaren Updates einzuspielen und gegebenenfalls zu überprüfen, ob die eigene Infrastruktur von der Schwachstelle betroffen ist. Weitere Informationen dazu finden sich im CVE-2024-3094.

Langfristig betrachtet handelt es sich hierbei jedoch weniger um ein technisches als vielmehr um ein gesellschaftliches und kulturelles Problem, das verschiedene Ebenen betrifft: Dazu zählt das blinde Vertrauen in Open-Source-Projekte, die anhaltende Nachhaltigkeitsproblematik in der Open-Source-Welt und die sorglose Integration externer Abhängigkeiten in eigene Projekte. Das gesamte System des Internets basiert im Wesentlichen auf gegenseitigem Vertrauen, oft jedoch, ohne wirklich zu wissen, wem dieses Vertrauen eigentlich geschenkt wird. Es ist daher erstaunlich, dass nicht noch mehr Zwischenfälle geschehen.

Die eigentlich spannende Frage ist jedoch, was vielleicht tatsächlich bereits unbemerkt passiert, ohne dass wir davon Kenntnis erlangen. Ich sehe den aktuellen Open-Source-Ansatz daher kritisch, denn die Verlockung, etwas kostenlos zu erhalten, macht viele Entwicklerinnen und Entwickler und auch Unternehmen offenbar blind für alles andere. In einer idealen Welt wäre das unproblematisch, aber angesichts der Existenz von Akteuren mit bösartigen Absichten – inklusive feindlicher Organisationen und Staaten – muss man sich fragen, ob das blinde Vertrauen in Open Source tatsächlich langfristig tragbar ist.

Open Source als Problem?

Und nur, damit das nicht falsch verstanden wird: Ich möchte damit nicht sagen, dass Closed Source die Lösung sei. Ein ähnlicher Angriff wäre dort genauso möglich. Doch wird die Anfälligkeit von Open Source durch das bestehende Problem verstärkt, dass Open-Source-Entwicklung in der Regel nicht nachhaltig ist: Solange Software für kritische Infrastrukturen wie das Internet von einzelnen Personen in ihrer Freizeit nebenher und unbezahlt erfolgt, solange wird es auf einfachstem Wege möglich sein, sich deren Vertrauen zu erschleichen. Würde die Entwicklung von Open-Source-Software hingegen angemessen bezahlt, wäre die Notwendigkeit, aus einer akuten Notlage heraus auf von Fremden angebotene Hilfe zurückzugreifen, deutlich niedriger.

Selbstverständlich weist Open Source sehr viele positive Aspekte auf, das möchte ich nicht abstreiten. Aber wo Licht ist, ist bekanntermaßen leider auch Schatten – und von diesen Schattenseiten der Open Source haben wir vermutlich gerade erst den Anfang gesehen.

(map)