Drei Jahre Geduld, 500 Millisekunden Verzögerung: Die XZ-Backdoor und was sie über digitale Sicherheit verrät

 Gepostet am March 5, 2026  |  12 Minuten  |  2473 Wörter  |  Stefan Fahl
Code

Drei Jahre Geduld, 500 Millisekunden Verzögerung: Die XZ-Backdoor und was sie über digitale Sicherheit verrät

 Gepostet am March 5, 2026  |  12 Minuten  |  2473 Wörter  |  Stefan Fahl

“Most of us would have blamed the network, rebooted something, and moved on with our day. He didn’t.”

Am 29. März 2024 veröffentlichte Andres Freund, ein Microsoft-Entwickler und PostgreSQL-Contributor, eine E-Mail auf der Openwall-Mailingliste, die die Open-Source-Community in Aufruhr versetzte. Der Betreff: “backdoor in upstream xz/liblzma leading to ssh server compromise”. Was als routinemäßige Performancemessung begann, endete mit der Entdeckung einer der raffiniertesten Backdoors, die jemals in Open-Source-Software eingeschleust wurden.

Die Schwachstelle CVE-2024-3094 erhielt den maximalen CVSS-Score von 10.0 – kritisch im wahrsten Sinne des Wortes. Denn wäre sie nicht entdeckt worden, hätte ein unbekannter Angreifer potenziell Zugriff auf Millionen von Servern weltweit gehabt. Ein Video auf YouTube erklärt die technischen Details anschaulich – doch die eigentliche Geschichte ist weitaus erschreckender.

500 Millisekunden, die die Welt retteten

Andres Freund bemerkte etwas Seltsames. Als er PostgreSQL auf einem Debian-Testsy stem benchmarkte, dauerten SSH-Logins eine halbe Sekunde länger als gewöhnlich. 500 Millisekunden. Die meisten hätten das Netzwerk beschuldigt, etwas neu gebootet und wären weitergegangen. Freund nicht.

Er bemerkte zudem, dass der sshd-Prozess ungewöhnlich viel CPU-Last erzeugte – selbst bei fehlgeschlagenen Login-Versuchen. Das war unlogisch. Warum sollte ein gescheiterter Login so viele Ressourcen verbrauchen? Er begann zu debuggen, nutzte Valgrind zum Memory-Debugging – und stieß auf Fehlermeldungen, die ihn stutzig machten.

Die Spur führte ihn zur liblzma-Bibliothek, Teil der XZ Utils, einer weit verbreiteten Kompressionssoftware. Was er dort fand, war atemberaubend: Eine Backdoor, so sorgfältig konstruiert, dass sie jahrelang unentdeckt geblieben war. Eine Backdoor, die es einem Angreifer mit dem richtigen privaten Schlüssel ermöglicht hätte, vor der SSH-Authentifizierung Code auf dem System auszuführen.

NPR interviewte Freund kurz nach der Entdeckung. Seine Reaktion war bemerkenswert nüchtern: “Annoyance, I guess… Because I was actually trying to do something else, and the symptoms seemed weird enough that I couldn’t really justify to myself to not switch to looking into what was going on.” Genervt. Weil er eigentlich etwas anderes vor hatte.

Diese Beiläufigkeit ist entscheidend. Freund war kein Sicherheitsforscher, der aktiv nach Backdoors suchte. Er war ein Entwickler, der Performance-Tests durchführte. Und genau das macht die Geschichte so erschreckend: Die Backdoor wäre niemals durch automatisierte Sicherheitsscans entdeckt worden. Kein Intrusion Detection System hat Alarm geschlagen. Kein Signature Scanner hat die Backdoor erkannt. Es war ein Mensch, der bemerkte, dass “etwas nicht stimmte”.

Drei Jahre Social Engineering: Der lange Marsch zum Vertrauen

Die XZ-Backdoor war keine spontane Aktion. Sie war das Ergebnis einer dreijährigen Kampagne, die im Januar 2021 begann. Ein GitHub-Account mit dem Namen “Jia Tan” (JiaT75) tauchte auf. Zunächst arbeitete dieser Account an libarchive, einer Bibliothek, die unter anderem in Microsoft Windows zum Einsatz kommt.

Ab April 2022 wandte sich “Jia Tan” dem XZ-Projekt zu. Die ersten Commits waren unauffällig: Bug-Fixes, kleine Verbesserungen, hilfreiche Beiträge. Lasse Collin, der finnische Entwickler, der XZ Utils fast zwei Jahrzehnte lang allein gewartet hatte, war vermutlich dankbar für die Hilfe.

Doch dann geschah etwas Bemerkenswertes: Weitere Accounts tauchten auf und drängten Collin, “Jia Tan” mehr Verantwortung zu geben. “Jigar Kumar”, “krygorin4545”, “misoeater91” – allesamt vermutlich Sockpuppets, kontrolliert von derselben Person oder Gruppe. Sie schrieben Nachrichten wie:

“Progress will not happen as long as there is so much time spent debating basic changes.”

“Lasse, why do you ignore patches for so long?”

Diese Druckausübung hatte Erfolg. Über die Zeit baute “Jia Tan” Vertrauen auf. 2023 erhielt er Co-Maintainer-Status. Er konnte nun Releases signieren. Und genau das tat er: Im Februar 2024 veröffentlichte er XZ Utils 5.6.0 – mit einer versteckten Backdoor. Kurz darauf folgte Version 5.6.1 mit weiterem Schadcode.

Die technische Raffinesse: Versteckt in Test-Dateien

Die Backdoor selbst ist ein Meisterwerk der Obfuskation. Sie besteht aus mehreren Schichten:

Schicht 1: Getarnte Test-Dateien

Der Schadcode war in zwei komprimierten Test-Dateien versteckt: tests/files/bad-3-corrupt_lzma2.xz und tests/files/good-large_compressed.lzma. Diese Dateien sahen aus wie gewöhnliche Test-Cases. In Wirklichkeit enthielten sie binären Schadcode, der während des Build-Prozesses extrahiert wurde.

Schicht 2: Manipulation des Build-Prozesses

Die Datei build-to-host.m4 enthielt ein obfuskiertes Script, das während des ./configure-Prozesses ausgeführt wurde. Dieses Script prüfte:

  • Läuft das Build-System auf x86-64 Linux?
  • Handelt es sich um ein Debian- oder RPM-Paket-Build?

Nur wenn beide Bedingungen erfüllt waren, wurde die Backdoor aktiviert.

Schicht 3: Injection in liblzma

Der extrahierte Schadcode wurde in die liblzma-Bibliothek injiziert. Er nutzte den IFUNC-Mechanismus von glibc, um die OpenSSH-Funktion RSA_public_decrypt durch eine manipulierte Version zu ersetzen.

Schicht 4: Der Hook in OpenSSH

OpenSSH nutzt normalerweise kein liblzma. Aber auf Systemen mit systemd gibt es einen Patch, der OpenSSH mit libsystemd verbindet – und libsystemd nutzt liblzma. Über diese Abhängigkeitskette gelangte die Backdoor in den SSH-Daemon.

Schicht 5: Die eigentliche Backdoor

Die manipulierte RSA_public_decrypt-Funktion enthielt Logik, die auf bestimmte SSH-Zertifikate wartete. Wenn ein Angreifer mit dem passenden privaten Ed448-Schlüssel eine Verbindung aufbaute, extrahierte die Backdoor einen Command aus dem Zertifikat und führte ihn via system() aus – vor der Authentifizierung. Remote Code Execution ohne Login.

Die Verschleierung: Fuzzing sabotiert

Besonders heimtückisch: “Jia Tan” hatte 2023 einen Pull Request eingereicht, der “Indirect Function Support” im Fuzzer deaktivierte. Fuzzing ist eine automatisierte Test-Methode, die versucht, Fehler durch zufällige Eingaben zu finden. Die Deaktivierung dieser Funktion verhinderte, dass die Backdoor durch Fuzzing entdeckt werden konnte.

Das zeigt: Die Angreifer kannten nicht nur die XZ-Codebasis im Detail, sondern auch die Sicherheitstools und -prozesse, die sie umgehen mussten.

Die globale Bedeutung: Ein Haar an der Katastrophe

Die Tragweite lässt sich kaum überschätzen. XZ Utils ist in praktisch jeder Linux-Distribution enthalten. Die betroffenen Versionen 5.6.0 und 5.6.1 waren zwar nur kurz verfügbar (Februar 2024), aber sie hatten bereits Einzug in mehrere Distributionen gefunden:

  • Fedora Linux 40 Beta und Fedora Rawhide
  • Debian unstable, testing und experimental
  • Kali Linux
  • Arch Linux (bestimmte Images zwischen 24. Februar und 28. März 2024)

Stable Versionen wie Ubuntu, Red Hat Enterprise Linux oder Amazon Linux waren nicht betroffen – ein Glücksfall. Denn wäre die Backdoor in stable releases gelangt, hätte sie Millionen von Servern kompromittiert.

Alex Stamos, ehemaliger Chief Security Officer von Facebook, nannte es die “weitestgehende und effektivste Backdoor”, die jemals in Software installiert wurde. Wäre sie nicht entdeckt worden, hätte sie den Angreifern einen “Masterschlüssel zu allen Computern auf der Welt” verschafft, die SSH nutzen.

Bruce Schneier, einer der renommiertesten IT-Sicherheitsexperten, beschrieb die Backdoor als “a masterful piece of work” und fügte hinzu: “It affects the SSH remote login protocol, basically giving an attacker access to everything.”

Die US-Behörde CISA gab umgehend eine Warnung heraus: Alle Nutzer sollten sofort auf eine unkompromittierte Version (5.4.6 oder früher) downgraden und ihre Systeme auf verdächtige Aktivitäten überprüfen.

Die Täter: Nur Staaten haben diese Ressourcen

Wer steckt dahinter? Die exakte Attribution steht noch aus. Aber alle Indizien deuten auf staatliche Akteure:

Zeitaufwand: Drei Jahre Social Engineering, Vertrauensaufbau, schrittweise Übernahme – das erfordert Geduld, die nur staatlich gesteuerte Operationen haben.

Technische Komplexität: Die Backdoor nutzt multiple Obfuskationsschichten, tiefes Wissen über Build-Systeme, glibc-Internals, OpenSSH-Architektur. Das ist keine One-Man-Show.

Koordination: Mehrere Sockpuppet-Accounts, über Jahre hinweg synchronisiert – das erfordert Organisation.

Kosten: Drei Jahre Vollzeit-Arbeit eines oder mehrerer hochqualifizierter Entwickler. Bei konservativer Rechnung: 500.000 bis 1.000.000 US-Dollar nur an Personalkosten. Dazu kommen Infrastruktur, Planung, Risikoanalyse.

Freund selbst sagte gegenüber NPR: “It does not look like a single computer hacker. There – both in the way they injected the backdoor, that was multiple years of work to get to the point of being able to do it. And then the complexity of the backdoor itself was also significant, so that can’t have been just, like, one lone individual doing it for a few weeks.”

Datadog Security Labs fasst zusammen: “The attack has attracted extensive industry and media coverage and is widely regarded as an advanced, multi-year, and likely state-sponsored operation.”

Welcher Staat? Spekulationen reichen von China über Russland bis Nordkorea. Beweise gibt es keine. “Jia Tan” ist vermutlich ein Pseudonym. Die E-Mail-Adressen führen ins Leere. Die Commits wurden über Tor oder VPNs gemacht. Die Angreifer haben ihre Spuren professionell verwischt.

Was wir daraus lernen müssen

Die XZ-Backdoor ist mehr als ein technischer Incident. Sie ist eine Warnung an die gesamte digitale Infrastruktur.

1. Open Source ist verwundbar – aber nicht weil es Open Source ist

Ein häufiges Missverständnis: “Open Source ist unsicher, weil jeder Code einschleusen kann.” Falsch. Die Backdoor wurde entdeckt, weil der Code offen ist. Weil Freund nachsehen konnte, was passiert. Weil die Community binnen Stunden die Codebasis analysieren konnte.

Proprietäre Software hätte dieselbe Backdoor enthalten können – nur wäre sie niemals entdeckt worden. Microsoft selbst hatte 2023 einen gestohlenen Azure-Master-Key, der wochenlang unbemerkt blieb. Das Cyber Safety Review Board kritisierte Microsofts “inadäquate Sicherheitskultur”. Proprietär schützt nicht. Offenheit ermöglicht Kontrolle.

2. Maintainer-Burnout ist ein Sicherheitsrisiko

Lasse Collin wartete XZ Utils fast 20 Jahre – unbezahlt. Als Freund gegenüber NPR darauf angesprochen wurde, sagte er: “In this case, the software that was where the backdoor was actually introduced, that was maintained by a single person for close to 20 years. And that single person was, as far as I know, not being paid for it, despite the software being used extremely widely.”

Das ist das Problem. Kritische Infrastruktur hängt von unbezahlten Freiwilligen ab. Wenn diese Freiwilligen überarbeitet sind, nehmen sie dankbar Hilfe an – auch von “Jia Tan”. Das ist menschlich. Aber es ist auch gefährlich.

Nach dem Heartbleed-Bug in OpenSSL 2014 begannen Unternehmen, OpenSSL-Maintainer zu bezahlen. Dasselbe muss für alle kritischen Open-Source-Projekte geschehen. Wer Software nutzt, die Milliarden wert ist, muss deren Entwickler bezahlen.

3. Trust ist kein Sicherheitsmodell

Die Angreifer nutzten das menschlichste aller Elemente: Vertrauen. “Jia Tan” war hilfsbereit, freundlich, zuverlässig. Über Jahre. Das schafft Vertrauen. Und Vertrauen öffnet Türen.

Die Lösung kann nicht sein, niemandem zu trauen. Die Lösung muss sein: Vertrauen durch Verifikation ersetzen. Mehr Code Reviews. Mehr automatisierte Tests. Mehr Vier-Augen-Prinzip bei kritischen Änderungen. Mehr Transparenz bei Build-Prozessen.

Projekte wie das Open Source Security Foundation (OpenSSF) arbeiten an Best Practices. Der “Bus Factor” – wie viele Maintainer müssen ausfallen, bis ein Projekt zusammenbricht – muss steigen. Kritische Projekte brauchen mindestens 3-5 aktive Maintainer.

4. Supply Chain Attacks sind die neue Normalität

Die XZ-Backdoor ist kein Einzelfall. SolarWinds 2020, CodeCov 2021, PyPI-Angriffe – die Liste wird länger. Angreifer haben erkannt: Warum einen Server hacken, wenn man die Software hacken kann, die auf dem Server läuft?

Die Verteidigung dagegen ist schwierig. Sie erfordert:

  • Software Bill of Materials (SBOM): Welche Komponenten nutzt mein System?
  • Dependency Pinning: Exakte Versionen festschreiben, nicht „latest"
  • Reproducible Builds: Kann ich verifizieren, dass die Binary wirklich aus dem Quellcode stammt?
  • Continous Monitoring: Laufen meine Systeme noch wie erwartet?

5. Menschen, nicht Tools, finden die wichtigsten Bugs

Freunds Entdeckung war kein Zufall. Aber sie war auch kein Ergebnis automatisierter Scans. Wie Datadog Security Labs schreibt: “Advanced security incidents are often detected not by automated tools, but by individuals who notice when ‘something feels off.’”

Wir brauchen Tools. Aber wir brauchen auch Menschen, die verstehen, was die Tools messen. Menschen, die 500 Millisekunden Verzögerung nicht ignorieren. Menschen, die neugierig sind.

Das ist ein Plädoyer für technische Tiefe, für Expertise, für das Verständnis dessen, was unter der Haube passiert. Abstraktion ist nützlich. Aber wer nur Abstraktionen kennt, wird Anomalien nicht erkennen.

Die Reaktion: Schnell, koordiniert, professionell

Nachdem Freund seine Entdeckung öffentlich gemacht hatte, reagierte die Open-Source-Community mit beeindruckender Geschwindigkeit:

  • Innerhalb von Stunden: Distributionen wie Fedora, Debian und Arch Linux zogen die kompromittierten Versionen zurück
  • Innerhalb von Tagen: CISA veröffentlichte offizielle Guidance
  • Innerhalb von Wochen: Detaillierte technische Analysen von Wiz, JFrog, Akamai und anderen

GitHub suspendierte das XZ-Repository temporär. “Jia Tan” verschwand von allen Accounts. Lasse Collin veröffentlichte ein Statement, in dem er die Ereignisse aus seiner Perspektive schilderte.

Die Koordination war bemerkenswert. Sie zeigte, dass die Open-Source-Community im Ernstfall funktioniert. Aber sie zeigte auch, wie knapp wir an einer Katastrophe vorbeigeschrammt sind.

Was hätte passieren können

Angenommen, Freund hätte die 500 Millisekunden ignoriert. Angenommen, XZ 5.6.1 wäre in stable releases gelangt. Was dann?

Szenario 1: Massenüberwachung

Ein Staat mit dem privaten Schlüssel hätte Zugriff auf Millionen von SSH-Servern gehabt. Regierungen, Unternehmen, Universitäten – alles kompromittiert. Stille Überwachung ohne Spuren.

Szenario 2: Sabotage

Kritische Infrastruktur – Kraftwerke, Wasserwerke, Verkehrssysteme – läuft auf Linux. Ein Angreifer hätte diese Systeme abschalten können. Auf Knopfdruck.

Szenario 3: Ransomware auf Steroiden

Warum einzelne Unternehmen angreifen, wenn man die gesamte Infrastruktur verschlüsseln kann? Ein koordinierter Angriff auf Tausende Server gleichzeitig.

Szenario 4: Zerstörung von Vertrauen

Wenn bekannt geworden wäre, dass eine staatlich gesponserte Backdoor jahrelang in Linux-Systemen aktiv war, hätte das das Vertrauen in Open Source zerstört. Die Folgen wären verheerend gewesen.

All das ist nicht passiert. Weil ein Entwickler neugierig war. Weil 500 Millisekunden ihm komisch vorkamen.

Fazit: Die Fragilität digitaler Zivilisation

Die XZ-Backdoor zeigt die erschreckende Fragilität unserer digitalen Infrastruktur. Kritische Software wird von einzelnen Freiwilligen gewartet. Vertrauen ersetzt Verifikation. Automatisierung ersetzt Verständnis.

Gleichzeitig zeigt sie die Stärke von Open Source. Die Backdoor wurde entdeckt, weil der Code offen ist. Sie wurde binnen Stunden neutralisiert, weil die Community koordiniert handeln kann. Sie wird analysiert und dokumentiert, weil Transparenz Standard ist.

Die Lehren sind klar:

  1. Bezahlt eure Maintainer. Kritische Infrastruktur darf nicht von unbezahlten Freiwilligen abhängen.
  2. Vertraut, aber verifiziert. Code Reviews, Vier-Augen-Prinzip, automatisierte Tests.
  3. Diversifiziert Abhängigkeiten. Single Points of Failure sind Single Points of Attack.
  4. Investiert in Menschen. Tools sind wichtig. Aber Menschen mit technischer Tiefe sind entscheidend.
  5. Bleibt wachsam. 500 Millisekunden können die Welt retten.

Die XZ-Backdoor ist Geschichte. Die nächste Supply Chain Attack ist bereits in Vorbereitung. Irgendwo baut jemand gerade Vertrauen auf. Irgendwo schleicht sich jemand in ein Projekt ein. Irgendwo wartet eine Backdoor darauf, aktiviert zu werden.

Die Frage ist nicht, ob es wieder passiert. Die Frage ist, ob wir sie wieder rechtzeitig entdecken.

Andres Freund hat uns eine Lektion erteilt: Manchmal rettet Neugier die Welt. Ignoriert niemals 500 Millisekunden.

Quellen und weiterführende Links:

Primärquellen und Entdeckung:

Technische Analysen:

Offizielle Stellen:

Detection und Mitigation:

Video:

Weiterführende Themen:

XZ Utils  CVE-2024-3094  Supply Chain Attack  OpenSSH  Open Source  Staatliche Hacker 

Siehe auch