Suche
Close this search box.

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

Wie ein Superheld an Ostern die IT-Welt schützt. Mit DALL-E generiert.

«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.

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.

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).

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

Betroffene Systeme

(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:

Vergleiche zu anderen Sicherheitslücken

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.

Nachtrag 2024-04-06: GitHub-Repository

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

Stand des xz-GitHub-Repos am 2024-04-06: Es zeigt jetzt die klassische GitHub-“404 Not Found”-Seite an. Dies könnte bedeuten, dass das git-Repository des Projekts gelöscht wurde, oder aus meiner Sicht wahrscheinlicher, dass die Repository-Zugriffsrechte auf “privat” eingestellt wurden. (Die Aussage von Lasse Collin, dass er an der Bereinigung von xz arbeite, lassen auf Letzteres schliessen.)
Hier ein Ausschnitt der GitHub-Aktivitäten von “Jia Tan” aus dem Jahre 2023. Es sind keine Aktivitäten im xz-Repository verzeichnet, obwohl er nach Aussagen in den anderen Artikeln in diesem Jahr sehr aktiv war. Es sind aber viele Aktivitäten in “privaten Repositorien” aufgeführt; mutmasslich, weil das xz-Repo jetzt privat ist.

dnip.ch mit Deiner Spende unterstützen

Wir wollen, dass unsere Inhalte frei verfügbar sind, weil wir es wichtig finden, dass möglichst viele Menschen in unserem Land die politischen Dimensionen der Digitalisierung erkennen und verstehen können.

Damit das möglich ist, sind wir auf deine Unterstützung angewiesen. Jeder Beitrag und sei er noch so klein, hilft uns, unsere Aufgabe wahrzunehmen.

20 Antworten

  1. Vielen Dank für die spannende Berichterstattung und zur Erinnerung, dass milliardenschwere Konzerne ihre Systeme auf dieser Frewilligenarbeit aufbauen und der Open Source Community etwas zurückgeben könnten.

  2. Ich würde beim Titel “Wie kommt es in ssh?”, noch erwähnen das libsystemd fälschlicherweise eingebunden wurde. Offenbar könnte man ja einfach sd_notify() nutzen.
    Habt ihr ja so auch in den Referenzen aufgeführt.
    Soll nicht victim blaming sein sondern einfach aufzeigen, dass SystemD dies bereits unterstützt hätte.

  3. Sehr interessant! Den Freiwilligen, die freie und quelloffene Programme pflegen, können wir nicht genug danken. Diese unbesungenen Helden leisten viel unerkannte und unbezahlte Arbeit, die unsere digitale Welt im Innersten zusammenhält. Ich musste auch an das xkcd-Bild mit “some random Person in Nebraska” denken…

    Dass Angriffe auf wichtige digitale Infrastruktur an Feiertagen erfolgen, lässt sich auch in anderen Zusammenhängen beobachten. Sicherheitsinfrastruktur muss gerade ausserhalb der regulären Arbeitszeiten gegen Angriffe verteidigt werden.

  4. Wir schreiben April 2024. Alle verantwortungsvollen Admins wissen, dass man das Administrationsinterface von Servern niemals, wirklich niemals, offen ins Internet hängt. Weder RDP noch SSH noch wasauchimmer. Zugang nur über VPN mit 2FA ist hier der Goldstandard.

    Nur dnip macht nen aufgeblasenen Artikel aus diesem NothingBurger.

    1. 24+ Millionen Admins sehen das leider noch anders, wie du oben siehst. Oder haben nicht den Provider, der ihnen das einfach macht. Oder Zeit und Wissen. Oder haben doch einmal einen Fehler gemacht. Oder ein Firmennetz. Oder, oder, oder…

      Und was, wenn die nächste Supply-Chain-Attacke deinen VPN-Server auf dieselbe gebackdoort hätte? Dann wäre auch dein 2FA weg gewesen.

      Erzähl du einem Teil der 24 Millionen Admins von den Best Practices oder hilf ihnen bei der Umsetzung. In der Zwischenzeit nehme ich mir Supply Chains und die anderen Baustellen vor.

        1. Es geht ja nur sekundär um ssh, primär sehen wir hier eine ausgeklügelte und über längere Zeit entwickelte Attacke auf ein weitverbreitetes Tool. Was ist, wenn das nächste Mal Wireshark im Visier ist, oder nginx?

  5. Vielen Dank für den Artikel.
    Als interessierter Laie wurde mir wieder gezeigt, wie wenig ich doch von dieser “Welt” weiß.
    Ein großen Danke an alle Freiwilligen etc.!

  6. Eine spannende Geschichte. Informatiker sind eine besondere Rasse, scheinbar. Sie stellen sich vor, jemand — eine Gruppe, vermutet man, vermutlich mit Recht — hat so viel Geduld, know-how und Zielstrbigkeit, einen ueblen Coup ueber 2 Jahre vorzubereiten. Sie wollen anonym bleiben, aber geben sich einen Namen der sagt “Hallo, Schlaefer, wir sind Chinesen”. Und bei aller Analyse, dieser unwahrscheinlicher Umstand wird ausgelassen — man laesst den Zweifel, aber uebernimmt Karikaturen wo ausdruecklich von Chinesen die Rede ist, spricht von Reiswein, usw.
    Wisst ihr was? Mir stinkt das viel mehr nach jemandem der den Chinesen eins hineinwischen will! Aber nicht wahr, Verbrecher sind dumm im Volksmund, gerade diejenige die nicht “unsere Vebrecher” sind …

    1. Hallo Preda,

      kurz zur Relativierung:

      • “Jia Tan” steht immer in Anführungszeichen. Ich ging davon aus, dass damit allen Leser:innen klar war, dass es sich um ein frei ausgesuchtes Pseudonym handle, wie übrigens auch “Jigar Kumar” und “Hans Jansen” (aber nicht Lasse Collin).
      • Mit der “Karikatur […] von Chinesen” meinst du wohl das Meme (wie die Karikatur oft eine Form der satirischen Überspitzung) von Kevin Beaumont mit den XKCD-Klötzchen. In meiner Bildunterschrift steht da: «Ob “Jia Tan” wirklich aus China stammt, ist unklar.»
      • Der Satz mit dem Reiswein heisst komplett: «Wahrscheinlich wird jetzt eine Flasche Champagner, Vodka oder Reiswein geöffnet; oder was auch immer in jener Weltgegend zum Feiern eines Erfolges dazugehört.»
      • In der Literaturliste steht auch: «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).»

      Aber selbstverständlich darf das jede:r als China-Bashing ansehen, der/die das so will.

    2. Ja, den Chinesen eines hineinwischen. Dreh mal “Jia Tan” in “Tan jia” um, dann weisst Du wo der Hase im Pfeffer liegt. Oder Tanja 75?

        1. Hallo Marcel Waldvogel. Mein Post war an Preda gerichtet. Da haben sich unsere beiden Antworten wohl überschnitten. Ich denke auch das es alle und jeder gewesen sein könnten. Deswegen mein Hinweis auf den Anagram Namen. War nicht als Kritik an Ihrem Beitrag gemeint.

          1. Ah, Threads sind hier nicht so klar. Ich dachte, du wolltest trotz meiner Replik nochmals in die gleiche Kerbe hauen. Nichts für ungut!

            PS: Das Thema kommt wohl in einem Follow-Up-Artikel noch zur Sprache.

  7. “Wie die Open-Source-Community an Ostern die Welt gerettet hat.”
    Habe als IT-Verantwortlicher bis zu meinem Ausscheiden aus einem 250-Frau/Mannbetrieb die OS-Fahne hochgehalten – von den Anmelde- und Fileservern, den email-Systemen bis hin zum lokal verwendeten Officesystem.
    Aber in diesem Fall hat IMHO die Open-Source Community gar nichts gerettet, leider. Sie hat es verzapft!
    Gerettet hat es – was für ein Witz und dann auch noch by chance – ausgerechnet ein Microsoft-Angestellter.

    1. Ich versuche es mit einer Analogie: Ein städtischer Mitarbeiter hat an einer Strassenkreuzung die Strassenbeleuchtung erneuert, damit Fussgänger und -streifen jetzt viel besser zu sehen sind. Von der Leiter ist ihm aber auch eine Bananenschale runtergefallen, auf der jemand ausgerutscht ist und nur knapp einem in übersetzter Geschwindigkeit daher kommenden Auto retten kann, mit nur einer kleinen Schürfung. Und jetzt sollen alle städtischen Mitarbeiter mit faulen Tomaten beworfen werden?

      Ich glaube nicht.

      Es gibt wohl kaum ein IT-Projekt, in dem nicht kleiner oder grössere Fehler passieren, auch Sicherheitslücken. Egal ob open oder closed source.

      Auch ein Mitarbeiter einer Firma, egal ob klein oder gross, kann Teil der OSS-Community sein, das ist kein Widerspruch. Es geht mir übrigens nicht nur um Andres Freund und Microsoft, auch wenn ich ihnen zu riesigem Dank verpflichtet bin. Es geht mir auch um die anderen Leute, die sich über das Wochenende die Zeit genommen haben, den Dingen auf den Grund zu gehen, die Auswirkungen rückgängig zu machen (im Projekt selbst und downstream) und sich zu überlegen, wie wir das alle in Zukunft besser machen können. Dafür gebührt meiner Ansicht nach allen auch ein grosses Dankeschön!

      Im Übrigen glaube ich, dass es wohl kaum ein Projekt gibt, welches nicht in riesigem Masse von Open Source abhängig ist, sei es Basisquellcode, Libraries, Tools (Compiler, IDE, …). Der Austausch von Quellcode und Erfahrung durch OSS/FOSS/FLOSS hat unsere IT-Produktivität als Gesellschaft massiv erhöht.

  8. wow – danke für die spannende Berichterstattung. Und ALLEN, die über OSTERN den Angriff verhindert haben, ein dickes Dankeschön!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Weitere Beiträge

Vogt am Freitag: Anfeuern

Wer ein Feuer machen kann, erkennt digitale Zusammenhänge. Das findet Zürichs Bildungsdirektorin Silvia Steiner. Das von ihr geforderte Handyverbot ist

Weiterlesen »