Ein Lieferkettenangriff auf den SSH-Daemon über die ubiquitäre XZ-Bibliothek entwickelte sich nur durch viel Glück nicht zum Open-Source-Fiasko.

Am Karfreitag, dem 29. März 2024 erhielt die weltweite Linux-Community von einem bisher unbekannten Angreifer ein Osterei ins Nest gelegt, auf das sie gern verzichtet hätte. Die Rede ist von der Hintertür, die Unbekannte im Paket xz-utils platzierten. Wäre die Backdoor nicht durch puren Zufall aufgeflogen, hätten die bisher unbekannten Täter in naher Zukunft einen Generalschlüssel für das Internet in Händen gehalten.

Wie viele solcher potenziell gefährlichen Bibliotheken sich möglicherweise noch in Umlauf befinden, lässt sich nur erahnen. Doch die zweite Beinahe-Katastrophe nach Heartbleed innerhalb eines Jahrzehnts weckt die Hoffnung, dass sich so etwas so schnell nicht wiederholt. Der Kasten “Timeline” fasst die Ereignisse chronologisch zusammen.

Was sind die XZ Utils?

Bei den XZ Utils [1] handelt es sich um eine Sammlung von Tools zum verlustfreien Komprimieren, die zwar mittlerweile von moderneren Alternativen wie Zstd überholt wurde, aber dennoch unter Linux weitverbreitet ist. Die Bibliothek kommt bei Tarballs, Softwarepaketen, Kernel- und Initramfs-Images zum Einsatz. Sie verwendet ein universelles Kompressionsformat mit hoher Kompressionsrate und relativ schneller Dekompression. Als primärer Kompressionsalgorithmus dient LZMA2, der Lempel-Ziv-Markow-Algorithmus.

Was war passiert?

Der bei Microsoft angestellte deutsche Entwickler Andres Freund, der an der Datenbanksoftware PostgreSQL arbeitet, unternahm Benchmarks in virtuellen Umgebungen. Dabei beschlich ihn das Gefühl, der SSH-Daemon Sshd benötige länger als gewöhnlich, um zu antworten. Es trog nicht: Messungen zeigten, dass es um fast eine halbe Sekunde ging. Das machte Freund argwöhnisch, woraufhin er der Sache auf den Grund ging. Seine Recherchen führten ihn zum Paket xz-utils und dort zu der Bibliothek Liblzma als Verursacher der verzögerten Antwort des SSH-Daemons (Abbildung 1).

Abbildung 1: Der klar erkennbare Zeitunterschied beim Start von SSH mit den kompromittierten XZ Utils (oben) und der sauberen Version (unten) veranlasste Andres Freund zu weiteren Analysen.

Freund ist zwar kein Sicherheitsexperte, doch wurde ihm bei der Inspektion des Codes trotzdem schnell klar, dass hier etwas nicht stimmte. Daraufhin alarmierte er sofort die Security-Community [2]. Was Sicherheitsforscher weltweit in den nächsten zwei Tagen herausfanden, gäbe den Plot für einen Hollywood-Thriller ab: Sie deckten einen von langer Hand geplanten und höchst anspruchsvoll umgesetzten Lieferkettenangriff (Supply Chain Attack [3]) auf das weitverbreitete OpenSSH mit enormem Bedrohungspotenzial auf (Abbildung 2).

Abbildung 2: Über Jahre hinweg bereiteten die Angreifer ihre Lieferkettenattacke auf OpenSSH akribisch vor.

Ein Lieferkettenangriff zielt nicht direkt auf die zu kompromittierende Software, sondern platziert den Schadcode in einer vom eigentlichen Ziel aufgerufenen Komponente. Durch eine Reihe komplexer Verschleierungen extrahiert im konkreten Fall der Liblzma-Build-Prozess aus einer getarnten Testdatei im Quellcode eine vorgefertigte Objektdatei. Die dient dann dazu, bestimmte Funktionen im Liblzma-Code zu ändern. Das Ergebnis ist eine modifizierte Liblzma, die dann jede Software verwendet, die gegen diese Bibliothek gelinkt wurde.

Diese Supply-Chain-Attacke erlaubt den unbefugten Fernzugriff via SSH auf betroffene Systeme, indem sie die SSH-Authentifizierung umgeht. Der Schadcode wird indirekt in Sshd geladen. Das gelingt, da Sshd oft gepatcht wird, um Systemd-notify zu unterstützen, damit sich nach dem Start von Sshd andere Dienste starten lassen.

An dieser Stelle fällt auf, dass die Entwickler bei Systemd seit Januar daran arbeiten, bestimmte Bibliotheken – unter anderem auch Liblzma – nur noch bei konkretem Bedarf dynamisch über die Funktion dlopen() [4] zu laden. Das mag die Angreifer zum schnelleren Abschluss ihres Angriffsszenarios getrieben haben, denn mit dieser neuen Handhabung der Bibliotheken hätte der Angriff so nicht funktioniert (Abbildung 3).

Abbildung 3: Möglicherweise zwang eine Meldung wie diese auf Mastodon die Angreifer auf den letzten Metern zur Eile. Nach der Umsetzung dieser Maßnahme wäre der Angriff gescheitert.

Der Angriff funktioniert nur unter bestimmten Voraussetzungen. So kann man die Backdoor lediglich bei Distributionen aktivieren, die das DEB- oder RPM-Paketformat, die GNU Compiler Collection GCC sowie die GNU-C-Bibliothek Glibc nutzen. Zudem lässt sich der Schadcode nur mit einem Schlüssel aktivieren. Diese Vorgaben zielen auf Distributionen wie Debian, Ubuntu, Red Hat und Suse ab, die allesamt weltweit eine große Verbreitung auf den Servern von Unternehmen, Organisationen und staatlichen Verwaltungen haben. Eine Hintertür in OpenSSH hätte hier katastrophale Folgen. Das liegt nicht etwa an Fehlern von Sshd, Systemd oder Glibc, sondern nur an der Art, wie der Angriff zur Anwendung gelangte.

Die ausführbaren Nutzdaten der Schadsoftware wurden als binäre Blobs in zwei Testdateien der Versionen XZ Utils 5.6.0 und 5.6.1 eingebettet. Betroffen waren Rolling-Release-Distributionen wie Debian Unstable, Kali Linux, OpenSuse Tumbleweed und MicroOS, Fedora Rawhide, frühe Versionen der Beta zu Fedora 40 und Derivate wie etwa Siduction. Glücklicherweise wurde die weitere Verbreitung gestoppt, kurz bevor die Schadsoftware in die stabilen Ausgaben der anvisierten Mainstream-Distributionen gelangte.

Was geschah

Zunächst gilt es, klarzustellen, dass hier sicherlich keine Hacker mit einem finanziellen Interesse dahinterstecken, sondern vermutlich eine staatliche Organisation. Bis heute gelang es jedoch nicht, den Angriff konkret einem Dienst oder auch nur einem Land zweifelsfrei zuzuordnen. Gegen die Urheberschaft krimineller Hacker spricht die jahrelange penible Vorarbeit sowie die Mischung aus technischer Exzellenz und konzertiertem Social Engineering auf mehreren Ebenen.

Als Ansatzpunkt suchten sich die Angreifer mit XZ Utils ein kleines Projekt aus, das einerseits Bibliotheken mitbringt, die das Zielobjekt als Abhängigkeit lädt. Zudem war klar ersichtlich, dass das XZ-Utils-Projekt nicht adäquat betreut wurde. Der Entwickler und Betreuer Lasse Collin deutete des Öfteren öffentlich an, dass er überarbeitet sei und zudem psychische Probleme habe. Hier fanden die Angreifer einen idealen Ansatzpunkt.

Im Oktober 2021 erstellt ein Akteur namens Jia Tan einen Account mit dem Usernamen JiaT75 auf Github. Kurze Zeit später trat er erstmals bei XZ Utils in Erscheinung, indem er einen harmlosen Patch an die Mailing-Liste xz-devel schickte, der die Lesbarkeit des Codes verbesserte. Ein weiterer Patch folgt einen Monat später. Im Februar 2022 nahm Collin einen ersten Patch von Tan offiziell ins Git-Repository auf. Im April reichte Tan einen weiteren Patch ein.

Insgesamt brachte Jia Tan zwischen Oktober 2021 und März 2024 rund 700 Änderungen in den XZ-Utils-Quellcode ein. Zunächst dienten diese lediglich dem Aufbau einer Vertrauensbasis. Zuvor brachte er bereits in dem XZ Utils nahestehenden Projekt Libarchive zur ZIP- und RAR-Komprimierung einen Pull Request ein, der möglicherweise eine erste Sicherheitslücke öffnet. Der Patch wurde damals angenommen, aber mittlerweile wieder revidiert.

Wenige Tage später trat ein mutmaßlicher zweiter Angreifer unter dem Namen Jigar Kumar auf. Er richtete die erste von mehreren E-Mails an Collin mit der Frage, warum ein Patch vom Tan nicht aufgenommen werde. Ein weiterer Angreifer mit dem Pseudonym Dennis Ens fragte per Mail, ob XZ Utils überhaupt noch betreut werde. Collin entschuldigte sich und antwortete, Tan habe hinter den Kulissen in letzter Zeit viel gute Arbeit geleistet (Abbildung 4).

Abbildung 4: Mit E-Mails wie dieser bauten die Angreifer Druck auf den Betreuer der XZ Utils auf, mit dem Ziel, Jia Tan als Co-Maintainer mit entsprechenden Rechten zu platzieren.

Im Mai und Juni 2022 fuhren Kumar und Ens fort, Collin mit weiteren E-Mails immer stärker unter Druck zu setzen und einen zusätzlichen neuen Betreuer für das Projekt zu fordern. Collin sagt zu, Tan könne künftig eine größere Rolle im Projekt einnehmen, und stellte ihn als Co-Maintainer nach der Veröffentlichung der Version 5.4.0 in Aussicht. Tans mutmaßliche Zuarbeiter setzten nun nach und bemängelten diesen Termin als zu spät. Im Oktober 2022 wurde Tan dann offiziell in das Projekt aufgenommen, anfangs noch ohne weitere Zugriffsrechte. Die erhielt er jedoch sukzessive in den nächsten Monaten, bis zu dem Punkt, wo er die XZ Utils eigenhändig bauen und veröffentlichen durfte. Damit war der Grundstein dafür gelegt, eine Hintertür in der Software zu platzieren.

Am 22. Februar 2024 lud Tan manipulierte binäre Testdateien hoch. Sie flossen in die am 24. Februar gebauten XZ Utils 5.6.0 ein, die erste Version mit der Hintertür. Die Schadfunktion wurde nur erstellt, wenn man die XZ Utils aus den Release-Tarballs kompilierte, im Quellcode des Github-Repositories waren sie nicht vorhanden. Da der manipulierte, verschlüsselte Code in Testdateien versteckt war, fiel das nicht auf. Zwei Tage später gelangte diese Version als XZ Utils 5.6.0-0.1 in das Repository von Debian Unstable (Abbildung 5) und in der Folge in die Paketquellen weiterer Distributionen. Gleichzeitig bemühte sich Tan auf der Fedora-Mailing-Liste um schnelle Aufnahme des Pakets, da es “großartige neue Funktionen” enthalte.

Abbildung 5: Der Auszug aus dem Changelog des Pakets XZ Utils aus Debian Unstable zeigt den Upload der Versionen 5.6.0, 5.6.1 und schließlich der reparierten Version.

Im März 2024 ändert Tan die Kontaktdaten des XZ-Utils-Accounts bei OSS-Fuzz [5], einem Google-Projekt zum Aufdecken von Programmierfehlern in Software, und gab seine private E-Mail-Adresse als Kontakt an. Kurz darauf betrat ein weiterer Akteur unter dem Namen Hans Jansen die Bühne, der ebenso wie die anderen Akteure vor 2021 keinerlei auffindbare Spuren im Internet hinterließ. Er sendete eine Reihe harmlos wirkender Patches an das XZ-Utils-Projekt, die eine neue Abhängigkeit zu Ifunc (GNU Indirect Function) einführten [6]. Dabei handelt es sich um eine Funktion der GNU-Toolchain, die es einem Entwickler ermöglicht, mehrere Implementierungen einer bestimmten Funktion zu erstellen und zur Laufzeit mithilfe einer Resolver-Funktion zwischen ihnen zu wählen.

Ohne weiteren Zusammenhang erweckte diese Einreichung keinerlei Misstrauen. Zwei Wochen darauf reichte Tan bei OSS-Fuzz einen Patch ein, der Ifunc für XZ Utils deaktivierte. Das führte dazu, dass Auffälligkeiten, die Ifunc betrafen, nicht mehr erkannt wurden. In der Folge platziert Tan einen Fehler im Projekt Valgrind, einer Werkzeugsammlung zur dynamischen Fehleranalyse von Computerprogrammen mittels virtueller Maschinen. Der in Valgrind platzierte Fehler war harmlos, aber lästig, denn er veranlasste das Tool dazu, bei jeder dynamisch mit Liblzma gelinkten Anwendung eine Warnung auszugeben. Diesen “Fehler” hatte Tan mit der Veröffentlichung von XZ Utils 5.6.1 “behoben” und spielte das als weiteres Argument für die Aufnahme in die angepeilten Distributionen aus. Bei Ubuntu öffnete Tan einen Bug-Report zur Aufnahme in Version 22.04 LTS (Abbildung 6). Das scheiterte lediglich daran, dass der Freeze für die Aufnahme neuer Pakete wenige Tage zuvor eingesetzt hatte.

Abbildung 6: Ein Bug-Report sollte für die Aufnahme in Ubuntu 24.04 sorgen. Ein Argument war der behobene Valgrind-Bug, den die Angreifer zuvor selbst inszenierten.

Zum Zeitpunkt der zufälligen Entdeckung der Hintertür kurz vor Ostern 2024 durch Andres Freund befanden sich die Versionen 5.6.0 und 5.6.1 bereits bei einigen Rolling-Release-Distributionen in den Archiven. Wer sein System fleißig aktualisierte, hatte eines dieser Releases auf seinem Rechner. Es wäre nur noch eine Frage der Zeit gewesen, bis die Hintertür auf diesem Weg in die stabilen Ausgaben dieser Distributionen aufgenommen worden wäre. Nicht nur die Linux-Welt hatte also wirklich viel Glück.

Das wirft freilich die Frage auf, ob es sich bei den XZ Utils um einen Einzelfall handelt oder ob dieselben oder andere Akteure bereits Schadcode an weiteren Stellen platziert haben. Nach dem Bekanntwerden der Lücke untersuchten viele Projekte ihren Code und ihr Umfeld auf verdächtige Vorkommnisse. In diesem Zusammenhang tauchten Mitte April 2024 Hinweise auf, die von einem ähnlichen Vorgehen bezüglich E-Mails und Github-Konten berichten, die vorher nirgendwo Spuren hinterließen. Die Hinweise stammen von den Organisationen Open Source Security Foundation (OpenSSF) und OpenJS Foundation. Sie halten zwar die Namen der betroffenen Projekte geheim, sprechen aber in einer Warnung [7] davon, dass auch dort in E-Mails von mehreren Personen hartnäckig das Einsetzen eines neuen Maintainers gefordert wurde.

Suche nach den Tätern

Soweit der Stand Mitte April 2024. Die Community der Sicherheitsexperten war nicht untätig beim Versuch, die Täter zu lokalisieren. Dazu untersuchten sie aufwendig IP-Adressen und Commit-Zeiten. So stellte eine unabhängige Analyse fest, dass die meisten Commits zu den Bürozeiten der Zeitzonen UTC+2 und UTC+3 (Eastern European Time, Moscow Time) passen. Während Commits auch während des chinesischen Neujahrsfests stattfanden, herrschte an osteuropäischen Feiertagen wie Weihnachten und Neujahr Funkstille. Das sind selbstredend alles nur Indizien. Ob die Täter jemals lokalisiert werden können, bleibt zumindest fraglich.

Risiko Open Source?

Nach dem Bekanntwerden der Lücke dauerte es nicht lang, bis die Apologeten proprietärer Software verkündeten, man habe ja schon immer gewusst, dass Open-Source-Software unsicher sei. Dabei belegt auch dieser Fall wieder genau das Gegenteil. In Windows hätte man die Backdoor vermutlich gar nicht gefunden – und wer weiß schon, wie viel Schadsoftware sich in proprietärer Software versteckt?

Das Open-Source-Prinzip vieler Augen funktionierte auch diesmal wieder. Was die Sicherheits-Community über Ostern alles über den Angriff an den Tag brachte, wäre bei proprietärer Software schlicht nicht möglich gewesen. Auch die Geschwindigkeit, in der reparierte Pakete ohne die Backdoor in den Distributionen bereitgestellt wurden, ist bemerkenswert.

Realistisch betrachtet ist keine Art von Software jemals völlig gefeit vor Sicherheitslücken, aber die Offenheit freier Software hilft enorm, Sicherheitsprobleme schnell aus der Welt zu schaffen.

Déjà-vu

Man muss sich nicht lange fragen, welche Lehren man wohl aus dem Vorfall ziehen soll: Die Situation erinnert fatal an Heartbleed, die kritische Lücke in der TLS-Implementation von OpenSSL von vor ziemlich genau 10 Jahren [8]. Hier war ein Projekt, das eine der Software-Säulen des Internets stellte, völlig unterbesetzt und unterfinanziert. Gleichzeitig benutzten unzählige Unternehmen mit teils riesigen Budgets die Software, ohne dass etwas zu OpenSSL zurückfloss. Das war damals wie heute das Drehbuch für ein Debakel.

Bei XZ Utils sah und sieht es ähnlich aus wie seinerzeit bei OpenSSL. Allerdings arbeitet das jetzt betroffene Projekt noch mehr im Verborgenen und wird nach Definition des Maintainers Lasse Collin als Hobby betrieben. Auch hier fließt weder Geld, noch gibt es sonstige Unterstützung seitens der Nutznießer.

Keines der in diesen Angriff involvierten Projekte trifft hier eine Schuld. Vielmehr wurde ein völlig überlasteter Entwickler das Opfer eines perfide ausgeklügelten, vermutlich staatlichen Angriffsversuchs.

Im Nachgang der sehr kritischen Heartbleed-Lücke gründete die Linux Foundation die Core Infrastructure Initiative, die 2020 in der Open Source Security Foundation aufging.

Fazit und Ausblick

Unternehmen sollten zur eigenen Sicherheit aus dem Debakel die Lehre ziehen, zunächst zu überprüfen, welche Werkzeuge im Unternehmen überhaupt zum Einsatz kommen. Ein zweiter Schritt bestünde in der Kontaktaufnahme zu einigen dieser Projekte und den darin involvierten Personen, am besten abgestimmt mit anderen Unternehmen.

Persönliche Beziehungen und finanzielle sowie personelle Hilfsangebote sind die beste Versicherung dagegen, dass ein Projekt bösartigem Social Engineering zum Opfer fällt. Ist ein Projekt besonders wichtig für ein Unternehmen, bestünde eine Möglichkeit darin, dem Entwickler einen Job anzubieten, bei dem er ganz oder teilweise an seinem Projekt arbeiten kann. So ähnlich funktioniert das ja seit langer Zeit beim Linux-Kernel. Eine gesunde Community stellt zudem die beste Verteidigung gegen Angriffe von außen dar. Die Initiative liegt jetzt bei den Nutznießern.

Auf technischer Seite arbeiten viele Distributionen im Projekt Reproducible Builds [9] gemeinsam an der Verbesserung der Sicherheit und der Prävention solcher Angriffe. Dabei geht es darum, dass ein nach diesem Prinzip erstellter Quellcode immer eine Bit-identische Binärdatei ausgibt und somit vor ungewollten Änderungen schützt. Debian begann vor über zehn Jahren mit dem Bereitstellen von Reproducible Builds und verkündete 2017, dass sich 90 Prozent des Paketbestands reproduzieren ließen [10]; auch OpenSuse Factory meldete kürzlich Vollzug [11].

Eine tiefergehende technische Analyse der Vorfälle um die XZ Utils finden Sie bei Interesse auf der Webseite Securelist [12]. Außerdem gibt es einen unterhaltsamen deutschsprachigen Podcast [13] von Viktor Garske, der die Hintergründe erläutert. Wie sich die Unterstützung von Open-Source-Betreuern verbessern ließe, skizziert ein englischsprachiger Beitrag von Rob Mensching [14]. (tle)