Xz Backdoor

Tja

Grundsätzliches

• Animation: APT und der xz-Angriff (einfach)
• Ein Backdoor in SSH wurde durch manipulierte Release-Artefakte der XZ-/liblzma-Distribution (xz 5.6.0 und 5.6.1) eingeschleust.
• Unter bestimmten Bedingungen kann diese Hintertür die SSH-Authentifizierung umgehen und Remote Code Execution bzw. Root-Zugriff gegen den SSH-Daemon (sshd) ermöglichen.
• Der Angriff kombinierte jahrelanges Social Engineering mit stark verschleierter Payload-Platzierung in Release-Tarballs.
• Die Entdeckung geht auf Andres Freund zurück (oss-security, 29.03.2024).
• Die Hintertür wurde über manipulierte Build-/m4-Skripte und versteckte Testartefakte in Tarballs zur Laufzeit aktiv.

Warum betrifft ein gepatchtes xz/liblzma SSH?

• liblzma ist eine Shared-Library; wenn ein Programm (z. B. sshd) diese Bibliothek zur Laufzeit lädt, wird der Code der Bibliothek in den Prozessraum von sshd eingebunden.
• Wird in die Bibliothek bösartiger Initialisierungs- oder Hook-Code eingebettet, läuft dieser Code im Kontext von sshd mit und kann Authentifizierungs-Pfad(e) beeinflussen.
• Kurz: Die Backdoor sitzt in der Bibliothek, liblzma wird von sshd geladen — daher kann ein kompromittiertes xz/liblzma direkt Verhalten in sshd auslösen, obwohl nur xz gepatcht wurde.

Technische Details

• Die Backdoor nutzte Tarball-only Artefakte (nicht klar als Klartext in der öffentlichen Git-History), z. B. modifizierte m4/build-Skripte und eingebettete Testdateien, die bei Release-Erstellung extrahiert wurden.
• Mechanismus: Hooking in OpenSSH-Relevante Pfade (Analysen deuten auf Eingriff in RSA-Verifikationspfade hin); bei Erkennung einer speziellen Signatur wurde ein Payload ausgeführt.
• Die Aktivierung erfolgte nur unter sehr spezifischen Build-/Laufzeitbedingungen, wodurch die Erkennung erschwert wurde.
• Die Payload war obfuskiert und enthielt Anti-Debugging-/Verschleierungsmaßnahmen.

Timeline

2005–2008

• Lasse Collin entwickelt mit Hilfe einiger anderer das .xz-Dateiformat, welches den LZMA-Algorithmus für Komprimierung verwendet
• Aufgrund der Effizienz der Komprimierung wächst die Verwendung der Software

2015–2020

• Lasse Collin äußert öffentlich Erschöpfung und Burnout-Symptome
• Er beklagt, dass er das Projekt nicht mehr alleine stemmen kann und dass die Arbeitslast zu groß ist
• Diese personelle Konzentration auf einen einzigen Maintainer wird später zur Verwundbarkeit gegenüber Social-Engineering-Angriffen

2021

• Der GitHub-Account JiaT75 (Jia Tan) taucht erstmals in der Open-Source-Szene auf
• Erste Beiträge sind kleine, unauffällige Patches und Tests in verschiedenen Projekten (u. a. im Umfeld von libarchive und später auch in Repositories des XZ-Ökosystems)
• Diese Patches wirkten zunächst harmlos (Bugfixes, Testcode, Build-Anpassungen) und halfen dabei, Vertrauen aufzubauen
• Ob Jia Tan eine reale Einzelperson, ein Pseudonym oder eine Gruppe ist, bleibt ungeklärt

2022

• Jia Tan reicht weitere Patches ein; einige dieser Beiträge erzeugen zusätzlichen Prüfaufwand und erfordern Bugfixes durch den Maintainer
• Durch die zusätzlichen Fehler und den damit verbundenen Aufwand steigt die Belastung von Lasse Collin weiter
• Parallel treten weitere Personas (u. a. die Persona Jigar Kumar) in Mailinglisten auf und drängen öffentlich auf Übernahme bzw. Beschleunigung von Änderungen
• Unter dem Gewicht der Arbeit und dem äußeren Druck stimmt Collin schließlich zu, Jia Tan mehr Verantwortung zu übertragen

2023

• Am 7. Januar 2023 erhält Jia Tan Commit-Rechte und darf direkt in liblzma mergen
• Im Laufe des Jahres werden Änderungen an Test- und Build-Infrastruktur vorgenommen, die später für die Einschleusung der Backdoor genutzt werden können
• Diese Änderungen erscheinen zunächst harmlos (Testcode / Infrastrukturpflege) und ziehen keine besondere Aufmerksamkeit auf sich

2024

• Am 9. März 2024 werden in scheinbar harmlosen Testdateien Codefragmente abgelegt, die beim Erstellen der Release-Tarballs extrahiert und in die Binärartefakte eingebettet werden
• Die Release-Tarballs für xz 5.6.0 und 5.6.1 enthalten so die verschleierte Backdoor (die Payload war nicht in der öffentlichen Git-History sichtbar)
• Die Hintertür ist so konzipiert, dass sie nur unter sehr spezifischen Laufzeit-/Build-Bedingungen aktiv wird und nur auf speziell signierte Schlüssel reagiert (NOBUS-Charakter)

Entdeckung

• Ende März 2024 bemerkt der Microsoft-Entwickler Andres Freund auf einem Testsystem unerklärliche CPU-Spitzen und zusätzliche Login-Latenzen (~500 ms) bei SSH-Verbindungen
• Durch Analyse der Release-Tarballs entdeckt er die obfuskierten Artefakte und meldet die Entdeckung öffentlich (oss-security, 29.03.2024)
• Kurz darauf folgen technische Analysen (Reverse Engineering) und Community-Tools zur Erkennung (YARA, osquery, Scanner wie xzbot)

Selbst prüfen

• Betroffen waren nur die Versionen xz 5.6.0 und 5.6.1. Ältere Versionen, zum Beispiel 5.4.x, enthalten die Hintertür nicht.
• Version anzeigen:

xz --version
dpkg -l xz-utils liblzma5 | grep ^ii

• Die Bibliothek, die von sshd geladen wird, zeigt:

ldd $(command -v sshd) | grep -i lzma

• Die Hintertür greift nur, wenn sshd die Bibliothek lädt. Das geschieht bei Distributionen, die OpenSSH für systemd anpassen (sshd lädt dann libsystemd, und diese lädt liblzma).
• Stabile Systeme waren nicht betroffen, weil dort noch eine ältere xz-Version (5.4.x oder älter) lief.

Reaktion & Schadensbegrenzung

• Distributionen zogen betroffene Pakete/Builds zurück oder blockierten die betroffenen Tarballs in ihren Pipelines; betroffene Versionen tauchten überwiegend in testing/unstable-Zweigen auf
• CVE-Eintrag (CVE-2024-3094) und Vendor-Advisories wurden veröffentlicht
• Scanner, YARA-Regeln und Prüfscripte wurden publiziert, um Exposure zu identifizieren

Bewertung & Lehren

• Vorgehen kombinierte Social-Engineering-Techniken (mehrere Personas, gezielter Druck) mit technischer Verschleierung — dies spricht stark für eine geplante, bösartige Operation; definitive Attribution (staatlich o. ä.) ist jedoch öffentlich nicht belegt
• Die Überlastung des Maintainers machte das Projekt besonders verwundbar; menschliche Faktoren sind ein zentraler Risikofaktor
• Konkrete Maßnahmen: strengere Signing-/Release-Hygiene, CI/Artifact-Prüfungen, Maintainer-Support, strengere Review-Prozesse, regelmäßige Audits

Quellenhinweis

• Erste öffentliche Meldung: Andres Freund auf oss-security, 29.03.2024
• Technische Analysen / Writeups (z. B. Gynvael Coldwind) und Community-Tools (xzbot)
• Diverse Vendor-Advisories / CVE-Einträge (CVE-2024-3094)

Video

• https://www.youtube.com/watch?v=8p8PHeGg--U

Links

• https://www.openwall.com/lists/oss-security/2024/03/29/4
• https://boehs.org/node/everything-i-know-about-the-xz-backdoor
• https://github.com/amlweems/xzbot
• https://tukaani.org/
• https://gynvael.coldwind.pl/?lang=en&id=782