Technischer Support
Dokumentation
Anmeldung
Kontakt
TuxCare BlogEin tiefer Einblick in den xz-Kompromiss
von Joao Correia
April 2, 2024 - Technischer Evangelist
xz ist ein weit verbreitetes Paket, das Benutzern und Entwicklern verlustfreie Komprimierung bietet und standardmäßig in den meisten, wenn nicht sogar allen Linux-Distributionen enthalten ist. Es wurde 2009 erstellt und hat seitdem zahlreiche Versionen veröffentlicht.
Als Open-Source-Projekt ist es auf GitHub verfügbar. Zum Zeitpunkt des Verfassens dieses Artikels war jedoch der Versuch, die Projektseite mit einer Meldung begrüßt, die besagt, dass "dieses Repository aufgrund eines Verstoßes gegen die Nutzungsbedingungen deaktiviert wurde", anstatt der traditionellen GitHub-Seite. Dieser Verstoß war auf die Verbreitung von Malware zurückzuführen. In diesem Artikel gehen wir dem Was, dem Warum, dem Wie und vielleicht sogar dem Wer hinter diesem Vorfall auf den Grund.
Als die Geschichte Ende der Woche vor Ostern bekannt wurde, explodierte die Cybersec-Sphäre auf Twitter, und die Internetspürnasen beschäftigten sich mit jedem Detail. Dieser Artikel stützt sich in hohem Maße auf Informationen, die im Rahmen dieser Ermittlungen gesammelt und veröffentlicht wurden und von denen ein Großteil hiersowie auf Informationen, die der Autor durch eigene Nachforschungen gesammelt hat. Wo immer möglich, wird auf die Originalquellen verwiesen, und wo keine direkte Quelle angegeben ist, kann der Leser davon ausgehen, dass die Informationen entweder von der GitHub gist der das Ereignis zusammenfasst, oder dieser Zeitleiste.
Bedenken Sie, dass diese Geschichte noch sehr jung ist. Es gibt noch einige ungelöste Aspekte und einige Hinweise auf die (unwahrscheinliche) Möglichkeit, dass die Person, die ursprünglich hinter dem Vorfall vermutet wurde, es nicht unbedingt ist. Dies wird im Abschnitt "Vorbehalte" dieses Artikels näher erläutert.
Schnallt euch an, der Kaninchenbau geht hier tief.
Historischer Kontext
Das xz-Projekt wurde, wie viele andere Open-Source-Projekte auch, als Lieblingsprojekt eines einzelnen Entwicklers ins Leben gerufen, der eine Idee hatte und sie mit der Welt teilte. Im Jahr 2009 gründete Lasse Collins, der zuvor für die Wartung von lzma-utils, einem anderen Projekt im Bereich Komprimierung, verantwortlich war, xz. Es wurde als Erweiterung bzw. Weiterentwicklung von lzma konzipiert, so dass liblzma jetzt standardmäßig als Teil des xz-Pakets ausgeliefert wird.
Wie bei den meisten Ein-Personen-Projekten üblich, war der Autor für den Großteil des Codes und für die Verwaltung der gelegentlichen Commits von Dritten, die Integration des Codes in das Repository und die Veröffentlichung neuer Versionen verantwortlich. Als das Projekt an Aufmerksamkeit gewann, wurde die Last der Verwaltung schwerer, und schließlich wurden andere Mitwirkende für ihre Bemühungen anerkannt und erhielten die Berechtigung, Aufgaben wie die Überprüfung des Codes, die Annahme oder Ablehnung von Beiträgen und die Verwaltung des Projektarchivs zu übernehmen.
Jia Tan, ein Entwickler, der bereits zuvor zu dem Projekt beigetragen hatte, erhielt vor etwas mehr als zwei Jahren Commit- und dann Release-Management-Rechte. Im Nachhinein scheint das Hinzufügen eines neuen Betreuers Teil einer Social-Engineering-Kampagne gewesen zu sein, die auf Lasse Collins abzielte. Die Zeitleiste dieses E-Mail-Verkehrs ist zu sehen hier.
Durch Druck und Anschuldigungen, das Projekt aufzugeben oder das Interesse zu verlieren, schickten mehrere verschiedene Benutzer (oder vielleicht eine einzige Person hinter mehreren Benutzernamen) Nachrichten an die Mailingliste des Projekts. Sie beschwerten sich über Verzögerungen bei der Annahme von Patches, der Freigabe neuer Versionen und der Annahme anderer Methoden, bis die Projektleitung begann, sich auf einen neuen, aber eifrigen Mitwirkenden zu verlassen. Die E-Mail-Konten, die hinter dieser Drucktaktik stehen, haben anscheinend über diese Mailingliste hinaus keine Präsenz im Internet zu haben.
Zu sagen, dass xz weit verbreitet ist, ist eine Untertreibung. xz ist eines der Komprimierungsformate, die Sie verwenden können, um den Linux-Kernel auf ein System zu packen, was es für das Booten dieses Systems unverzichtbar macht. Die erzielten Komprimierungsraten und die Geschwindigkeit der Dekomprimierung machen es zu einer perfekten Option für platzsparende Veröffentlichungen, Kernel-Images und andere Komponenten.
Die fehlende Zeit
Ironischerweise führte Andres Freund, ein Software-Ingenieur bei Microsoft, Timing-Messungen an virtuellen Linux-Maschinen durch, um eine Basislinie für eine nicht verwandte Aufgabe festzulegen. Dabei bemerkte er ein gewisses "Rauschen" in den Messwerten. Der sshd-Prozess, der für die Annahme von sicheren Remote-Shell-Verbindungen zuständig ist, verbrauchte selbst bei fehlgeschlagenen Verbindungsversuchen eine übermäßige Menge an CPU, wobei sich eine Verzögerung von 500 ms auf die Verbindungen auswirkte. Diese unerklärliche Verzögerung veranlasste Freund zu weiteren Untersuchungen, bei denen er Tools zur Leistungsüberwachung (perf) und Fehlersuche (dbg) einsetzte, um das Problem zu identifizieren.
Er entdeckte eine Hintertür in xz. Genauer gesagt identifizierte er die Hintertür und den eingeschleusten Code, da die Hintertür im Huckepack-Verfahren bestimmte von sshd aufgerufene Funktionen nutzte. Es ist wichtig anzumerken, dass sshd nicht von xz oder liblzma abhängt, was aufmerksamen Lesern vielleicht schon aufgefallen ist. In Systemen, die systemd zum Laden von sshd verwenden, enthält systemd jedoch liblzma als Abhängigkeit. Durch diese Verbindung konnte der Backdoor-Code in sshd eingeschleust werden. Zu den Systemen, die in diese Kategorie fallen, gehören Fedora, Ubuntu, Debian und die meisten von ihnen abgeleiteten Distributionen.
Die Hintertür
Die Methode, mit der der Code in xz (und liblzma) eingeschleust wurde, umfasste einige Binärdateien, die dem xz-Repository hinzugefügt wurden, und einen kompromittierten Build-Prozess. Diese Dateien, die ursprünglich die ursprünglich von Jia Tan als Teil einer "Test-Suite" für xzeingereicht wurden, waren binäre Blobs, die "mit einem Hex-Editor handgefertigt" wurden. Das Lesen von Quellcode ist bereits eine komplexe Aufgabe, aber das Lesen von Binärcode ist nahezu unmöglich. Es gibt eine augenzwinkernde Bemerkung, dass "es keinen besseren Quellcode gibt als die Dateien selbst". In der Tat.
Der Commit mit den bösartigen Dateien wurde am 23. Februar 2024 erstellt. Soweit derzeit bekannt ist, ist der bösartige Code nur in zwei der Binärdateien enthalten. Die anderen scheinen ihre beabsichtigten Funktionen zu erfüllen - sie testen verschiedene Bedingungen für Fehler im Komprimierungs- oder Dekomprimierungsprozess von xz und liblzma.
Einer der bemerkenswerten Aspekte der Hintertür ist, dass ein zufälliger Benutzer, der den Code aus dem xz-Repository entnimmt und ihn nach dem Einfügen der Hintertür kompiliert, keine kompromittierte Binärdatei erhält (soweit die derzeitige Annahme, die sich jedoch später als falsch herausstellen kann). Der eigentliche Injektionscode wäre nur dann in der Ausgabe enthalten, wenn eine bestimmte "build-to-host.m4"-Datei während der Kompilierung vorhanden wäre, aber diese Datei wurde auch zu ".gitignore" hinzugefügt, wodurch sie für reguläre Git-Operationen, die normalerweise von Endbenutzern verwendet werden, unzugänglich ist. Sie wird jedoch während des Erstellungsprozesses eines Pakets einer Linux-Distribution verwendet.
Diese Vorgehensweise zielte darauf ab, den Code in aktuelle Linux-Distributionen einzuschleusen, und erschwerte es gleichzeitig den Sicherheitsforschern, den Vorfall in einer kontrollierten Umgebung zu reproduzieren.
Am 24. Februar, einen Tag nach dem Hinzufügen der bösartigen Dateien, markierte derselbe Benutzer xz-5.6.0 (d. h., er präsentierte es als nächste Version). Linux-Distributionen nehmen in der Regel neue Versionen von Paketen auf, und Debian zum Beispiel nahm sie ein paar Tage später in das Unstable-Repository auf.
Am 28, wurde ein zusätzlicher Patch von Jia Tan hinzugefügt, der die Erkennung von Landlock während des Erstellungsprozesses beeinträchtigte. Landlock ist ein Sicherheitsmerkmal, das (unter anderem) fremde Verknüpfungen und den Import von Code verhindert, der ausgelöst werden würde, wenn es während der Kompilierung aktiviert wäre.
Dies wurde auf eine sehr subtile Weise erreicht. Ein einzelnes "." (Punkt), das der Datei "CMakeLists.txt" hinzugefügt wurde, störte die Kompilierung der Sandbox-Prüfung, so dass die Landlock-Erkennung immer "false" zurückgab, was wiederum dazu führte, dass sie für den bösartigen Code immer deaktiviert wurde. Diese Änderung wurde bei der Einreichung nicht erkannt. Bezeichnenderweise wird dieser Commit Lasse Collins (nicht Jia Tan) zugeschrieben, der möglicherweise gefälscht wurde, oder die sehr subtile Änderung wurde nicht entdeckt, bevor der Code hinzugefügt wurde.
Insbesondere wurde am 29. Februar in einem Pull-Request im systemd-Projekt die Forderung, das Linken von liblzma zu stoppen, um die Bildgröße zu reduzieren. Dadurch wäre der Angriff vereitelt worden. Dieses Ereignis scheint in keinem Zusammenhang mit dem eigentlichen Angriff zu stehen und wird als Zufall akzeptiert, der die Zeitachse beschleunigt haben könnte. Es ist nicht bekannt, ob frühere Gespräche zu diesem Thema öffentlich waren und dem Angreifer bekannt waren.
Die Funktion, die den bösartigen Code aufruft, ist _get_cpuid. Möglicherweise gibt es noch weitere Funktionen, die noch entdeckt werden müssen. Diese Funktion führt den bösartigen Nutzdatencode aus, bevor die ursprüngliche _get_cpuid-Funktion ausgeführt und zurückgegeben wird, wodurch die vom Microsoft-Ingenieur festgestellte Latenz entsteht. Genauer gesagt, wird diese Funktion zu Beginn des Zertifikatsvalidierungsprozesses aufgerufen, wenn eine Verbindung initiiert wird.
Einige Verteilungen begannen, während der Analyse valgrind-Fehler in dieser Funktion zu beobachten. Am 8. März hat Jia Tan einen Code zur Behebung der Valgrind-Erkennungen eingereichtvorgelegt, der im Nachhinein den Anschein erweckt, als würde er die Analyse des bösartigen Codes einfach deaktivieren.
Am darauffolgenden Tag, dem 9. März, aktualisierte Jia Tan die durch die Hintertür geschützten Dateien unter dem Vorwand, dass "sie mit einem Zufallswert erstellt wurden, der nur auf seinem Rechner vorhanden war, und um sie in Zukunft besser reproduzieren zu können, sollte ein konstanter Startwert verwendet werden." Auch hier gilt, dass Binärdateien schwer zu analysieren sind, insbesondere wenn der Backdoor-Code lediglich Werte aus vordefinierten Stellen innerhalb des Binärblob auswählt, was eine Entdeckung praktisch unmöglich macht. Noch am selben Tag markierte und veröffentlichte er xz-5.6.1.
Am 25. März tauchte eines der E-Mail-Konten wieder auf, das benutzt wurde, um den ursprünglichen Betreuer von xz unter Druck zu setzen. das Debian-Projekt unter Druck zu setzen, die neue Version von xz aufzunehmen. Andere scheinbare Geisterkonten schlossen sich an, um den Druck zu erhöhen.
Am 28. März reichte Jia Tan einen Fehlerbericht bei Ubuntu für die Aufnahme von xz-5.6.1ein, da Debian es bereits integriert hatte.
Das bösartige Verhalten ist zielt speziell auf x86-64-Systeme ab, auf denen glibc läuft (es hängt von einer Funktion ab, die von glibc bereitgestellt wird) und sshd über systemd läuft. Dieser Satz von Bedingungen passt zu Debian- und Red-Hat-basierten Distributionen.
Die Entschleierung und Analyse des bösartigen Codes ergab, dass er jedes Mal aktiviert wurde, wenn eine eingehende Verbindung über sshd empfangen wurde. Es wurde erst kürzlich entdeckt, dass der Code beim Empfang einer Verbindung einen bestimmten öffentlichen Schlüssel erwartet. Wenn dieser Schlüssel nicht vorhanden ist, funktioniert sshd wie gewohnt. Wenn jedoch ein vom Angreifer kontrollierter Schlüssel vorhanden ist, löst der Code ein anderes, ferngesteuertes Verhalten aus.
Entdeckung, und die Open-Source-Welt ist erschüttert
Am 28. März führte die Untersuchung von Andres Freund zur Identifizierung der Hintertür. Die Distributionen wurden benachrichtigt, und es wurden Updates veröffentlicht, die die Pakete im Wesentlichen auf eine Version vor Jia Tans Beteiligung am xz-Projekt zurücksetzen. Das bedeutet, dass es jetzt eine "5.6.1+wirklich5.4.5" Version von xz in den Repositories mehrerer Distributionen verfügbar.
Zu den Distributionen, die das Vorhandensein des kompromittierten Pakets bestätigt haben, gehören Fedora Rawhide, Fedora 40 beta und Debian.
Da xz eine entscheidende Rolle im Prozess der Paketerstellung selbst spielte, entschied sich das Debian-Projekt, sein gesamtes Erstellungssystem neu zu erstellen, da es eine Version von xz verwendete, die Jia Tans Patches enthielt (vor der angeblichen Einbindung der Hintertür).
Ein Angriff auf die Lieferkette kann eine enorme Reichweite haben. Auch wenn dies oft behauptet wird, wird es erst durch klare und eindeutige Beweise, wie diesen Angriff, wirklich deutlich.
Bei der Analyse dieser Situation werden mehrere Probleme deutlich:
Erstens führt die Art und Weise, wie Open-Source-Projekte ohne angemessene Finanzierung und Ressourcen betrieben werden, zu Situationen, in denen die Projektbetreuer überfordert sein können und dazu verleitet werden, weniger als ideale Kompromisse zu akzeptieren. Diese Schwachstelle ermöglicht es Bedrohungsakteuren, wichtige Projekte zu infiltrieren und schließlich die Kontrolle darüber zu erlangen.
Zweitens: xz war lediglich das Projekt, das erwischt wurde. Ohne die Verzögerung, die durch den bösartigen Code verursacht wurde, der wahrscheinlich mit mehr Zeit hätte optimiert werden können, wäre dieser Angriff vielleicht gar nicht entdeckt worden, und jeder würde schließlich eine kompromittierte Version von xz auf seinen Debian- und Red-Hat-basierten Systemen ausführen. Durch die Rückgängigmachung von xz wird angenommen, dass diese spezielle Bedrohung neutralisiert wurde. Wie sicher diese Behauptung ist, bleibt jedoch zu diesem Zeitpunkt unklar.
Drittens wird Open-Source-Projekten in jeder Minute und an jedem Tag Code hinzugefügt, und zwar in unzähligen verschiedenen Projekten. Die Art und Weise, wie Abhängigkeiten verwendet und überprüft werden, ermöglicht es, dass eine Kaskade von Fehlleitungen das beabsichtigte Ziel erreicht, selbst wenn kein bösartiger Code jemals direkt das vom Angreifer beabsichtigte Zielpaket berührt.
Viertens ist das Argument, dass Open-Source-Code sicherer ist, nur weil er offen ist, ein Strohmann. Dieses Argument gilt nur, solange es genügend und ausreichend motivierte Personen gibt, die jede Zeile des Codes jedes Projekts bei jeder Übertragung überprüfen. Dies erfordert eine große Anzahl hochqualifizierter Personen, die einen erheblichen Teil unbezahlter Arbeit leisten, und zwar auf unbestimmte Zeit. Die Fähigkeit, Code zu prüfen und zu untersuchen, ist nur dann effektiv, wenn die Prüfung und Untersuchung tatsächlich durchgeführt wird. Selbst dann ist es aufgrund der Natur der Sache und der verfügbaren Verschleierungsmethoden möglich, bösartigen Code in ahnungslose Projekte einzuschleusen. Man könnte sogar argumentieren, dass die Verfügbarkeit von Quellcode unter Sicherheitsaspekten böswilligen Akteuren, die nach Schwachstellen suchen, mehr hilft als den Endnutzern, und das vielleicht sogar in erheblichem Maße. Open-Source-Code bietet zwar viele unbestreitbare Vorteile, aber die eigentliche Sicherheit ist nicht immer einer davon. Diese Hintertür wurde völlig zufällig entdecktentdeckt, nicht weil jemand den Code aktiv überprüft hat.
Fünftens: Der Aufbau eines guten Rufs in der Open-Source-Gemeinschaft beruht oft nur auf der Commit-Historie in GitHub und auf nichts anderem. Interesse an einem Projekt zu zeigen und einige Codekorrekturen beizusteuern, reicht oft aus, um akzeptiert zu werden. Die Demonstration von Hilfsbereitschaft kann leicht fingiert werden. Dies macht es sehr schwierig, bestimmte Personen zu identifizieren, die sich hinter im Wesentlichen anonymen Konten verbergen. Ein Benutzer kann mehrere Konten haben oder gefälschte Konten erstellen, wenn ein Konto verdächtig ist oder als bösartig erkannt wird. Eine Organisation, die über genügend Ressourcen verfügt, kann eine ganze Armee solcher Konten aufbauen und mit Personal ausstatten.
Sechstens gibt es bei den meisten Open-Source-Projekten keinen klar definierten Notfallplan. Die Wiederherstellung eines bekannten guten Zustands ist eine Herausforderung, wenn es schwierig ist, überhaupt festzustellen, was dieser bekannte gute Zustand ist. Während ein Konto für diesen Angriff verantwortlich gemacht wird, ist es ungewiss, ob es das einzige war, das verwendet wurde.
Der mögliche Vorbehalt
Die Analyse des Ablaufs dieses Vorfalls deutet darauf hin, dass ein gut finanzierter, hoch qualifizierter Bedrohungsakteur oder eine Gruppe beteiligt war. Einige bemerkenswerte Beobachtungen sind:
- Jia Tan scheint einem 9 bis 5 (oder 6) Arbeitstag zu folgen. Die Commit- und GitHub-Aktivitäten legen dieses Muster naheDie Wochenenden und Feiertage, die mit bestimmten Ländern übereinstimmen, sind auf den ersten Blick erkennbar. Es ist jedoch zu beachten, dass Zeitstempel in Git-Commits nach Belieben manipuliert werden können, und im Vergleich zu den Kenntnissen, die im Backdoor-Code demonstriert werden, ist es trivial, die Zeit in einem Commit zu ändern.
- Jia Tan hat Code zu mehreren Projekten außerhalb von xz beigetragen. Das Konto hat sogar Code für Googles OSS-Fuzzeingereicht, einem Tool, das bösartiges oder fehlerhaftes Verhalten in Open-Source-Projekten aufspüren soll, sowie für mehrere andere Projekte im Zusammenhang mit Kompression. All dieser Code steht nun auf dem Prüfstand und ist nicht mehr vertrauenswürdig.
- Merkwürdigerweise weicht die Zeitzone der Commits, in die die bösartigen Dateien hochgeladen wurden, von der typischen Zeitzone ab, die mit dem Konto von Jia Tan verbunden ist. Eine detaillierte Analyse dieser Unstimmigkeit finden Sie hierEs besteht jedoch die Möglichkeit, dass das Entwicklerkonto kompromittiert wurde und nicht absichtlich benutzt wurde. Dies ist zwar nach wie vor eine Möglichkeit, aber andere Aspekte des Vorfalls machen es weniger plausibel. Nichtsdestotrotz ist dies eine Überlegung wert.
Schlussbemerkungen
Diese Geschichte ist wahrscheinlich noch lange nicht vorbei. Die bisherige Reaktion bestand darin, das GitHub-Repository von xz zu schließen, die Distributionspakete auf eine ältere Version zurückzusetzen und andere Commits des vermeintlich verantwortlichen Nutzers neu zu bewerten.
Zu den offenen Fragen gehören:
- Dies ist einer der raffiniertesten Angriffe auf die Lieferkette, die es bisher gab. Es ist schwer vorstellbar, dass es sich um das Werk eines einzelnen Hackers handelt. Wer steckt dahinter? Wenn Jia Tan sich an einen Arbeitsplan gehalten hat, welches Land, welche Organisation oder Gruppe hat dann das Gehalt gezahlt?
- Die Aufrechterhaltung einer Operation über mehr als zwei Jahre hinweg erfordert erhebliche Ressourcen und Anstrengungen. Was war das Endziel? Letztendlich wären alle Debian- und Red Hat-basierten Systeme kompromittiert worden. Wer würde davon profitieren, wenn er Zugang zu allen Systemen hätte, auf denen diese Distributionen laufen?
- Zeit und Zeitzonen lassen sich in Commit-Nachrichten leicht manipulieren. Wurden sie absichtlich so eingestellt, dass sie auf bestimmte Zonen verweisen?
- Wurde der gesamte bösartige Code identifiziert? Gibt es noch weitere Nutzdaten, die noch entdeckt werden müssen?
- War sshd der einzige Zielprozess?
- Welche anderen Projekte waren von dem Angriff betroffen?
Im Bereich der Cybersicherheit weichen wir ständig den Kugeln aus. Bis wir es nicht mehr tun. Und das Kuriose ist, dass wir die Kugel, die uns erwischt, nicht einmal sehen, bevor es zu spät ist.
Möchten Sie mehr über CVEs (Common Vulnerabilities and Exposures) erfahren und die Bedeutung von CVEs für die IT-Sicherheit verstehen? Sehen Sie sich unsere LinuxTalk mit Tuxcare Youtube Serie EP2 an
In unserem Linux Talk mit TuxCare Youtube Seie Ep 4 erfahren Sie mehr über die jüngste xz-Kompromittierung, was passiert ist, wie es dazu kam und welche Auswirkungen es auf die Open-Source-Community hat.
