Xz Backdoor: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
(Die Seite wurde neu angelegt: „* Ein Backdoor in SSH wurde durch die Bibliotheken liblzma 5.6.0 und 5.6.1 in Debian und Fedora eingebaut * Es erlaubt dem Inhaber eines speziellen privaten Sc…“) |
|||
| (13 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | * Ein Backdoor in SSH wurde durch | + | [[Kategorie:Hacking]] |
| − | * | + | =Tja= |
| − | * | + | [[Datei:Xz-backdoor.png|300px]] |
| − | * Die Entdeckung der | + | |
| + | =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 [https://www.openwall.com/lists/oss-security/2024/03/29/4 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 = | ||
| + | * 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 | ||
Aktuelle Version vom 6. Oktober 2025, 18:59 Uhr
Tja
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)