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

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

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

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

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

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

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

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)

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)

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

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

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)