Alles, was Sie über die XZ Utils Backdoor wissen müssen
Zusammenfassung
CVE-2024-3094 ist eine Sicherheitslücke, die in der Open-Source-Bibliothek XZ Utils entdeckt wurde und auf schädlichen Code zurückzuführen ist, der von einem der Betreiber in die Bibliothek übertragen wurde.
Sie wurde ursprünglich als Backdoor für die Umgehung der SSH-Authentifizierung gemeldet, doch weitere Analysen deuten darauf hin, dass die Backdoor tatsächlich eine Remotecodeausführung (Remote Code Execution, RCE) ermöglicht.
Vor etwa zwei Jahren begann der Angreifer, zum XZ-Projekt beizutragen und langsam an Glaubwürdigkeit zu gewinnen, bis er Verantwortung als Betreiber übernahm. Solche langfristigen Operationen werden in der Regel von staatlich geförderten Cyberkriminellen durchgeführt, eine genaue Zuordnung ist derzeit jedoch nicht möglich.
Da die Backdoor die neuesten Versionen von XZ Utils betrifft, wird empfohlen, auf eine nicht kompromittierte Version zurückzustufen. In diesem Blogbeitrag bieten wir weitere potenzielle Abwehrmaßnahmen, um den Angriff einzudämmen.
Hintergrund
XZ Utils und die zugrunde liegende Bibliothek „liblzma“ sind Open-Source-Projekte für die Implementierung der lzma-Komprimierung und -Dekomprimierung. Sie sind in vielen Linux-Distributionen enthalten, bei Entwicklern sehr beliebt und werden im gesamten Linux-Ökosystem in großem Umfang eingesetzt.
Vor fast zwei Jahren trat ein Entwickler unter dem Namen Jia Tan dem Projekt bei und begann, Pull Requests für verschiedene Fehlerbehebungen oder Verbesserungen zu erstellen. Das ist nichts Außergewöhnliches; noch scheint in der Open-Source-Welt alles seinen gewohnten Gang zu gehen. Nachdem Jia Tan aber Vertrauen und Glaubwürdigkeit aufgebaut hatte, erhielt er nach und nach Berechtigungen für das Repository und schließlich die Rechte für das Freigabemanagement.
Um diese Berechtigungen zu erhalten, verwendete Jia Tan anscheinend eine interessante Form von Social Engineering: Er nutzte gefälschte Konten, um unzählige Funktionsanforderungen und Beschwerden über Fehler zu senden, um Druck auf den ursprünglichen Betreiber auszuüben. Das führte schließlich dazu, dass dem Repository ein weiterer Betreiber hinzugefügt werden musste.
Nachdem sich Jia Tan etwa zwei Jahre lang an der Weiterentwicklung des Codes beteiligt hatte, nahm er 2023 einige Änderungen an XZ vor, die mit der Version 5.6.0 veröffentlicht wurden. Zu diesen Änderungen gehörte eine ausgefeilte Backdoor.
Die Backdoor
Die Backdoor ist ziemlich komplex. Zunächst einmal ist sie im xz-GitHub-Repository nicht zu finden (das derzeit deaktiviert ist, aber das ist nicht der Punkt). Bei dem augenscheinlichen Versuch, eine Erkennung zu vermeiden, hat der Angreifer Teile der Backdoor nur in die Tarball-Versionen des Quellcodes aufgenommen, statt sie in das öffentliche Git-Repository zu übertragen. So blieben Teile der Backdoor einigermaßen verborgen, während sie bei der Erstellung von abhängigen Projekten verwendet wurde.
Die Backdoor besteht aus vielen Teilen, die über mehrere Commits eingeführt werden:
Bei der Erstellung werden IFUNCs verwendet, um die Funktionen zur Symbolauflösung mit der Malware zu übernehmen.
Es wird ein verschleiertes gemeinsames Objekt verwendet, das in Testdateien versteckt ist.
Ein Skript wird während des Erstellungsprozesses der Bibliothek ausgeführt, die das freigegebene Objekt extrahiert (nur in den Versionen enthalten, nicht im Repository, aber zu .gitignore hinzugefügt).
Landlock wird deaktiviert – dies ist eine Sicherheitsfunktion zum Einschränken von Prozessberechtigungen.
Die Ausführung besteht ebenfalls aus mehreren Phasen:
Das schädliche Skript build-to-host.m4 wird während des Erstellungsprozesses der Bibliothek ausgeführt und decodiert die „Test“-Datei bad-3-corrupt_lzma2.xz in ein Bash-Skript.
Das Bash-Skript führt dann einen komplizierteren Decodierungsprozess für eine andere „Test“-Datei (good-large_compressed.lzma) durch und decodiert sie in ein anderes Skript.
Dieses Skript extrahiert dann das gemeinsame Objekt liblzma_la-crc64-fast.o, das dem Kompilierungsprozess von liblzma hinzugefügt wird.
Dieser Prozess ist zugegebenermaßen sehr komplex. Wir empfehlen die Infografik von Thomas Roccia als gute visuelle Referenz und detaillierte Analyse.
Das gemeinsame Objekt selbst wird in liblzma kompiliert und ersetzt den regulären Auflösungsprozess für Funktionsnamen. Während des Ladens von (beliebigen) Prozessen werden Funktionsnamen in tatsächliche Zeiger im Prozessspeicher aufgelöst, die auf den Binärcode verweisen. Die schädliche Bibliothek beeinträchtigt den Funktionsauflösungsvorgang, sodass der Funktionszeiger für die OpenSSH-Funktion RSA_public_decrypt ersetzt werden kann (Abbildung 1).
Anschließend zeigt er auf eine eigene Schadfunktion, die laut einer von Filippo Valsorda veröffentlichten Studie einen Befehl aus dem Zertifikat des Clients extrahiert, der sich authentifiziert (nachdem überprüft wurde, dass es sich hierbei um den Angreifer handelt). Anschließend wird dieser Befehl zur Ausführung an die Funktion „system()“ übergeben, wodurch bereits vor der Authentifizierung eine RCE erreicht wird.
Abb. 1: Der liblzma-Hooking-Prozess
Für eine ausführlichere Erklärung der Backdoor-Komponenten können Sie sich den openwall-Beitrag von Andres Freund ansehen.
Potenzielle Auswirkungen
Derzeit scheint es, als ob die Backdoor zum SSH-Daemon auf dem anfälligen Gerät hinzugefügt wird, sodass ein Remote-Angreifer beliebigen Code ausführen kann. Das bedeutet, dass jeder Computer mit dem anfälligen Paket, das SSH über das Internet zugänglich macht, potenziell gefährdet ist.
Diese Backdoor wäre beinahe zu einem der bedeutendsten Eindringlinge geworden, der die SolarWinds-Backdoor in den Schatten gestellt hätte. Die Angreifer konnten fast sofort auf jedes Linux-Gerät zugreifen, auf dem eine infizierte Version von XZ ausgeführt wurde, darunter Fedora, Ubuntu und Debian. Fast.
Es gab aber jemanden, der das verhindert hat – Andres Freund. Nachdem Andres ein Problem mit einer Latenz von 500 ms untersucht hatte, das nach einem Software-Update auftrat, konnte er das Problem bis zum XZ-Paket zurückverfolgen und schließlich die Backdoor identifizieren.
Dies wirft natürlich viele Fragen auf. Wir hatten Glück. Wenn diese Backdoor nicht von einem neugierigen Ingenieur entdeckt worden wäre, wie lange wäre sie wohl aktiv geblieben?
Und was vielleicht noch besorgniserregender ist: Was, wenn das schon einmal passiert ist?
Erkennung und Abwehr
Versionsverwaltung
Die Cybersecurity and Infrastructure Security Agency (CISA) empiehlt ein Downgrade auf eine nicht kompromittierte Version, z. B. 5.4.6.
Um zu erfahren, welche Version von XZ Utils oder liblzma derzeit auf Ihren Systemen vorhanden ist, können Sie die folgende Abfrage in Akamai Guardicore Segmentation Insight ausführen, um nach geladenen Instanzen der liblzma-Bibliothek zu suchen (Abbildung 2).
SELECT DISTINCT path AS liblzma_path
FROM process_memory_map
WHERE LOWER(path) LIKE "%liblzma%"
Abb. 2: Abfrage für geladene Instanzen von liblzma
Alternativ können Sie die folgende Abfrage ausführen, um den Paketmanager für die installierte Version zu finden.
SELECT name AS vulnerable_item, 'DEB' AS type, version
FROM deb_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
UNION
SELECT name AS vulnerable_item, 'RPM' AS type, version
FROM rpm_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
Natürlich können Sie auch Filter verwenden, um nur gefährdete Assets anzuzeigen.
SELECT path AS vulnerable_item, "Loaded Library" AS type, '5.6%' AS version
FROM process_memory_map
WHERE LOWER(path) LIKE "%liblzma%5.6%"
SELECT name AS vulnerable_item, 'DEB' AS type, version
FROM deb_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
AND version LIKE '5.6.%'
UNION
SELECT name AS vulnerable_item, 'RPM' AS type, version
FROM rpm_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
AND version LIKE '5.6.%'
Threat Hunting
Da die Backdoor tatsächlich Systembefehle ausführt und nicht nur eine Authentifizierung zulässt, können Sie dieses Verhalten möglicherweise über die Prozessverfolgung zu erkennen.
Normalerweise wird bei der Anmeldung eine neue Shell für den Nutzer erstellt, die den Standard-Shell-Prozess (wie bash) ausführt. Mit dieser Backdoor wird der schädliche Befehl jedoch tatsächlich vom SSH-Daemon-Prozess, sshd, ausgeführt, was eine Anomalie auslösen könnte.
Unser Threat-Hunting-Service, Akamai Hunt, verfügt über Methoden, um solche Anomalien zu erkennen, z. B. indem er ständig eine Baseline der Prozessaktivitäten und ihrer untergeordneten Prozesse verfolgt.
Kill Switch
Nach einigen Analysen der Backdoor scheint es einen Kill Switch in Form von Umgebungsvariablen zu geben. Wenn Sie den Schlüssel yolAbejyiejuvnup=Evjtgvsh5okmkAvj zu den Umgebungsvariablen des Systems hinzufügen, wird die Backdoor möglicherweise deaktiviert.
Quellen
