Die xz-Hintertür: Das verborgene Oster-Drama​ der IT

Inhaltsverzeichnis

Weitgehend unbemerkt von der breiten Öffentlichkeit puzzelten Security-Spezialisten über die Osterfeiertage die Einzelteile einer Geschichte zusammen, die das Zeug zu ganz großem Drama hat: Geheimdienst-Agenten schleusen versteckte Hintertüren ein, ein sympathischer Nerd vereitelt gerade noch rechtzeitig das ruchlose Streben nach World Domination und den tragischen Part steuert ein ausgebrannter Open-Source-Entwickler mit psychischen Problemen bei, den die heimtückischen Angreifer mitleidlos ausnutzen. Alles geht so gerade noch einmal gut – aber jetzt sind alle ratlos, wie es weitergehen soll. Doch der Reihe nach:

Das Setting

Fragt mal den ITler eures Vertrauens nach seinen wichtigsten Admin-Werkzeugen, auf die er sich unbedingt verlässt. Die Chancen sind gut, dass SSH weit oben auf dieser Liste auftaucht. Diesen Dienst nutzen Admins für einen sicheren, verschlüsselten Low-Level-Zugang zu Servern aller Art. Wenn irgendein wichtiger Dienst ernsthaft hakt, wird sich früher oder später ein Administrator via SSH auf der Kommandozeile auf dem zuständigen Server anmelden.

Über SSH kann man also Server übers Netz erreichen und administrieren; eine Sicherheitslücke in diesem Dienst wäre fatal. Die Suchmaschine Shodan listet weltweit knapp 20 Millionen SSH-Zugänge, in Deutschland sind es immer noch über 2 Millionen. Eine Hintertür via SSH, die es erlaubt, dort beliebige Befehle auszuführen, ist damit der feuchte Traum jedes Geheimdienstes.

Doch die Beliebtheit von SSH rührt unter anderem daher, dass es berühmt für seine Sicherheit ist. Es wurde von Berufs-Paranoikern auf der Basis modernster Sicherheitskonzepte geschrieben und über Jahrzehnte kontinuierlich auf optimale Sicherheit hin weiterentwickelt. Da beißt die Maus so einfach keinen Faden ab.

Schwachpunkt Supply-Chain

Doch der SSH-Dienst läuft nicht im luftleeren Raum, sondern ist auf die Ressourcen des zugrundeliegenden Systems angewiesen. Unter anderem lädt er auf einem typischen Linux-System über 20 dynamische Bibliotheken, darunter liblzma.so, die Funktionen zur (De-)Kompression im xz-Format bereitstellt. Diese XZ-Tools sind ein kleines Open-Source-Projekt, das über viele Jahre von einem einzelnen Freiwilligen als Hobby betreut wird.

Der litt unter akutem Burn-out und psychischen Problemen, weswegen er dieser Aufgabe nicht mehr wirklich gerecht werden konnte. Deshalb nahm er die Hilfe eines zunächst Unbekannten namens "Jia Tan" dankbar an. Dies förderten mehrere mutmaßliche Komplizen, die mit Beschwerden und Forderungen den Druck auf den Maintainer stetig erhöhten. Jia Tan erarbeitete sich schließlich im Lauf von zwei Jahren das Vertrauen des xz-Maintainers und wurde recht schnell zum offiziellen Co-Maintainer, der selbstständig neuen Code in das Projekt einbringen konnte.

Die Hintertür

Das nutzte er, um Anfang 2024 in die Version 5.6.0 eine überaus raffinierte Hintertür einzubauen. Dabei platzierte er diese Backdoor nicht etwa im öffentlich einsehbaren Quellcode des XZ-Projekts. Stattdessen sorgte er dafür, dass der Build-Prozess Code aus einigen angeblichen Test-Dateien extrahierte und in das finale Binary der Bibliothek einbaute. Der Backdoor-Code findet sich dabei nur in den Release-Tarballs des Projekts.

Allein dieser Vorgang weist schon reichlich viele Finessen auf, die allein genug Stoff für einen Artikel gäben. Hier soll genügen, dass die fertigen Versionen 5.6.x von liblzma damit eine sehr spezielle Hintertür enthielten, die nur dann aktiv wurde, wenn sie der SSH-Prozess aus /usr/sbin/sshd benutzte. Da diese Hintertür nur in Binärform vorliegt und diverse Anti-Debugging-Maßnahmen enthält, gibt es noch keine finale Analyse.

Nach bisherigem Kenntnisstand leitet sie eine Funktion aus dem Anmeldevorgang auf sich um. Konkret landet jeder Versuch, sich mit einem RSA-Public-Key anzumelden via RSA_public_decrypt() im Hintertür-Code. Der analysiert den dazu verwendeten öffentlichen Schlüssel und extrahiert daraus Kommandozeilenbefehle, die er auf dem Server ausführt.

Damit das nicht jeder nutzen kann, muss die übertragene Befehlssequenz zusätzlich eine bestimmte digitale Signatur tragen. Und eine solche Signatur können nur die Angreifer hinter Jia Tan mit ihrem geheimen Schlüssel erstellen. Das ist damit eine typische "Nobody but us" – kurz NOBUS-Hintertür, wie sie insbesondere Geheimdienste bevorzugen.

Die Verbreitung

Diese Hintertür befindet sich in den aktuellen XZ-Tools xz-5.6.0 und xz-5.6.1 sowie den zugehörigen liblzma-Bibliotheken. Die waren zwar bereits in einige unstable- und testing-Zweige der Distributionen vorgedrungen, aber weder Debian, noch Ubuntu oder Red Hat haben sie in ihren Stable-Zweig aufgenommen.

Genau darauf drängte jedoch, wie aktuelle Analysen zeigen, eine Reihe von Personen sehr aktiv; vermutlich handelt es sich dabei wie bei Jia Tan ebenfalls um künstliche Personas der Angreifer. Hätten sie Erfolg gehabt, wäre das der Super-GAU mit vielen Millionen Systemen, auf denen die Angreifer nach Belieben schalten und walten könnten.

Auftritt: Der große Held

Dass es nicht so weit kam, verdanken wir der Neugier des Software-Entwicklers Andres Freund, der Dingen gern auf den Grund geht. Wie er selbst erklärte, störte seltsame CPU-Last seine Messungen auf einem Testsystem. Weiteres Nachforschen ergab, dass auf den Systemen mit der Hintertür ein fehlgeschlagener Log-in-Versuch via SSH etwa 500 Millisekunden länger brauchte, als auf Systemen mit älteren Versionen von liblzma.

Mit diesen Indizien spürte er dann auch das obfuszierte Skript im Tar-File des Quellcodes auf und alarmierte am Freitag, dem 29. März, die Open-Source-Community. Medien wie heise Security berichteten bereits kurz danach über die rätselhafte XZ-Backdoor, Red Hat gab der Schwachstelle die ID CVE-2024-3094 und auch Institutionen wie das BSI warnten.

Ein Nerd, der etwas seltsame CPU-Last und eine halbe Sekunde unerklärliche Verzögerung nicht auf die leichte Schulter nahm, machte also den Unterschied. Wie sich danach herausstellte, kam der Alarm gerade noch rechtzeitig; die Zahl der betroffenen Systeme war überschaubar, erkennbarer Schaden fand sich bislang keiner. Doch das Potenzial dieser NOBUS-Backdoor ist gewaltig; es sucht in der Geschichte des Internets seinesgleichen.

Viele Fragen, wenig Antworten

Letztlich ist das Internet und ein beträchtlicher Teil der weltweiten IT so knapp an einer Katastrophe vorbeigeschrammt, dass alle sich fragen: Was wäre passiert, wenn Freund das Phänomen wie fast jede(r) sonst einfach mit einem Achselzucken abgetan hätte? Wie viele weitere solche Hintertüren gibt es noch, die niemand zufällig bemerkte? Und vor allem: Wie lässt sich das zukünftig vermeiden?

Die Suche nach diesen Antworten ist aktuell in vollem Gange. Natürlich gab es fast sofort Stimmen, die den Vorgang als endgültigen Beweis der Untauglichkeit des Open-Source-Entwicklungs-Modells proklamierten, bei dem Hinz&Kunz Hintertüren in wichtige Projekte einschleusen könne. Und auf der anderen Seiten natürlich solche, die die Tatsache feierten, dass Freunds Entdeckung ja gerade der Beweis sei, dass die Kontrolle durch viele Augen funktioniere.

Ich halte es für zu früh, finale Erkenntnisse zu postulieren, bevor das gesamte Ausmaß dieser Aktionen geklärt ist. Was man jedoch jetzt schon tun kann ist, ein paar pragmatische Schlüsse ziehen und daraus erste Erkenntnisse ableiten. So sollte man jetzt unverzüglich alle Projekte mit großer Verbreitung, die direkt aus dem Internet erreichbar sind, systematisch auf vergleichbare Hintertüren untersuchen. Und dazu gehört nicht nur der eigene Code, sondern auch das, was sie alles nachladen. Und das gilt natürlich keineswegs nur für Open-Source-Projekte wie Apache oder nginx. Auch kommerzielle Software lädt reihenweise externe Bibliotheken nach.

Und da kommt dann zwangsläufig auch die soziale Komponente aufs Tapet, nämlich dass unglaublich viele wichtige Projekte auf den Schultern einzelner lasten, die damit letztlich hoffnungslos überfordert sind. Das hat bereits der oben aufgeführte xkcd-Comic perfekt illustriert. Es wurde im Rahmen des Heartbleed-Debakels bei Openssl als Problem ausgemacht und im Zug der Nachbereitung der Log4j-Lücke ausführlich diskutiert. Ich bin sehr gespannt, ob diesmal mehr bei diesen Diskussionen herauskommt, als noch mehr Magic Security Dust.

(ju)