Nach XZ-Backdoor: Open-Source-Software als Risiko oder strategischer Vorteil?

Ist öffentlich entwickelte Open Source Software besonders anfällig für Social-Engineering-Angriffe oder bietet gerade sie eher strukturelle Resilienz dagegen?

In Pocket speichern vorlesen Druckansicht 220 Kommentare lesen

(Bild: BeeBright / Shutterstock.com)

Lesezeit: 12 Min.
Von
  • Florian v. Samson
Inhaltsverzeichnis

Endlich Feierabend! Die Katze hat sich zufrieden schnurrend auf dem Firmenlaptop eingerollt. Es ist 20:00 Uhr. Ich will noch schnell den von mir vor Jahren notdürftig improvisierten Protokollparser in meinem Utility durch die deutlich besseren Funktionen aus einer Bibliothek auf GitHub ersetzen, wozu mich schon die ganze Zeit ein User drängt.

So oder so ähnlich sehen viele Abende oder auch Nächte der Menschen aus, die in ihrer Freizeit an Free/Libre-Open-Source-Software-Projekten (FLOSS) arbeiten. Neben der eigentlichen Programmierarbeit muss ein solches Projekt organisatorisch gepflegt werden, Releases müssen erstellt und verwaltet werden. Anwender stellen Fragen, äußern Wünsche oder leisten Beiträge in Form von Patches oder Fehlerberichten. All dies macht die gelebte Dynamik und die offene Zusammenarbeit bei FLOSS-Projekten aus, beansprucht aber einiges an Zeit, die dann nicht zum Programmieren zur Verfügung steht.

Zu programmieren ist aber bei den meisten die eigentliche Motivation, ihre wertvolle Freizeit zu opfern. So ist es überaus erfreulich, wenn Dritte hilfreiche Beiträge zum Projekt leisten. Im Falle der XZ Utils und dem inzwischen berüchtigten Jia Tan fing es im Oktober 2021 mit Diskussionsbeiträgen auf der Mailingliste an, ab April 2022 folgten Patches, die anfangs über die Mailingliste, später als direkte Pull Requests eingereicht wurden und beispielsweise lästige Angelegenheiten wie Probleme im Build-Prozess behoben haben. Etwa zeitgleich begannen andere die organisatorischen und personellen Schwierigkeiten des Projekts zu diskutieren und als Lösung einen zweiten Projektverantwortlichen vorzuschlagen, wie es bei der offenen Kollaboration im Rahmen öffentlicher FLOSS-Projekte durchaus üblich ist.

Nicht auszuschließen ist, dass es sich bei diesen „anderen“ ebenfalls um die Person oder Personengruppe hinter Jia Tan handelt. Allerdings ist es üblich, dass Beitragende zu öffentlichen FLOSS-Projekten unter Pseudonymen auftreten und sich eine gute Reputation durch konstruktive Zusammenarbeit erwerben, sei es in Form von Hilfestellungen, Dokumentation, Übersetzungen, Unterstützung bei der Projektorganisation oder eben auch konkreten Verbesserungen an der Software. Natürlich wird solche Hilfe meist gerne angenommen und zahlt im Laufe der Zeit auf die Währung „Vertrauen“ ein.

So ist Jia Tan wie der nette Nachbar, der einem die Tür aufhält, wenn man schwer beladen vom Einkaufen zurückkommt oder der regelmäßig Paketlieferungen annimmt, die man sonst beim Paketshop am anderen Ende der Stadt abholen müsste.

Zwar gibt es viele Entwicklerinnen und Entwickler im Umfeld von Free/Libre Open Source Software, die sich beispielsweise auf Konferenzen persönlich kennengelernt haben, aber mit dem überwiegenden Teil der Beitragenden haben Projektverwalter meist nur durch E-Mails und GitHub-Aktivitäten Kontakt. So ersetzt eine längere, konstruktive Historie der Zusammenarbeit im digitalen Raum die persönliche Bekanntschaft als Fundament für das Vertrauen.

Irgendwann treffen wir die Entscheidung, dem netten Nachbarn auch den Wohnungsschlüssel zu geben, damit er in unserer Abwesenheit die Blumen gießen oder die Katze füttern kann. Und dafür wird wohl keiner dessen polizeiliches Führungszeugnis verlangen – warum auch: Es gibt keinen konkreten Anlass, diesem Menschen zu misstrauen.

Genau so hat es wohl auch Lasse Collin gesehen, als er Jia Tan im Januar 2023 Schreibrechte für das GitHub-Repository der XZ Utils eingeräumt hat. Warum auch nicht? Die bisherigen Beiträge waren hilfreich und Jia Tan hatte schon einiges für das Projekt geleistet. Im März 2023 benennt Jia Tan sich als Ansprechpartner für die XZ Utils bei Googles „OSS Fuzz“-Projekt, einem Source Code Security Scanner und reichte dort im Juni 2023 als Mitverwalter der XZ Utils Änderungen zum Scannen der XZ Utils ein, die auch angenommen wurden.

Mit der Änderung der Projekt-Webseite auf eine bei GitHub gehostete Site im Februar 2024 und dem darauffolgenden Erstellen von Releases der xzUtils war das Ziel erreicht: Alle Prozesse des Projekts waren nun auch in der Hand von Jian Tan und es war inzwischen auch üblich, dass er diese Tätigkeiten durchführte. So konnte er im März 2024 die offiziellen Sourcecode-Releases der Versionen 5.6.0 und 5.6.1 der XZ Utils eigenständig als „Tarballs“ (.tar.gz-Archive) veröffentlichen.

Auf den ersten Blick erscheinen die Beiträge von Jia Tan in den zweieinhalb Jahren von Oktober 2021 bis März 2024 weitgehend positiv: konstruktive E-Mails sowie zahlreiche Patches beziehungsweise Pull Requests, die augenscheinlich echte Probleme lösen. Im Nachhinein lässt sich dagegen nachvollziehen, dass er systematisch und schrittweise angefangen hat, soziale Nähe zu erzeugen und dann die Grundlagen für eine technisch komplexe Schadfunktion in kleinen Häppchen unter zahlreichen Codebeiträgen versteckt in die XZ Utils eingebracht hat. Die beim „OSS Fuzz“-Projekt eingereichte Änderung hat dafür gesorgt, dass das Projekt den Schadcode nicht entdeckt hat.

Schließlich hat der Angreifer über eine „Verbesserung“ von Testdateien den Code der eigentlichen Schadfunktion extrem gut versteckt in komprimierter und chiffrierter Form eingebracht. Er landete in Dateien der XZ Utils, in denen niemand nach bösartigem Code suchen würde, da es sich augenscheinlich um reine Datendateien zum Testen der XZ Utils auf korrektes Funktionieren handelt, versteckt in einer Form, in der weder manuelle Code-Reviews noch maschinelle Codescans den Schadcode identifizieren können.

Darüber hinaus wurde die Schadfunktion nur erstellt, wenn man die XZ Utils aus den Release-Tarballs kompilierte, nicht jedoch, wenn man den Sourcecode direkt dem GitHub-Repository entnahm. Der eigentliche Clou ist aber, dass die Schadfunktion eine Hintertür in OpenSSH öffnet, wenn diese mit XZ-Unterstützung kompiliert wurde, und dann auch nur auf x86-64 Rechnern unter Linux mit systemd. Dies sind genau einzuhaltende Rahmenbedingungen, die aber für die meisten Linux-Distributionen auf Rechnern mit CPUs von Intel oder AMD gegeben sind. Des Weiteren ist diese Hintertür nur mit Kenntnis eines bestimmten, geheimen Schlüssels nutzbar.

In der Summe hat der Angreifer also über zweieinhalb Jahre hinweg viel Energie und Hirnschmalz investiert, um in einem etwas aus der Mode gekommenen und daher inzwischen wenig beachteten Datenkompressor möglichst unauffällig eine Schadfunktion einzubringen, die eine Hintertür in der meistgenutzten Fernzugriffssoftware auf fast allen x86-64 Rechnern unter Linux öffnet, die aber nur Personen mit Kenntnis eines bestimmten kryptografischen Schlüssels nutzen können.

Solch ein sowohl technisch als auch organisatorisch hoher Aufwand ist für staatliche Akteure nicht ungewöhnlich: Man denke nur an die lange Geschichte der Crypto AG sowie den von der NIST Hintertür-behaftet spezifizierten und von Symantec, Juniper und anderen US-Firmen implementierten Zufallszahlengenerator Dual_EC_DRBG. Eine weitere Gemeinsamkeit ist, dass all diese Beispiele in der westlichen Welt spielen, weil dort nach vielen Jahren solche Vorgänge manchmal doch öffentlich werden; im Fall der XZ Utils waren es nur wenige Monate, weil alle relevanten Informationen zur Technik wie auch der Projektorganisation jederzeit transparent nachvollziehbar und offen zugänglich sind, da es sich um ein öffentliches FLOSS-Projekt handelt.

Dagegen erscheint es bei dem weltweiten Mangel an IT-Fachkräften eher einfacher für einen Nachrichtendienst, einen Mitarbeiter bei einer Softwarefirma einstellen und agieren zu lassen; insbesondere da sein Tun nicht öffentlich zugänglich dokumentiert wird und somit das Entdeckungsrisiko deutlich geringer ist und sich die Details seiner Aktionen oft nicht so transparent nachvollziehen lassen wie bei FLOSS. Auch sind die Entdeckungsmöglichkeiten und die technische Analyse schwerer oder gar nicht möglich, wenn der Quellcode einer Software nicht vorliegt. Darüber hinaus hat eine betroffene Software-Firma kein Interesse daran, dass ein solcher Vorgang an die Öffentlichkeit gelangt.