xz oder: Wie die Open-Source-Community an Ostern die Welt gerettet hat

«Die Feiertage. Die ganzen IT-Abteilungen feiern mit der Familie… Die ganzen IT-Abteilungen? Nein! Eine von unbeugsamen Open-Source-Enthusiasten bevölkerte Mailingliste hört nicht auf, den Eindringlingen Widerstand zu leisten.»

Wir sind dieses Wochenende nur durch unglaublichen Zufall extrem knapp an einer schon lange vorbereiteten, wohl grössten Katastrophe rund um die globale IT-Sicherheit vorbeigeschrammt. Phuh! Doch — was ist eigentlich passiert? Wie konnte das überhaupt geschehen? Und was können (und müssen) wir tun, um dies zukünftig zu vermeiden?

TL;DR (oder: Das Wichtigste in Kürze)

5 von 6 der übers Internet erreichbaren Server laufen unter einem Unix, davon die meisten unter Linux. Diese Server wollen auch irgendwie administriert werden, viele davon auch übers Internet. Die Standardmethode für die Fernwartung von Unix-Rechnern ist ssh, „Secure SHell“, eine sichere Methode, um Statusinformationen abzurufen, Konfigurationen zu ändern, Daten zu transferieren oder Befehle auszuführen. ssh hat sich diese Führungsrolle über die letzten bald 30 Jahre erarbeitet und gilt als sehr vertrauenswürdig; u.a. durch seine Transparenz und Verfügbarkeit als Open Source.

Genau diese hohe Verbreitung und das hohe Vertrauen sollte jetzt genutzt werden, um eine Sicherheitslücke in Millionen von Servern einzuschleusen, mit der die unbekannten Hintermänner die vollständige Kontrolle über diese und noch mehr Server hätten übernehmen können. Darauf hatten sich die Unbekannten über mindestens 3 Jahre gezielt vorbereitet und hatten sich schon für weitere Pläne vorbereitet.

Das Resultat hätte für unsere persönlichen Daten, unsere Wirtschaft und deren Abläufe, sowie für die davon abhängigen Prozesse inklusive kritische Infrastrukturen desaströs enden können. Zum Glück hat ein Entwickler eines anderen Open-Source-Projektes, Andres Freund, bei einem Test eine kleine Veränderung wahrgenommen und wollte ihre Ursache finden. Dafür musste er sich durch ein Dickicht von Verschleierungsversuchen der Unbekannten durchwühlen.

Er hat seine Erkenntnisse dann am Karfreitag mit Online-Mitstreitern geteilt und gemeinsam sind sie dann der Sache auf den Grund gegangen. Und haben damit über Ostern kurz die Welt gerettet.

All‘ diesen Mitstreitern gebührt ein Dank. Hier ist ihre Geschichte.

Häufung an Feiertagen?

Scheint es nur mir so oder tauchen grosse IT-Sicherheitsrisiken, welche (auch) Open-Source-Lösungen betreffen, in letzter Zeit vermehrt zu Feiertagen auf?

• Neujahr 2018, Spectre und Meltdown: Hardware-Sicherheitslücken in eigentlich allen schnellen Prozessoren, als Nebenwirkung von Optimierungen, um Programme schneller laufen zu lassen.
• Weihnachten 2021, Log4j/Log4Shell: Eine Sicherheitslücke, welche Tausende von Firmen z.T. über Wochen oder Monate beschäftigt hat, da die Softwareaktualisierung auf eine sichere Version oft sehr schwierig war.
• Weihnachten 2023, SMTP Smuggling: Die am weitesten verbreitete Mailsoftware kann bei der Spamerkennung ausgetrickst werden (wegen Bugs anderswo).
• Ostern 2024, xz/liblzma: Eine eigentlich langweilige Kompressionsbibliothek wurde zur globalen Hintertür für Remote-Serverzugang umgebaut und wäre wohl in den nächsten Wochen auf tausenden von Servern gelandet.

Die beiden ersten scheinen ohne böse Absicht entstanden zu sein und betrafen auch nicht nur Open-Source-Lösungen (mehr dazu hinter den Links). Hinter der xz-Lücke steckt aber Absicht und viel Vorbereitung und Geduld.

«Das dauert plötzlich ½ Sekunde länger. Das muss ich mir anschauen!»

Vergangene Woche schaut sich Andres Freund, Entwickler bei der Open-Source-Datenbank PostgreSQL, gerade an, ob die letzten Änderungen seine Datenbank langsamer oder schneller gemacht hätten. Dazu verwendet er eine Linux-Distribution, welche Pakete beinhaltet, welche erst später zu den „Normalusern“ fliessen sollen, damit er Probleme frühzeitig erkennen kann.

Dabei bemerkt er, dass die für das Remote-Login notwendigen ssh-Prozesse auffällig viel Zeit verwenden, rund ¾ statt ¼ Sekunden. Die meisten Entwickler hätten die Suche wohl auf später verschoben. Nicht so Andres. Er beginnt eine lange obskure Untersuchung, er gerät immer tiefer in die Sache hinein, oder passend zu Ostern, „going down the rabbit hole„, wie die Engländer sagen würden.

Und damit hat er wohl die IT-Welt vor einem von langer Hand geplanten Katastrophe bewahrt.

Die Vorbereitung der Katastrophe

Andres Freund teilt sein Wissen am 29. März auf einer Sicherheitsmailingliste und setzt damit eine Bewegung in Gang. Unzählige Leute versuchen herauszufinden, wie dieses Problem zustande gekommen sei. Es werden Source-Code-Repositorien und Archive von Mailinglisten durchsucht; zum Glück ist alles transparent und damit nachvollziehbar.

(Die Namen der mutmasslich vom Angreifer kontrollierten Konten sind in Anführungszeichen gesetzt, da dies kaum echte Namen sein dürften. Da das Quellcode-Repository von xz aus Sicherheitsgründen gesperrt wurde, muss ich mich bei der folgenden Darstellung des Ablaufs auf die Berichte von u.a. Andres Freund, Evan Boehs, Michał Zalewski und Samuel Rüegger verlassen. Sobald das Repository wieder verfügbar sind, helfen die Links in Evan Boehs‘ Artikel, die einzelnen Entwicklungen Schritt für Schritt nachzuvollziehen.)

2021—2022: Etablierung von Vertrauen und Rechten

• Im Jahr 2021 taucht ein Nutzer mit Namen „Jia Tan“ erstmals auf und schlägt eine Änderung beim Open-Source-Projekt libarchive vor, angeblich zur Verbesserung einer Fehlermeldung. Die damals akzeptierte Änderung könnte unsichere/unerwünschte Nebenwirkung haben; dies wird gerade überprüft und wenn nötig korrigiert. (Dieser Schritt ist möglicherweise nur ein Probelauf oder dient dem Aufbau der Online-Persönlichkeit.)
• Im Jahr 2022 schlägt „Jia Tan“ eine Änderung an xz vor. Nachdem der xz-Entwickler, Lasse Collin, nicht sofort reagiert, beginnt ein Good-Cop-Bad-Cop-Spiel zwischen „Jia Tan“ und einer neu auftauchenden Online-Persönlichkeit, „Jigar Kumar“, mutmasslich eine zusätzliche Identität („Sockenpuppe„) des Akteurs hinter „Jia Tan“. „Jigar Kumar“ verschwindet danach in der Versenkung.
• Wenige Tage danach beginnt „Jia Tan“ Änderungen an xz vorzunehmen, welche vom ursprünglichen Entwickler eingepflegt werden. Damit beginnt dieser langsam, sich Vertrauen und Rechte anzueignen.
• Im Januar 2023 darf „Jia Tan“ erstmals selbst Änderungen einpflegen.

Damit hat das Team hinter dieser Operation ein wichtiges Zwischenziel erreicht (aufgrund der Geduld und Persistenz dürfte sich kaum um die Aktion eines Einzelnen handeln). Wahrscheinlich wird jetzt eine Flasche Champagner, Vodka oder Reiswein geöffnet; oder was auch immer in jener Weltgegend zum Feiern eines Erfolges dazugehört.

2023: Deaktivieren von Sicherheitswarnungen

• Im März desselben Jahres setzt „Jia Tan“ neu sich—statt wie bisher Lasse Collin—als Kontaktperson für Warnungen des Sicherheitstools oss-fuzz ein. „Jia Tan“ ebnet damit den Pfad für die ersten unsicheren Codeänderungen.
• In den Folgemonaten schlägt ein „Hans Jansen“ eine Änderung vor, mit der je nach System eine schnellere Berechnung der Prüfsumme möglich ist. Die Art, wie zwischen den verschiedenen Prüfsummenvarianten unterschieden wird, legt auch den Grundstein für eine spätere Ersetzung anderer Funktionen zur Laufzeit. Auch „Hans Jansen“ verschwindet vorerst wieder von der Bildfläche.
• „Jia Tan“ akzeptiert diese Änderung und das automatische Sicherheitsanalysetool oss-fuzz schlägt Alarm: Einer seiner vielen Tests hält die Änderung für potenziell gefährlich.
• „Jia Tan“ bittet das oss-fuzz-Team, den spezifischen Test zu deaktivieren, da das ein falscher Alarm sei; die Änderung sei gewollt. Dies machen auch andere Projekte aus lauteren Gründen. Hier ist der Grund aber definitiv unlauter; dies wird aber erst aus heutiger Perspektive in dieser Deutlichkeit klar.

Nach diesen Entwicklungen schauen weniger Augen (automatisiert oder menschlich) auf seltsame Änderungen am Code. Die Bühne ist somit frei für den eigentlichen Star: Die Backdoor!

2024: Einbau und Aktivierung der Sicherheitslücke

• Anfang März 2024 wurde dann der echte Schadcode eingefügt., liebe Osterhasen
  • Wie heute allgemein üblich, enthält auch xz automatische Testfunktionen, um Fehler nach Änderungen an der Software oder der eingesetzten Umgebung (Compiler, Betriebssysteme, …) frühzeitig zu erkennen.
  • Es werden neue angebliche „Testdateien“ ins Projekt aufgenommen. Im Normalfall werden diese als Teil von automatisierten Tests verwendet, also beispielsweise, um zu testen, ob die Kompression/Dekompression noch korrekt funktioniert. Hier dienen sie aber einem ganz anderen Zweck:
  • Der Schadcode (konkret ist es eine Backdoor) wird nicht im Quellcode selbst platziert, sondern in diesen vorgeblichen „Testdateien“. Statt die übersetzte Funktion aus dem (sauberen) Quellcode zu nutzen, wird die über die „Testdateien“ eingeschmuggelten, kompromittierten Funktionen genutzt. Ein ganz fieser Trick.
  • Dieser Steuercode verfügt zusätzlich über ein „Plugin-System“, mit dem später einfach zusätzliche vorgebliche „Testdateien“ hinzugefügt werden könnten. Wenn diese im richtigen Format vorliegen, würden sie automatisch „entschlüsselt“ und beim Übersetzen mit aktiviert.
  • Das Plugin-System wurde bisher noch nicht genutzt; es war also von „Jia Tan“ für weitsichtige zukünftige Erweiterungen vorgesehen.
• Beim Hinzufügen des Schadcodes wird von einem anderen Testtool, valgrind, ein Fehler gemeldet. Dieser Fehler wird ebenfalls versteckt.
• Vor einer Woche (25. März) taucht „Hans Jansen“ wieder aus der Versenkung auf und bittet das Team der Linux-Distribution Debian, die neueste Version von xz doch bitte einzubauen. Einige andere, eigens für diesen Zweck erzeugten Konten, unterstützen ihn, da es den valgrind-Fehler behebe. Der für dieses Paket Zuständige bei Debian aktualisiert auf die neueste xz-Version, vorerst für die Testversion, von wo es dann wenige Tage später bei Andres Freund auftaucht und für Verwirrung und Nachforschungen sorgt.
• Die Linux-Distributionen Kali und Arch haben die bösartige Version ebenfalls übernommen.
• Anfragen bei anderen Linux-Distributionen und Bibliotheken wurden abgelehnt oder vertröstet.
• Am 28. März, drei Tage nach der Bitte um „Update“ auf die infizierte Bibliothek, veröffentlicht Andres Freund seine erste Analyse. In den folgenden Stunden und Tagen beteiligen sich Unzählige weitere Personen nach der Suche.
• Inzwischen gibt es von allen betroffenen Systemen aktualisierte Versionen, welche die Fehler beheben (typischerweise, in dem sie auf eine ältere, noch nicht verseuchte, Version zurückgehen).

Innert weniger Tage wurde dank aufmerksamen Open-Source-Leuten mehrere Jahre akribische Vorbereitung einer gross angelegten Cyberattacke zunichte gemacht. Danke an alle Beteiligten!

Was wäre die Funktion gewesen?

Die aktuelle Backdoor zielte auf den ssh-Server (sshd). Ssh-Logins sind auf Abermillionen Rechnern im Internet verfügbar und mutmasslich die verbreiteste Variante, sich auf anderen Rechnern einzuloggen.

Infizierte ssh-Server sollten nachher beliebige Befehle aus der Ferne entgegennehmen und mit Administratorrechten (root) ausführen. Bei einem ssh-Login wird die Nutzerin heute meist durch sogenannte „ssh-Keys“ identifiziert, eine sehr sichere Variante auf der Basis von Public-Key-Encryption (seltener noch durch Passwörter).

Der zusätzlich eingeschleppte Code sorgte dafür, dass gewisse dieser ssh-Schlüssel nicht wie sonst üblich zur Authentifizierung verwendet werden sollten. Stattdessen wird der mitgelieferte (präparierte) öffentliche Schlüssel als Kommandozeile für uminterpretiert und ausgeführt.

Dadurch ist

1. fast jeder Befehl auf dem Zielrechner ausführbar, ohne dass im Logfile fehlgeschlagene Loginversuche auftauchen würden und
2. der Angriff ist clever als „NOBUS“-Attacke („Nobody But Us“) ausgelegt: Der Angriff muss mit einem definierten privaten Schlüssel signiert sein, der zu dem in der Backdoor hinterlegten öffentlichen Schlüssel passt. Ausser dem Akteur hinter der Backdoor kennt mutmasslich niemand diesen Schlüssel. (Und wenn er erratbar wäre, wären so ziemlich alle Sicherheitsmassnahmen im Internet wertlos.)

Wie kommt es in ssh?

Rund 80% der aus dem Internet ansprechbaren ssh-Server nutzen OpenSSH. Diese Implementierung ist aber unabhängig von xz. Wie kommt der Schadcode also in den Server? Viele der Linux-Distributionen nutzen nicht die offizielle OpenSSH-Version, sondern fügen ein paar Erweiterungen ein, um sie Beispielsweise in Firmenumgebungen besser nutzen zu können.

Zur Erhöhung der Zuverlässigkeit des Systems haben viele Distributionen das Init-System systemd stärker in ssh integriert. Dabei wird eine Bibliothek libsystemd zusätzlich benötigt, die wiederum von xz und damit den infizierten Komponenten abhängt. Voilà!

Beim Start nun überschreibt der Backdoor-Code die Funktion, die zur Überprüfung der ssh-Key-Authentisierung nötig ist durch die Version mit der (bösartig) „erweiterten“ Funktionalität.

Note 5¾, sehr gut!

Wir haben es mit einer von langer Hand vorbereitetem Angriff zu tun, wie er vielen Geheimdiensten gut anstehen würde:

1. Man gibt sich mehrere Jahre Vorlauf
2. Man versteckt die Sicherheitslücke gut
3. Sie lässt sich nur vom Angreifer ausnutzen
4. Sie hinterlässt kaum Spuren
5. „Offiziell“ gibt es keinen Bezug zwischen der manipulierten Bibliothek und der infizierten Software
6. Es wurde langfristig und zukunftsorientiert geplant, mit der Möglichkeit, in der Zukunft weitere Ziele unauffällig einbauen zu können

Eigentlich müsste man für dieses Vorgehen eine Note 6+ ausstellen, wenn es nicht die IT-Sicherheit von unzähligen Systemen, deren Daten und den davon abhängigen Personen und kritischen Infrastrukturen gefährden würde.

Gemachte Fehler

Doch Abzüge gibt es dafür, dass keine vollständigen Tests in realen Systemumgebungen gefahren wurden. Damit hätte diese Erkennung der Sicherheitslücke verhindert werden können. Wir sind also wirklich extrem knapp an einer Katastrophe vorbeigeschrammt, die Abermillionen von Servern auf der ganzen Welt dem unbekannten Akteur hinter „Jia Tan“ ausgesetzt hätten.

Es ist aber (leider) davon auszugehen, dass zukünftige Akteure mehr interne Tests fahren werden. Und darauf müssen wir vorbereitet sein. (Es wurden auch Mutmassungen geäussert, dass die Organisation hinter „Jia Tan“ weitere Projekte mit anderen Pseudonymen parallel am Laufen haben könnte, da die vorgenommenen Änderungen niemals kein Vollzeitpensum ergäben. Auch diese mutmasslichen parallelen Aktivitäten dürften von dieser Erkenntnis „profitieren“.)

Plausible Deniability

Es ist zu erwarten, dass zukünftige derartige Supply-Chain-Attacken versuchen werden, glaubhafte Abstreitbarkeit zu erreichen, wie sie bei einigen klassischen Geheimdienstaktivitäten schon zur Tradition geworden ist. Das heisst, man versucht die Hintertür so zu kaschieren, dass es auch ein Flüchtigkeitsfehler der Softwareentwickler hätte sein können. Der Vorteil ist, dass ein so etablierter Backdoor-Schreiber weitermachen könnte und nicht neu beginnen müsste.

Wie wir am Beispiel von „Jia Tan“ sehen, sind aber Wegwerfidentitäten zumindest aktuell noch mit wenig Aufwand zu etablieren; wahrscheinlich lohnt sich der zusätzliche Aufwand nicht.

Beispiele finden sich im Literaturverzeichnis. Dort fehlt explizit DUAL_EC_DRBG, da keine Abstreitung erfolgte.

Wieso die Eile?

[Neu 2024-04-02 21:00] Nach Publikation des Artikels wurde mir mitgeteilt, dass am 29. Februar 2024 ein Änderungsvorschlag bei systemd einging, der das Nachladen der Kompressionsbibliotheken (u.a. xz) aus Effizienzgründen vom Programmstart auf später verschieben wollte. Mutmasslich sah die Organisation hinter „Jia Tan“ ihre Felle davonschwimmen. Denn wenn diese Änderung in die Linuxdistributionen übernommen worden wäre, hätte ihre von langer Hand vorbereitete sshd-Backdoor nicht mehr funktioniert. (Aufgrund des sorgfältig vorbereiteten Plugin-Systems wäre ein Wechsel auf andere Programme möglich gewesen; eine ähnlich attraktive Alternative zu finden, die auch ohne systemd von xz abhängt, wäre wohl schwierig gewesen.)

Ohne diesen Zeitdruck wären vom „Jia Tan“-Team möglicherweise zusätzliche Tests gefahren worden und die hohe CPU-Last vermieden worden, die Andres Freund dazu veranlasste, das Problem unter die Lupe zu nehmen und damit die Backdoor zu entdecken.

Was lernen wir daraus?

Dies ist ein typisches Beispiel für einen Supply-Chain-Angriff, bei dem nicht die Software selbst, sondern eine ihrer Abhängigkeiten, Bibliotheken oder Module infiziert wird. Diese sind sehr schwierig zu entdecken. Und trotzdem würde die ganze Softwarebranche ohne diese grossartige Auswahl an (zumeist Open-Source-)Hilfsmitteln zusammenbrechen. Dieses Wochenende wurden viele Optionen genannt, nicht alle davon neu. Sie gehen in verschiedene Richtungen, die sich manchmal auch teilweise widersprechen.

Vereinfachung

Eine Meinung geht dahin, sich wieder der Modularität und Einfachheit von Programmen zu widmen, also eine Art Revival der Unix-Philosophie: Wir sollten uns bei Software wieder auf die wichtigen Komponenten besinnen und nicht einfach alles an zusätzlichen Softwarekomponenten importieren, nur weil es praktisch ist. Oder zumindest versuchen, diese Abhängigkeiten so weit wie möglich zu isolieren.

Belohnung

Es wird auch eine bessere Entlöhnung der (oftmals) Freiwilligen gefordert, welche diese Pakete pflegen.

Beispielsweise könnten Firmen damit beginnen, dass jede:r ihrer Entwickler:innen monatlich einen bestimmten Betrag, beispielsweise 50 Franken, zur Verfügung hat, die er/sie Projekten nach Wahl zukommen lassen kann. Mit weniger als 1% der Entwicklungskosten könnte so das Ökosystem und damit auch die Produkte der spendenden Firma signifikant sicherer gemacht werden. (Auch anstelle von oder zusätzlich zu „Open-Source-Wartungsverträgen“ oder direkten Entwicklungsaufträgen.)

Michał Zalewski hält dies alleine aber noch nicht für ausreichend. Denn genau „langweilige“ Pakete wie eben xz, die stabil laufen und wo jede Änderung potenziell mehr Nachteile als Vorteile nach sich zieht seien das Problem. Es gelte auch, zusätzliche Motivation dafür zu finden, da die Betreuung eines solchen Projektes ähnlich interessant sei, wie dem Gras beim Wachsen zuzuhören.

Er fordert gleichzeitig auch grosse Firmen auf, die massiv von diesen Paketen profitieren und sie in ihren eigenen kostenpflichtigen Produkten nutzen oder weitergeben, ihre Pakete selbst aktiv nach Sicherheitsproblemen zu scannen. Und es würde nur ein Bruchteil der billionenteuren Riesenprojekte kosten, die einige Firmen auf sich nähmen, wie grosse Sprachmodelle oder selbstfahrende Autos:

Even when it comes to lesser threats, the bottom line is that we have untold trillions of dollars riding on top of code developed by hobbyists. The companies profiting from this infrastructure can afford to thoroughly vet and monitor key dependencies on behalf of the community. To be clear, a comprehensive solution would be a difficult and costly undertaking — but it’s not any harder or costlier than large language models or self-driving cars.

Michał „lcamtuf“ Zalewski in OSS backdoors: the folly of the easy fix (2024-03-31).

Bessere Kontrolle

Es wurde auch die Aussage gemacht, dass die Betreuer von solchen Systemen noch mehr Zeit in Qualitätssicherung stecken müssten, also die unvergütete Last, die sie bereits jetzt tragen, nochmals zu erhöhen.

Dies halte ich aus obiger Sicht für wenig sinnvoll. Allerdings könnten durchaus auch nationale IT-Sicherheitszentren (in der Schweiz das Bundesamt für Cybersicherheit, BACS) diese Aufgabe übernehmen. Denn es fördert ihre eigene Cybersicherheit und die ihrer Wirtschaft und Bürger.

Neue Ideen

Informatikstudierende erhalten neben vielen Hintergründen und methodischen Ansätzen während ihrer Ausbildung auch Kenntnisse in der praktischen Softwareentwicklung. Leider basiert die häufig nur darauf, von Null an ein eigenes Softwareprojekt zu entwickeln.

In der Wirtschaft benötigte Skills wie die Analyse oder Erweiterung von bestehendem, z.T. fremden Code, fehlen oft. Hier könnte eine Mitarbeit in einem dieser Open-Source-Projekte durchaus mehrfachen Vorteil bringen. Nicht nur würden die Studierenden wichtige Praxiserfahrung sammeln, auch die Prxzojekte hätten entsprechende Unterstützung.

Die Idee ist nicht neu. So habe ich früher Lehrveranstaltungen in ähnliche Richtungen angeboten, aber auch LibreFaso, ein Projekt in Burkina Faso, bot Studierenden entsprechende Stipendien an.

«Gibt es das auch als Video?»

Wer das lieber als Video sieht (oder Leute kennt, die lieber Videos schauen als Text zu lesen): Hier gibt es ein grossartiges Video von Fireship auf YouTube. Ich mag vor allem die Analogie, mit der der Einbau und die Entdeckung der xz-Backdoor erläutert wird.

Zum Nachlesen

Dieser Tage ist viel zum Thema geschrieben worden. Hier ein Versuch, einige wichtige Quellen und verwandte Informationen halbwegs strukturiert zu präsentieren.

Es gibt inzwischen einen Follow-Up-Artikel:

Was geschah

• Andres Freud: I accidentally found a security issue while benchmarking postgres changes, 2024-03-29.
  Fediverse-Thread des Entdeckers, mit Link auf die Mailinglistendiskussion.
• Evan Boehs: Everything I Know About the XZ Backdoor, 2024-03-29.
  Ein Überblick über die Vorgeschichte.
• Kevin Beaumont: Fediverse-Thread, seit 2024-03-29.
  Überblick über die (neuesten) Entwicklungen aus Sicht eines Sicherheitsforschers.
• Jan Wildeboer: Fediverse-Thread, seit 2024-03-30.
  Fediverse-Thread zu xz aus Sicht eines Red-Hat-Mitarbeiters
• Samuel Rüegger: Die «xz-Hintertür» gefährdet unzählige Computer weltweit – was wir bisher wissen, 2024-03-31.
  Ein deutschsprachiger Überblick über die Timeline.
• Lasse Collin: XZ Utils backdoor, 2024-03-30.
  Die Aussage des ursprünglichen xz-Entwicklers.
• Rhea Karty und Simon Henniger: XZ Backdoor: Times, damned times, and scams, 2024-03-30. [neu 2024-04-03]
  Aufgrund von Arbeitszeiten und -tagen wird vermutet, dass „Jia Tan“ in Osteuropa oder Russland arbeite (was nicht heissen muss, dass „Jia Tan“ für eine der dortigen Regierungen arbeitet).
• Trigglux: xz backdoor, 2024-04-02. [neu 2024-04-04]
  Gegenteilige Meinung: Dass es eine einzelne Person gewesen sei, die im Fernöstlichen Bereich lebt und die Backdoor abends nach seiner Arbeitszeit und am Wochenende entwickelt habe.
• Russ Cox: Timeline of the xz open source attack, 2024-04-01/03. [neu 2024-04-13]
  Die wohl am besten strukturierte Timeline der xz-Events.
• Folker Schmidt und Justus Tartz: xz-Backdoor – eine Aufarbeitung, HiSolutions, 2024-04-12. [neu 2024-04-13]
  Ein etwas technischerer Blick auf die Geschichte; auch mit der Bitte für signierten Commits.

Betroffene Systeme

• Christopher Kunz: Hintertür in xz-Bibliothek gefährdet SSH-Verbindungen, Heise, 2024-03-30.
  U.a. Auflistung der betroffenen Distributionen.
• Christopher Kunz: xz-Attacke: Hintertür enträtselt, weitere Details zu betroffenen Distros, Heise, 2024-03-30.

(Technische) Hintergründe

• Thomas Roccia: XZ Outbreak (CVE-2024-3094), 2024-03-31.
  Grafischer Überblick über die Schadfunktion und ihre Einbindung.
• Daroc Alden: How the XZ backdoor works, LWN (nur für Abonnenten), 2024-04-02. [neu 2024-04-03]
  Sehr gut nachvollziehbare Beschreibung der Backdoor für Techies.
• Connor Tumbleson: Watching xz unfold from afar, 2024-03-31.
  Eine detaillierte Beschreibung der Abläufe.
• Gynvael Coldwind: xz/liblzma: Bash-stage Obfuscation Explained, 2024-03-30.
  Technische Erklärung, wie die Sicherheitslücke versteckt wurde.
• Rob Mensching: A Microcosm of the interactions in Open Source projects, 2024-03-30.
  Einblick in die zwischenmenschlichen Interaktionen am Beispiel von xz/liblzma.
• Antonio Diaz Diaz: Xz format inadequate for long-term archiving, 2016-06-11 (aktualisiert 2022-02-02).
  Eine Kritik am Xz-Fileformat und seiner Fehlerüberprüfung, bei der ich nur einen Teil der Argumente teile. Hat keinen inhaltlichen Bezug zu diesem Angriff, zeigt aber, dass sich Entwickler manchmal mit (zu) breit angelegter Kritik konfrontiert sehen. Eine gute Tat vollbringen zu wollen stösst in diesem Bereich oft auf heftigeren Gegenwind als nötig.
• Lennart Poettering: sd_notify, aktualisiert am 2024-04-02.
  Es gibt jetzt Democode von Luca Boccassi, mit dem die sd_notify()-Funktion auch ohne Abhängigkeit von libsystemd verwendet werden kann. Die Verwendung dieses Democodes verhindert den xz-Angriff.
• Who is the mysterious Jia Tan who installed a backdoor in the compression tool XZ Utils?, Gigazine, 2024-04-04. [neu 2024-04-06]
  Erwähnt u.a. die von „Jia Tan“ genutzte VPN-Verbindung via Singapur.

Reverse Engineering (2024-04-06)

Etliche Leute arbeiten daran, die Funktionsweise der Backdoor zu analysieren und zu dokumentieren. Hier einige Artikel:

• Bojan Zdrnja: The amazingly scary xz sshd backdoor, 2024-04-01.
  Erläutert die Funktionen und die Datenspeicherung im Programmcode.
• xzre Documentation, ongoing.
  Versuch der Erstellung einer „Quellcodedokumentation“ aus dem binären Programmcode der xz-Backdoor. Zum Einstieg z.B. hier.

Vergleiche zu anderen Sicherheitslücken

• Marcel Waldvogel: Meltdown und Spectre: Lesen ohne zu lesen, 2018-01-15.
  Allgemeinverständliche Analogien für die beiden komplexen Sicherheitslücken (und der Beginn meiner Karriere als Erklärbär 😊).
• Kristian Köhntopp: Kommentar zu Log4j: Es funktioniert wie spezifiziert, Heise, 2021-12-14.
  Die Log4j-Sicherheitslücke wird gerne als Vergleich gebracht. Doch eigentlich verhielt sich dort fast alles anders.
• Ron Bowes: Code injection or backdoor: A new look at Ivanti’s CVE-2021-44529, Greynoise Labs, 2024-02-16.
  Eine Analyse der „Ivanti Endpoint Manager“-Backdoor von 2021.
• Marcel Waldvogel: Y2K38: Timed Obsolescence, DNIP, 2024-01-19.
  Auch die Jahr-2000- oder -2038-Probleme könnten globale Auswirkungen haben. Aber nicht in dem hier gerade vereitelten Ausmass.
• Russ Cox: Running the “Reflections on Trusting Trust” Compiler, 2023-10-25.
  Ken Thompson hielt 1983 anlässlich der Ehrung mit dem Turing-Award einen Vortrag, der später als Artikel „Reflections on Trusting Trust“ in die Geschichte eingehen sollte. Er beschreibt, wie man eine Hintertür (in einem Compiler) so versteckt, dass sie im Quellcode nicht (mehr) sichtbar ist. (Die xz-Backdoor ist ebenfalls nicht im eigentlichen Quellcode sichtbar, verwendet aber andere Ansätze.) Der Artikel von Russ Cox erklärt die Funktionsweise am originalen Thompson-Code.
• Clifford Stoll: Cuckoo’s Egg (Deutsch: Das Kuckucksei), Wikipedia-Eintrag dazu.
  Stoll entdeckte einen Hackerangriff auch wegen einer Kleinigkeit (Buchungsdifferenz von $0.75) und mit viel Persistenz; nicht unähnlich zur Entdeckung dieser Backdoor.

Beispiele von Plausible Deniability

Eine Liste von Sicherheitslücken, bei denen nicht offensichtlich ist, ob es Versehen oder Absicht war.

• Eclypsium: Supply Chain Risk from Gigabyte App Center Backdoor, 2023-05-31.
  Eine automatisch installierte Software hat Firmware-Updates heruntergeladen. Dabei wird die Quelle der zu installierenden Software nicht richtig überprüft, wodurch ein Einschleusen (MITM) von Malware möglich ist.
• Synopsys: Understanding the Apple ‘goto fail;’ vulnerability, 2014-02-25.
  Eine verdoppelte Zeile führte dazu, dass die Gegenstelle bei einem TLS-Verbindungsaufbau nicht korrekt verifiziert wurde.
• Scott Craver: The Underhanded C Contest, Wettbewerb der Jahre 2005…2015.
  Ein Wettbewerb, in dem man Programme schreiben musste, die neben der offiziellen Aufgabe eine versteckte Zusatzaufgabe zu erfüllen hatten. Diese Funktion durfte aber beim Überprüfen des Quellcodes nicht auffallen.
• Monika Ermert und Jürgen Schmidt: Schnüffelcode in Juniper-Netzgeräten: Weitere Erkenntnisse und Spekulationen, Heise, 2015-12-21.
  Hier wurde der Code rund um DUAL_EC_DRBG unauffällig so modifiziert, dass er mutmasslich von anderen Angreifern genutzt werden konnte (und möglicherweise auch beim Belgacom-Angriff genutzt wurde).

Lösungsansätze

• Glyph Lefkowitz: Software needs to be more expensive, 2024-03-30.
  Die Idee, dass jede:r Entwickler:in jeden Monat 50$ zur Verfügung haben sollte, mit der hilfreiche Open-Source-Projekte unterstützt werden können.
• Michał „lcamtuf“ Zalewski: Technologist vs spy: the xz backdoor debate, 2024-03-30.
  Die Bemerkung, dass Geld alleine nicht reiche («watch paint dry»-Zitat).
• Michał „lcamtuf“ Zalewski: OSS backdoors: the folly of the easy fix, 2024-03-31.
  Die Last der besseren Überprüfung solle nicht (nur) auf den Entwicklern/Maintainern ruhen, sondern die grossen Sicherheitsfirmen und Geheimdienste sollten sich auch daran beteiligen.

Weitere (spätere) Berichte (2024-04-06)

Vor allem zu Dokumentationszwecken für zukünftige Archäologen.

• Nikita Mazurov: The Other Players Who Helped (Almost) Make the World’s Biggest Backdoor Hack, The Intercept, 2024-04-03.
• A stealth attack came close to compromising the world’s computers, The Economist, 2024-04-02.
• Dan Goodin: What we know about the xz Utils backdoor that almost infected the world, Ars Technica, 2024-04-01.
• Andy Greenberg und Matt Burgess: The Mystery of ‘Jia Tan,’ the XZ Backdoor Mastermind, Wired, 2024-04-03.
• Lukas Mäder: «Das ist der verrückteste Angriff»: Ein Programmierer entdeckt per Zufall eine gefährliche Hintertüre im Code – wohl von einem Geheimdienst, NZZ, 2024-04-04.
• Daniel Schurter: Wie ein paar Nerds an Ostern den vielleicht schlimmsten Hack der Geschichte verhinderten, Watson, 2024-04-03.

Nachtrag 2024-04-06: GitHub-Repository

Bei meinem heutigen Besuch auf dem GitHub-Repository war die Fehlermeldung eine andere. Ein paar OSINT-Schritte.