«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?
Inhalte
ToggleTL;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?
Hintergrund: Ein paar Begriffe
PostgreSQL, oft als Postgres abgekürzt, ist eine beliebte Datenbanksoftware. Sie hat nur durch einen glücklichen Zufall mit dem xz
-Problem zu tun.
Linux ist ein von Linus Torvalds 1991 als Hobbyprojekt gestarteter Betriebssystemkern (und inzwischen die Basis für die meisten Server im Internet). Ein Betriebssystemkern (“Kernel“) alleine ist aber für Normalsterbliche nutzlos. Deshalb hatten verschiedene Personen und Organisationen schon früh damit begonnen, diesen Kernel mit einer Sammlung von Programmen zu versehen, anfänglich mit Kommandozeilentools, später dann auch mit grafischen Oberflächen.
Eine Linux-Distribution ist eine solche Sammlung von Programmen, gemeinsam mit dem Linux-Kernel, jeweils mit unterschiedlichen Eigenschaften und Zielgruppe. Bekannte Linux-Distributionen tragen Namen wie Debian, Fedora, Red Hat, SUSE, Ubuntu etc.
Eine Programmbibliothek, kurz Bibliothek, ist eine thematische Sammlung von nützlichen Funktionen, welche von Programmen genutzt werden kann. Ohne Bibliotheken wäre moderne Softwareentwicklung unmöglich.
xz ist eine Werkzeugssammlung (Bibliothek) zur effizienten Datenkompression. Da die Dateien damit sehr gut komprimiert werden, hat es breite Beliebtheit erfahren. Eine Variante als Programmbibliothek, die liblzma, kann auch in andere und eigene Programme integriert werden. xz
spielt hier eine Hauptrolle.
ssh ist ein Kommandozeilenprogramm, welches eine sichere Verbindung zu einem anderen Server aufbaut, über die dieser dann ferngesteuert werden kann. ssh
, genauer die beliebteste Variante OpenSSH, spielt hier die andere Hauptrolle.
Eine Backdoor ist eine Hintertür in einem Programm oder Computersystem. Mit einer Hintertür können unter Umgehung der normalen Sicherheitsschranken Funktionen ausgeführt werden. Diese sind meist Teil eines Angriffs durch Unbefugte und stellen damit ein Sicherheitsrisiko dar.
Bei einer Supply Chain Attack auf eine Software wird nicht die Software selbst mit einer Schwachstelle (z.B. einer Backdoor) versehen, sondern eine von dieser Software direkt oder indirekt verwendete “Zuliefer”-Komponente, beispielsweise eine für diese Software verwendete Bibliothek.
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
Hintergrund: Free/Libre Open Source Software
Zu Anfang des Computerzeitalters wurde viele Software zusammen mit dem Computer geliefert oder die (wenigen) Nutzer:innen eines bestimmten Computertyps teilten sich ihre Programme untereinander: Das Ziel war, die Computer möglichst gut zu nutzen.
Erst später kam die Idee auf, Software separat zu verkaufen. Ein wichtiger Teil der Computernutzer wollten ihre Software aber weiterhin grosszügig teilen, beispielsweise, damit sie ihre Programme für beliebige Zwecke nutzen konnten, daraus lernen konnten, die Programme anpassen und verbessern und diese neuen Versionen auch teilen zu können. (Aus Gründen der Übersichtlichkeit fasse ich alle möglichen Kombinationen und auch teilweise Einschränkungen davon unter dem Begriff “Open Source” zusammen.)
Heute findet Open-Source-Softwareentwicklung meist auf öffentlich zugänglichen Repositorien statt: Das sind auf Quellcode spezialisierte Dateiablagen, welche das gemeinsame Entwickeln technisch unterstützen, paralleles Arbeiten ermöglichen und Transparenz über die Entstehungsgeschichte geben. Die beliebteste Form von Repositorien beruht heute auf der Software git; diese ist auch Grundlage für Kollaborationsplattformen wie GitHub und GitLab.
Repositorien bieten aber auch die Möglichkeit, Neuerungen für sich privat auszuprobieren und diese, sobald man damit zufrieden ist, der Allgemeinheit als Verbesserung vorzuschlagen. Auch wenn viele Schritte verteilt und demokratisch erfolgen, schlussendlich gibt es eine kleine Gruppe von Entscheidern, welche über die Annahme der Neuerungen entscheiden. Diese werden häufig Maintainer genannt.
Viele dieser Softwareprojekte sind als Meritokratien aufgebaut: Wer sich für das Projekt engagiert und aktiv einbringt, bekommt mit der Zeit von seinen Kolleg:innen mehr Rechte zugestanden. So kann man sich beispielsweise zum Maintainer hocharbeiten.
Um die Qualität der in einem Projekt gepflegten Software hoch zu halten, integrieren die meisten Projekte automatische Tests in ihre Repositorien, die beispielsweise bei jeder Quellcodeänderung automatisch überprüfen, ob die Änderungen nicht zu Fehlern führen. Ein solches Werkzeug ist das weiter unten relevant werdende oss-fuzz
.
- 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 derxz
-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.
- Wie heute allgemein üblich, enthält auch
- 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 denvalgrind
-Fehler behebe. Der für dieses Paket Zuständige bei Debian aktualisiert auf die neuestexz
-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
- fast jeder Befehl auf dem Zielrechner ausführbar, ohne dass im Logfile fehlgeschlagene Loginversuche auftauchen würden und
- 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:
- Man gibt sich mehrere Jahre Vorlauf
- Man versteckt die Sicherheitslücke gut
- Sie lässt sich nur vom Angreifer ausnutzen
- Sie hinterlässt kaum Spuren
- “Offiziell” gibt es keinen Bezug zwischen der manipulierten Bibliothek und der infizierten Software
- 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 diesd_notify()
-Funktion auch ohne Abhängigkeit vonlibsystemd
verwendet werden kann. Die Verwendung dieses Democodes verhindert denxz
-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. (Diexz
-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.
xz
arbeite, lassen auf Letzteres schliessen.)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.
20 Antworten
Man möchte zu dem Ganzen etwas sagen, etwas kommentieren und traut sich dann aber doch nicht.
Hier kann man fast alles sagen. Oder es uns privat via Signal oder Threema mitteilen.
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.
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.
sd_notify()
gibt es erst seit ca. 2 Tagen einzeln. Und direkt darüber steht immer noch, dass man lieber die Library einbinden soll. Auch wenn Lennart Poettering im Fediverse meint, das Protokoll sei stabil und die Einbindung nicht nötig.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.
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.
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.
Wenn viele was falsch machen wird es dadurch nicht richtig. Aber die Sachzwänge immer , ja ja…
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?
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.!
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 …
Hallo Preda,
kurz zur Relativierung:
Aber selbstverständlich darf das jede:r als China-Bashing ansehen, der/die das so will.
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?
Wo bitte wische ich den Chinesen eins aus? Etwas konkretere Kritik wäre schon hilfreich.
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.
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.
“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.
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.
wow – danke für die spannende Berichterstattung. Und ALLEN, die über OSTERN den Angriff verhindert haben, ein dickes Dankeschön!