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 haben ergeben, dass die Backdoor die Remoteausführung von Code (RCE, Remote Code Execution) 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, schien Jia Tan eine interessante Form von Social-Engineeringzu verwenden: 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 wurden.
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.
Ein verschleiertes gemeinsames Objekt, das in Testdateien ausgeblendet ist, wird eingeschlossen.
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 hinzugefügt zu .gitignore).
Landlocking,eine Sicherheitsfunktion zum Einschränken von Prozessberechtigungen, wird deaktiviert.
Die Ausführung besteht ebenfalls aus mehreren Phasen:
Das schädliche Skript build-to-host.m4 wird während der Erstellung 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) durchund decodiert sie in ein anderes Skript.
Dieses Skript extrahiert dann ein gemeinsames Objekt (liblzma_la-crc64-fast.o), das zum Kompilierungsprozess von liblzma hinzugefügt wird.
Dieser Prozess ist zugegebenermaßen sehr komplex. Wir empfehlen die Infografikvon Thomas Roccia, die eine hervorragende visuelle Referenz und eine detaillierte Analyse bietet.
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 könnte (Abbildung 1).
Diese Funktion wird dann auf eine weitere schädliche Funktion verwiesen, die laut den von Filippo Valsordaveröffentlichten Studien einen Befehl aus dem Zertifikat des authentifizierenden Clients extrahiert (nachdem überprüft wurde, dass es sich um den Angreifer handelt) und ihn zur Ausführung an „system() function“ weiterleitet, wodurch die RCE vor der Authentifizierung ermöglicht wird.
Abb. 1: Der liblzma-Hooking-Prozess
Eine ausführlichere Erklärung zu den Teilen der Backdoor finden Sie im Beitragvon Andres Freund auf Openwall.
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 von der Cybersecurity and Infrastructure Security Agency (CISA) empfohlene Vorgehensweise beinhaltet das Zurückstufen auf eine nicht kompromittierte Version, wie 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 kann.
Unser Threat Hunting-Service, Akamai Hunt, kann solche Anomalien erkennen – z. B. durch ständige Überwachung einer Baseline für Prozessaktivität und der untergeordneten Prozesse.
Kill Switch
Laut einiger Analysen der Backdoorscheint sie eine „Kill Switch“-Umgebungsvariable zu haben. Wenn der Schlüssel yolAbejyiejuvnup=Evjtgvsh5okmkAvj zu den Umgebungsvariablen des Systems hinzugefügt wird, kann die Backdoor möglicherweise deaktiviert werden.
Quellen
