xz-Backdoor: Realer Angriff auf das Internet?

Ein raffinierter “NOBUS”-Angriff

Mittlerweile ist schon recht viel bekannt, wie der Angriff wohl abgelaufen ist und wie jemand es schaffte, Schadcode unbemerkt in ein weit verbreitetes Open Source Projekt einzuschleusen. Freie Software soll ja per Definition genau das verhindern: Der Quellcode eines Programms ist für jedermann frei einsehbar, sodass jeder ihn auf seine Funktionalität und eventuelle Schadhaftigkeit überprüfen kann. Und genau dieser Umstand hat auch dazu geführt, dass das jemand getan und die Hintertür zum Glück entdeckt hat. Aber der Reihe nach.

Eigentlich ist es ein recht langweiliges Projekt: “XZ Utils” ist ein Werkzeug um effizient Daten zu archivieren. Es ist schon recht ausgereift, und beinhaltet Programme und Bibliotheken zur Komprimierung von Daten ¹. Angeblich wird das Projekt lediglich von einem freiwilligen Entwickler “aus Spaß an der Freude” betreut - das kommt leider häufiger vor bei Free Software Projekten.

Und genau deshalb ist diese Software so interessant für einen Angriff. Denn neben dem Umstand dass nur eine einzelne Person zu überlisten ist, nutzt natürlich auch der OpenSSH Dienst Ressourcen des zugrundeliegenden Systems - unter anderem die liblzma.so Bibliothek aus eben diesem Projekt “XZ Utils”. Die Hintertür wurde darüber hinaus raffiniert versteckt - so wurde diese nicht einfach im öffentlich einsehbaren Code von “XZ-Utils” eingebaut, sondern die schädlichen Codezeilen findet sich laut den analysierenden Entwicklern nur in den komprimierten Release Dateien und dieser Code sorgt im Build Prozess dafür, dass entsprechende Codeteile währenddessen über angebliche Testdateien nachgeladen werden.

Zusätzlich wurde noch dafür gesorgt, dass derjenige, der die eingebaute Funktion später nutzen will, eine entsprechende digitale Signatur (Schlüssel) mitliefern muss - also eine “Nobody but us” (NOBUS)² Funktion, die eigentlich nur den Schluss zulässt, dass wohl ein Geheimdienst hinter der Attacke stecken dürfte.

So ist es zum Beispiel anscheinend auch nicht möglich, wie bei anderen Sicherheitslücken einen entsprechenden Vulnerability-Scanner zu schreiben um die Systeme auf eben diese Sicherheitslücke zu untersuchen. Fehlt nämlich der vorhin erwähnte nötige Schlüssel, stellt die Hintertür ihre Arbeit ein und der normale OpenSSH Code wird ausgeführt.

Ein “Free Software Krimi”

Psychotricks und Fake-Accounts: Es ist schon ziemlich abenteuerlich, wie man es geschafft hat das Projekt zu übernehmen. Einer der Angreifer mit dem Pseudonym “Jia Tan”³ (ich nenne ihn jetzt nur noch “Angreifer”, da es sich ohnehin um ein Kollektiv von Fake-Identitäten handeln dürfte) tauchte bereits 2021 beim ebenfalls freien Projekt “libarchive” mit einer einfachen Änderung dieses Quellcodes zur Verbesserung einer Fehlermeldung auf. Möglicherweise wollte er sich eine vertrauenswürdige Github-Identität aufbauen.

2022 dann schlägt genau diese Github-Identität dem einzigen Maintainer von “XZ Utils” eine Änderung an xz vor. Dieser düfte zu der Zeit wohl einige Probleme gehabt haben und war anscheinend nicht wirklich in der Lage sich entsprechend um das Projekt zu kümmern - von daher war er wohl für die Hilfe dankbar. Außerdem begannen plötzlich andere Accounts den Maintainer mit Forderungen und Beschwerden unter Druck zu setzen. Der Hauptangreifer schaffte es sich Vertrauen bei ihm zu erschleichen und Rechte anzueignen.

2023 waren sie dann erstmals in der Lage neue Änderungen am Code selbstständig in das Projekt einzupflegen. Im März setzten die Angreifer die “Jia Tan” Identität dann als Kontaktperson für Warnungen der automatischen Sicherheitstools ein - ab diesem Zeitpunkt konnten dann auch unsichere Codeänderungen eingepflegt werden. In den Monaten darauf wurde eine Änderung eingepflegt, die das automatische Tool “oss-fuzz” als potentiell gefährlich erkannte, worauf der Angreifer das Team um die automatischen Tests bat, den entsprechenden Test zu deaktivieren ⁴. Das machen übrigens auch andere Projekte - ist also eigentlich nichts besonderes - nachträglich gesehen in diesem Fall natürlich schon.

2024 wurde der Schadcode dann eingepflegt. Es wurden für automatisierte Test entsprechende “Testdateien” aufgenommen - eben diese Testdateien wie schon Anfangs beschrieben. Zusätzlich wurde angeblich auch noch eine Art “Plugin-System” eingebaut, wodurch später noch Erweiterungen hätten vorgenommen werden können. Die Angreifer waren sozusagen gekommen um zu bleiben.

Gleichzeitig standen sie auch in Kontakt mit einem Fedora-Entwickler⁵ und mit der Debian Mailinglist⁶ um für die Aufnahme ihrer kompomitierten Pakete zu werben.

Und tatsächlich schafften sie es den Schadcode in die Vorversionen der Distributionen Fedora und Debian einzuschleusen - zum Glück nicht in die stabile Version.

3 Tage danach, nämlich am 28. März 2024 fiel dem Postgres-Entwickler Andreas Freund beim Testen von Änderungen an seinem eigenen Projekt auf, das in der Vorversion von Debian der Remote Login offensichtlich 500 Millisekunden (!sic) langsamer geworden war und ging der Sache auf den Grund ⁷.

Fazit

Es scheint möglich zu sein, mit etwas Geduld und durch die Kontrolle eines einzigen Menschen so viel Macht zu erlangen, um den Großteil des Internets zumindest theoretisch vorübergehend abrauchen zu lassen.

Gleichzeitig ist es möglich, dass ein einzelner, aufmerksamer Entwickler, der sich offensichtlich an 500 ms Verzögerung stört, die Welt vor ebendiesem Supergau bewahrt.

Die Frage ist schon, wie viele Hintertüren dieser Art es womöglich bereits gibt - sowohl in der Open Source Projekten als auch in proprietärer Software. Dort scheint es mir noch einfacher zu sein, denn die Angreifer müssten dafür nur eigene Leute ins Unternehmen einschleusen (sollte für einen Geheimdienst kein allzugroßes Problem sein) und es würden mit Sicherheit nicht so viele Augen den Quellcode Sicherheitschecks unterziehen.

Ebenso ist höchst interessant, dass lediglich Fachblogs und entsprechende Magazine über diesen nachgewiesenermaßen böswilligen Angriffes eines höchstwahrscheinlich staatlichen (womöglich westlichen?) Akteurs auf die weltweite Internet-Infrastruktur berichtet haben.

Und da fallen mir auch noch die Planspiele des WEF namens „Cyber Polygon“ ⁸ ein, wo genau solche “Supply-Chain-Attacken” durchgespielt ⁹ werden und davor gewarnt wird. Spätestens seit dem ebenfalls von dem WEF durchgeführten “Event 201” und der Corona-Pandemie bin ich sehr aufmerksam wenn aus dieser Ecke neue, gruselige Warnungen wie z.B. über “frightening scenarios” durch welche “the COVID 19 crisis would be seen in this respect as a small disturbance in comparison to a major cyber attack” ¹⁰ kommen. Ich möchte nämlich vorbereitet sein, wenn angekündigte “Cyber Pandemien” dann Realität werden.