Wie die Open-Source-Community an Ostern die (IT-)Welt rettete

Huch, waren das spannende Ostern, aus IT-Sicht! Es wurde die potenziell schlimmste IT-Sicherheitskatastrophe durch puren Zufall noch rechtzeitig abgewendet. Ansonsten hätte ein Angreifer Millionen von Servern weltweit im Nu unter seine Kontrolle bringen können.

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.

Auf DNIP.ch findet ihr wie immer ihre ganze Geschichte kostenlos mit vielen Details. Hier aber das, was wir jetzt tun müssen.

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.

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