Xz Backdoor: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
Zeile 9: Zeile 9:
 
* Die Entdeckung geht auf Andres Freund zurück (oss-security, 29.03.2024).
 
* 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.
 
* 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=
 
=Technische Details=

Aktuelle Version vom 6. Oktober 2025, 18:59 Uhr

Tja

Xz-backdoor.png

Grundsätzliches

  • 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)

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)

Links