Am Freitag erschütterte ein einzelner Entwickler von Microsoft die Welt, als er enthüllte, dass absichtlich eine Hintertür in xz Utils eingebaut wurde, einem Open-Source-Datenkompressionsprogramm, das auf fast allen Installationen von Linux und anderen Unix-ähnlichen Betriebssystemen verfügbar ist. Es ist wahrscheinlich, dass die Person oder die Personen hinter diesem Projekt Jahre daran gearbeitet haben. Sie standen vermutlich kurz davor, die Hintertür-Aktualisierung in Debian und Red Hat, den beiden größten Linux-Distributionen, zu integrieren, als ein Softwareentwickler mit scharfem Blick etwas Verdächtiges bemerkte.
Weitere Lesungen
Eine in einem weit verbreiteten Linux-Utility gefundene Hintertür zielt auf verschlüsselte SSH-Verbindungen ab
„Dies könnte der am besten durchgeführte Supply-Chain-Angriff sein, von dem wir in der Öffentlichkeit gehört haben, und es ist ein Alptraumszenario: bösartig, kompetent, autorisierter Upstream in einer weit verbreiteten Bibliothek“, sagte der Software- und Kryptografieingenieur Filippo Valsorda über die Bemühung, die beängstigend nah am Erfolg war.
Forscher haben das Wochenende damit verbracht, Hinweise zu sammeln. Hier ist, was wir bisher wissen.
Was ist xz Utils?
xz Utils ist nahezu allgegenwärtig in Linux. Es bietet verlustfreie Datenkompression auf praktisch allen Unix-ähnlichen Betriebssystemen, einschließlich Linux. xz Utils bietet kritische Funktionen für die Kompression und Dekompression von Daten bei allen Arten von Operationen. xz Utils unterstützt auch das ältere .lzma-Format, was diese Komponente noch entscheidender macht.
Was ist passiert?
Andres Freund, ein Entwickler und Ingenieur, der an Microsofts PostgreSQL-Angeboten arbeitet, hatte kürzlich Leistungsprobleme bei einem Debian-System untersucht, die bei SSH, dem am weitesten verbreiteten Protokoll für das Remote-Login auf Geräte über das Internet, auftraten. Genauer gesagt verbrauchten SSH-Logins zu viele CPU-Zyklen und erzeugten Fehler mit valgrind, einem Dienstprogramm zur Überwachung des Computer-Speichers.
Durch puren Zufall und Freunds sorgfältiges Auge entdeckte er schließlich, dass die Probleme das Ergebnis von Aktualisierungen waren, die an xz Utils vorgenommen worden waren. Am Freitag wandte sich Freund an die Open Source Security List, um zu enthüllen, dass die Aktualisierungen das Ergebnis von jemandem waren, der absichtlich eine Hintertür in die Kompressionssoftware eingebaut hatte.
Es ist schwer, die Komplexität der sozialen Ingenieurskunst und die Funktionsweise der Hintertür zu überschätzen. Thomas Roccia, ein Forscher bei Microsoft, veröffentlichte eine Grafik auf Mastodon, die hilft, das weitreichende Ausmaß des fast erfolgreichen Unterfangens zu visualisieren, eine Hintertür mit einer Reichweite zu verbreiten, die das SolarWinds-Ereignis von 2020 in den Schatten gestellt hätte.
Was macht die Hintertür?
Schadcode, der zu den xz Utils-Versionen 5.6.0 und 5.6.1 hinzugefügt wurde, änderte die Funktionsweise der Software. Die Hintertür manipulierte sshd, die ausführbare Datei, die für die Herstellung von Remote-SSH-Verbindungen verwendet wird. Jeder, der im Besitz eines vorher festgelegten Verschlüsselungsschlüssels war, konnte beliebigen Code seiner Wahl in ein SSH-Login-Zertifikat einfügen, hochladen und auf dem mit der Hintertür versehenen Gerät ausführen. Niemand hat tatsächlich gesehen, dass Code hochgeladen wurde, daher ist nicht bekannt, welchen Code der Angreifer ausführen wollte. Theoretisch könnte der Code alles Mögliche ermöglichen, einschließlich des Diebstahls von Verschlüsselungsschlüsseln oder der Installation von Malware.
Warte, wie kann ein Komprimierungsprogramm einen so sicherheitskritischen Prozess wie SSH manipulieren?
Jede Bibliothek kann die inneren Abläufe jeder ausführbaren Datei, gegen die sie verlinkt ist, manipulieren. Oft wird der Entwickler der ausführbaren Datei einen Link zu einer Bibliothek herstellen, die benötigt wird, damit sie ordnungsgemäß funktioniert. OpenSSH, die beliebteste sshd-Implementierung, verlinkt die liblzma-Bibliothek nicht, aber Debian und viele andere Linux-Distributionen fügen einen Patch hinzu, um sshd mit systemd zu verlinken, einem Programm, das eine Vielzahl von Diensten während des Systemstarts lädt. Systemd wiederum verlinkt mit liblzma, und dies ermöglicht es xz Utils, Kontrolle über sshd auszuüben.
Wie kam es zu dieser Hintertür?
Es scheint, dass diese Hintertür Jahre in der Entwicklung war. Im Jahr 2021 machte jemand mit dem Benutzernamen JiaT75 seinen ersten bekannten Commit zu einem Open-Source-Projekt. Im Rückblick ist die Änderung am libarchive-Projekt verdächtig, weil es die safe_fprint-Funktion durch eine Variante ersetzte, die seit langem als weniger sicher gilt. Niemand bemerkte es zu der Zeit.
Im folgenden Jahr reichte JiaT75 einen Patch über die xz Utils-Mailingliste ein und fast sofort trat ein noch nie zuvor gesehener Teilnehmer namens Jigar Kumar der Diskussion bei und argumentierte, dass Lasse Collin, der langjährige Betreuer von xz Utils, die Software nicht oft oder schnell genug aktualisiert hatte. Kumar drängte Collin mit Unterstützung von Dennis Ens und mehreren anderen Personen, die nie eine Präsenz in der Liste hatten, einen zusätzlichen Entwickler für die Wartung des Projekts aufzunehmen.
Im Januar 2023 machte JiaT75 ihren ersten Commit zu xz Utils. In den folgenden Monaten wurde JiaT75, der den Namen Jia Tan verwendete, zunehmend in xz Utils-Angelegenheiten involviert. Zum Beispiel ersetzte Tan Collins‘ Kontaktinformationen durch ihre eigenen auf oss-fuzz, einem Projekt, das Open-Source-Software auf ausnutzbare Schwachstellen scannt. Tan bat auch darum, dass oss-fuzz die ifunc-Funktion während des Tests deaktiviert, eine Änderung, die verhinderte, dass es die bösartigen Änderungen entdeckte, die Tan bald an xz Utils vornehmen würde.
Im Februar dieses Jahres gab Tan Commits für die Versionen 5.6.0 und 5.6.1 von xz Utils heraus. Die Updates implementierten die Hintertür. In den folgenden Wochen appellierten Tan oder andere an Entwickler von Ubuntu, Red Hat und Debian, die Updates in ihre Betriebssysteme zu integrieren. Schließlich gelangte eines der beiden Updates in die folgenden Releases, laut der Sicherheitsfirma Tenable:
VERTEILUNG BERICHTIGUNG ANMERKUNGEN
- Fedora Rawhide https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users Fedora Rawhide ist die Entwicklungsverteilung von Fedora Linux
- Fedora 41 https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
- Debian-Testing, Unstable und Experimental-Distributionen Versionen 5.5.1alpha-0.1 bis 5.6.1-1. https://lists.debian.org/debian-security-announce/2024/msg00057.html
- openSUSE Tumbleweed und openSUSE MicroOS https://news.opensuse.org/2024/03/29/xz-backdoor/ Die Version mit der Hintertür von xz wurde zwischen dem 7. und dem 28. März in Tumbleweed und MicroOS eingeschlossen
- Kali Linux https://www.kali.org/blog/about-the-xz-backdoor/ Die Version mit der Hintertür von xz wurde zwischen dem 26. und 28. März in Kali Linux (xz-utils 5.6.0-0.2) eingeschlossen
Können Sie mehr darüber sagen, was diese Hintertür tut?
Kurz gesagt, sie ermöglicht es jemandem mit dem richtigen privaten Schlüssel, sshd, die ausführbare Datei, die für die Herstellung von SSH-
Verbindungen verantwortlich ist, zu übernehmen und von dort aus bösartige Befehle auszuführen. Die Hintertür wird durch einen fünfstufigen Loader implementiert, der eine Reihe von einfachen, aber cleveren Techniken verwendet, um sich zu verstecken. Sie bietet auch die Mittel für die Lieferung neuer Payloads, ohne dass größere Änderungen erforderlich sind.
Diese Hintertür hat mehrere Komponenten. Auf hoher Ebene:
Die Release-Tarballs, die Upstream veröffentlicht, haben nicht den gleichen Code, den GitHub hat. Dies ist bei C-Projekten üblich, damit die nachgeschalteten Verbraucher sich nicht daran erinnern müssen, wie man Autotools und Autoconf ausführt. Die Version von build-to-host.m4 in den Release-Tarballs unterscheidet sich stark von der Upstream-Version auf GitHub.
Es gibt auch in der Tests/-Ordner innerhalb des Git-Repositorys gefertigte Testdateien. Diese Dateien befinden sich in den folgenden Commits:
tests/files/bad-3-corrupt_lzma2.xz (cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0, 74b138d2a6529f2c07729d7c77b1725a8e8b16f1)
tests/files/good-large_compressed.lzma (cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0, 74b138d2a6529f2c07729d7c77b1725a8e8b16f1)
Ein Skript, das von build-to-host.m4 aufgerufen wird, entpackt diese bösartigen Testdaten und verwendet sie, um den Build-Prozess zu modifizieren.
IFUNC, ein Mechanismus in glibc, der indirekte Funktionsaufrufe ermöglicht, wird verwendet, um zur Laufzeit Hooking/Umleitung von OpenSSHs Authentifizierungsroutinen durchzuführen. IFUNC ist ein Werkzeug, das normalerweise für legitime Dinge verwendet wird, aber in diesem Fall für diesen Angriffsweg ausgenutzt wird.
Normalerweise veröffentlicht Upstream Release-Tarballs, die sich von den automatisch generierten auf GitHub unterscheiden. In diesen modifizierten Tarballs ist eine bösartige Version von build-to-host.m4 enthalten, um ein Skript während des Build-Prozesses auszuführen.
Dieses Skript (zumindest in den Versionen 5.6.0 und 5.6.1) überprüft verschiedene Bedingungen wie die Architektur der Maschine. Hier ist ein Ausschnitt des bösartigen Skripts, das von build-to-host.m4 entpackt wird und eine Erklärung, was es tut:
if ! (echo „$build“ | grep -Eq „^x86_64“ > /dev/null 2>&1) && (echo „$build“ | grep -Eq „linux-gnu$“ > /dev/null 2>&1);then
Wenn amd64/x86_64 das Ziel des Builds ist
Und wenn das Ziel den Namen linux-gnu verwendet (überprüft meist die Verwendung von glibc)
Es wird auch das verwendete Toolchain überprüft:if test „x$GCC“ != ‚xyes‘ > /dev/null 2>&1;then
exit 0
fi
if test „x$CC“ != ‚xgcc‘ > /dev/null 2>&1;then
exit 0
fi
LDv=$LD“ -v“
if ! $LDv 2>&1 | grep -qs ‚GNU ld‘ > /dev/null 2>&1;then
exit 0
Und wenn Sie versuchen, ein Debian- oder Red-Hat-Paket zu bauen:if test -f „$srcdir/debian/rules“ || test „x$RPM_ARCH“ = „xx86_64“;then
Dieser Angriff scheint also auf amd64-Systeme abzuzielen, die glibc verwenden und entweder von Debian oder Red-Hat-basierten Distributionen abgeleitet sind. Andere Systeme könnten zu diesem Zeitpunkt anfällig sein, aber wir wissen es nicht.
In einem Online-Interview bestätigte der Entwickler und Reverse-Engineer HD Moore den Verdacht von Sam James, dass die Hintertür entweder Debian- oder Red-Hat-Distributionen abzielte.„Der Angriff war hinterhältig, insofern er nur die letzten Schritte der Hintertür durchführte, wenn Sie die Bibliothek auf amd64 (Intel x86 64-Bit) bauten und ein Debian- oder ein RPM-Paket bauten (anstatt es für eine lokale Installation zu verwenden)“, schrieb er. Er paraphrasierte Beobachtungen von Forschern, die gemeinsam das Wochenende damit verbrachten, die bösartigen Updates zu analysieren, und fuhr fort:
Bei der Überprüfung eines SSH-öffentlichen Schlüssels, wenn der öffentliche Schlüssel eine bestimmte Fingerabdruckfunktion entspricht, werden die Schlüsselinhalte mit einem vorab geteilten Schlüssel entschlüsselt, bevor der öffentliche Schlüssel tatsächlich überprüft wird. Die entschlüsselten Inhalte werden dann direkt an das System weitergegeben.
Wenn der Fingerabdruck nicht übereinstimmt oder die entschlüsselten Inhalte nicht einem bestimmten Format entsprechen, fällt es auf die reguläre Schlüsselüberprüfung zurück und niemand ist klüger. Die Hintertür ist super hinterhältig. Sie nutzt ein wenig bekanntes Feature der glibc, um eine Funktion zu haken. Sie wird nur ausgelöst, wenn die mit einer Hintertür versehene xz-Bibliothek von einem /usr/bin/sshd-Prozess auf einer der betroffenen Distributionen geladen wird. Es mag viele andere Hintertüren geben, aber die, über die alle sprechen, verwendet das Funktionsumleitungszeug, um den Haken hinzuzufügen. Die Payload wurde in gefälschte xz-Testdateien kodiert und läuft effektiv als Shellcode, der den SSH-RSA-Schlüsselüberprüfungscode ändert, sodass ein magischer öffentlicher Schlüssel (der während der normalen Authentifizierung gesendet wird) dem Angreifer Zugang gewährt
Ihr großes Schema war:
- schleichend die Release-Tarballs, aber nicht den Quellcode, mit einer Hintertür versehen
- Sockenpuppen-Accounts verwenden, um die verschiedenen Linux-Distributionen davon zu überzeugen, die neueste Version zu ziehen und zu verpacken
- sobald diese Distributionen sie ausgeliefert hatten, konnten sie das System jedes nachgeschalteten Benutzers/Unternehmens/usw. übernehmen
Forscher des Netzwerkunternehmens Akamai erklären auch gut, wie die Hintertür funktioniert:
Die Hintertür ist ziemlich komplex. Zum einen finden Sie sie nicht im xz GitHub-Repository (das derzeit deaktiviert ist, aber das ist neben dem Punkt). In dem, was wie ein Versuch scheint, Entdeckung zu vermeiden, anstatt Teile der Hintertür in das öffentliche Git-Repository zu pushen, hat der bösartige Betreuer sie nur in Quellcode-Tarball-Veröffentlichungen enthalten. Dies führte dazu, dass Teile der Hintertür relativ verborgen blieben, während sie immer noch während des Build-Prozesses von abhängigen Projekten verwendet wurden.
Die Hintertür besteht aus vielen Teilen, die über mehrere Commits eingeführt wurden:
Verwendung von IFUNCs im Build-Prozess, die verwendet werden, um die Symbolauflösungsfunktionen durch die Malware zu kapern
Einschließen eines verschleierten gemeinsam genutzten Objekts, das in Testdateien versteckt ist
Ausführen eines Skripts, das während des Build-Prozesses der Bibliothek festgelegt wird, das das gemeinsam genutzte Objekt extrahiert (nicht im Repository enthalten, nur in Veröffentlichungen, aber zu .gitignore hinzugefügt)
Deaktivieren von Landlocking, das eine Sicherheitsfunktion ist, um die Privilegien von Prozessen einzuschränken
Die Ausführungskette besteht auch aus mehreren Stufen:
- Das bösartige Skript build-to-host.m4 wird während des Build-Prozesses der Bibliothek ausgeführt und dekodiert die „Test“-Datei bad-3-corrupt_lzma2.xz in ein Bash-Skript
- Das Bash-Skript führt dann einen komplizierteren Dekodierungsprozess an einer anderen „Test“-Datei, good-large_compressed.lzma, durch und dekodiert sie in ein weiteres Skript
- Dieses Skript extrahiert dann ein gemeinsam genutztes Objekt liblzma_la-crc64-fast.o, das dem Kompilierungsprozess von liblzma hinzugefügt wird
- Dieser Prozess ist zugegebenermaßen schwer zu verfolgen. Wir empfehlen Thomas Roccias Infografik für eine großartige visuelle Referenz und eine eingehende Analyse.
Das gemeinsam genutzte Objekt selbst wird in liblzma kompiliert und ersetzt den regulären Funktionsnamenauflösungsprozess. Während des Ladens eines (beliebigen) Prozesses werden Funktionsnamen in tatsächliche Zeiger auf den Prozessspeicher aufgelöst, die auf den Binärcode zeigen. Die bösartige Bibliothek greift in den Funktionsauflösungsprozess ein, sodass sie den Funktionszeiger für die OpenSSH-Funktion RSA_public_decrypt ersetzen kann.
Sie weist dann diese Funktion einer bösartigen eigenen zu, die laut einer von Filippo Valsorda veröffentlichten Forschung ein Kommando aus dem Zertifikat des authentifizierenden Clients extrahiert (nachdem überprüft wurde, dass es der Bedrohungsakteur ist) und es an die System()-Funktion zur Ausführung weitergibt, wodurch RCE vor der Authentifizierung erreicht wird.
Gibt es eine CVE-Tracking-Bezeichnung?
Ja, es ist CVE-2024-3094.
Wie weiß ich, ob die Hintertür auf meinem Gerät vorhanden ist?
Es gibt mehrere Möglichkeiten. Eine davon ist diese Seite der Sicherheitsfirma Binarly. Das Tool erkennt die Implementierung von IFUNC und basiert auf Verhaltensanalyse. Es kann automatisch Invarianten erkennen, falls eine ähnliche Hintertür anderswo implantiert wird.
Es gibt auch ein Projekt namens xzbot. Es bietet Folgendes:
Honeypot: gefälschter anfälliger Server, um Exploit-Versuche zu erkennen
ed448-Patch: Patch liblzma.so, um unseren eigenen ED448-öffentlichen Schlüssel zu verwenden
Backdoor-Format: Format der Backdoor-Nutzlast
Backdoor-Demo: CLI, um das RCE unter der Annahme der Kenntnis des ED448-Privatschlüssels auszulösen
