Xz Backdoor: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
(→Tja) |
|||
| Zeile 20: | Zeile 20: | ||
= Timeline = | = Timeline = | ||
| − | == | + | == 2005–2008 == |
* Lasse Collin entwickelt mit Hilfe einiger anderer das ''.xz''-Dateiformat, welches den LZMA-Algorithmus für Komprimierung verwendet | * 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 | * 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 == | == 2021 == | ||
| − | * JiaT75 (Jia Tan) | + | * Der GitHub-Account '''JiaT75 (Jia Tan)''' taucht auf |
| − | * | + | * Erste Beiträge sind kleine, unauffällige Patches und Tests |
| − | * | + | * Ob Jia Tan eine reale Einzelperson, ein Pseudonym oder eine Gruppe ist, bleibt ungeklärt |
== 2022 == | == 2022 == | ||
| − | * Jia Tan | + | * 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 == | == 2023 == | ||
| − | * Am 7. Januar 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 == | == 2024 == | ||
| − | * Am 9. März 2024 | + | * Am 9. März 2024 werden in scheinbar harmlosen Testdateien Code-Fragmente 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 (nicht in der Git-History sichtbar) |
| + | * Die Backdoor ist so konzipiert, dass sie nur unter sehr spezifischen Laufzeit-/Buildbedingungen aktiv wird und nur auf speziell signierte Schlüssel reagiert (NOBUS-Charakter) | ||
= Entdeckung = | = Entdeckung = | ||
| − | * | + | * Ende März 2024 bemerkt der Microsoft-Entwickler Andres Freund auf einem Testsystem unerklärliche CPU-Spitzen und eine zusätzliche Login-Latenz (~500 ms) bei SSH-Verbindungen |
| − | * | + | * Durch Analyse der betroffenen Release-Tarballs findet er die obfuskierten Artefakte; am 29. März 2024 meldet er die Entdeckung öffentlich auf oss-security |
| − | * | + | * Kurz darauf erscheinen technische Analysen (Reverse Engineering) und Community-Tools zur Erkennung (YARA, osquery, Scanner wie xzbot) |
| − | * | + | |
| + | = Reaktion & Schadensbegrenzung = | ||
| + | * Distributionen ziehen betroffene Pakete/Builds zurück oder blockieren die betroffenen Tarballs in ihren Pipelines | ||
| + | * CVE-Eintrag (CVE-2024-3094) und Vendor-Advisories werden veröffentlicht | ||
| + | * Scanner, YARA-Regeln und Prüfskripte werden publiziert, um Exposure zu identifizieren | ||
| + | |||
| + | = Bewertung & Lehren = | ||
| + | * Das Vorgehen kombiniert gezielte Social-Engineering-Techniken (mehrere Personas, gezielter Druck) mit technischer Verschleierung — dies spricht stark für eine geplante, bösartige Operation, nicht bloße Schlamperei | ||
| + | * Gleichzeitig macht die Überlastung des Maintainers ein kleines Projekt anfällig; die menschliche Komponente ist ein zentraler Risikofaktor | ||
| + | * Konkrete Maßnahmen: stärkere 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 = | = Links = | ||
Version vom 6. Oktober 2025, 18:42 Uhr
Tja
Grundsätzliches
- 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 Schlüssels Zugang zu jedem SSH-Server mit root-Rechten
- Dieser Hack erforderte jahrelanges Social Engineering und der Payload wurde sehr ungewöhnlich versteckt
- Die Entdeckung der Backdoor verdanken wir Andres Freund
- Die Backdoor wird durch manipulierte Hooks in der lzma-Bibliothek zur Laufzeit aktiv und manipuliert SSH-Authentifizierungsmechanismen
Technische Details
- Die Backdoor nutzt das Hooking-Prinzip, um sich in die OpenSSH-Verarbeitung einzuklinken
- Beim Start eines betroffenen SSH-Servers wird eine Hintertür aktiviert, die auf einen speziellen privaten Schlüssel reagiert
- Die Modifikation wurde in der liblzma-Bibliothek vorgenommen, welche als Abhängigkeit von OpenSSH eingebunden ist
- Dadurch wird die SSH-Authentifizierung umgangen und ein direkter Root-Zugang ermöglicht
- Die Payload ist stark verschleiert und war schwer zu entdecken
- Der Code nutzte komplexe Kompressionsalgorithmen, um sich im System zu verbergen
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 auf
- Erste Beiträge sind kleine, unauffällige Patches und Tests
- 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 Code-Fragmente 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 (nicht in der Git-History sichtbar)
- Die Backdoor ist so konzipiert, dass sie nur unter sehr spezifischen Laufzeit-/Buildbedingungen 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 eine zusätzliche Login-Latenz (~500 ms) bei SSH-Verbindungen
- Durch Analyse der betroffenen Release-Tarballs findet er die obfuskierten Artefakte; am 29. März 2024 meldet er die Entdeckung öffentlich auf oss-security
- Kurz darauf erscheinen technische Analysen (Reverse Engineering) und Community-Tools zur Erkennung (YARA, osquery, Scanner wie xzbot)
Reaktion & Schadensbegrenzung
- Distributionen ziehen betroffene Pakete/Builds zurück oder blockieren die betroffenen Tarballs in ihren Pipelines
- CVE-Eintrag (CVE-2024-3094) und Vendor-Advisories werden veröffentlicht
- Scanner, YARA-Regeln und Prüfskripte werden publiziert, um Exposure zu identifizieren
Bewertung & Lehren
- Das Vorgehen kombiniert gezielte Social-Engineering-Techniken (mehrere Personas, gezielter Druck) mit technischer Verschleierung — dies spricht stark für eine geplante, bösartige Operation, nicht bloße Schlamperei
- Gleichzeitig macht die Überlastung des Maintainers ein kleines Projekt anfällig; die menschliche Komponente ist ein zentraler Risikofaktor
- Konkrete Maßnahmen: stärkere 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)