Filmreifer Angriff auf die Serversysteme weltweit

Um Ostern 2024 hat sich ein reales Szenario in der Opensource Security-Entwickler-Szene abgespielt, das das Zeug für einen modernen James-Bond-Film haben könnte. Denn eben solche Geheimdienst-Agenten schleusten versteckte Backdoors in eine der wichtigsten Zugriffstools in der modernen IT ein.
Nur durch die Benchmarks eines einzelnen Entwicklers ist eine über Jahre vorbereitete Unterwanderung von Millionen Systemen aufgedeckt wurden. Das ist wieder einmal ein Beweis dafür, wie effektiv OpenSource funktioniert. In einem Software-Konzern wäre das erst gar nicht bekannt geworden, wenn man es überhaupt entdeckt hätte. Jedenfalls von dem Aufwand und der Akribie, die dahintersteckt, nach zu urteilen, riecht das gewaltig nach staatlichen Angreifern.

Im Großen und Ganzen wurde nur eine kleine Kompressionsbibliothek liblzma.so mit Schadcode infiltriert. Doch was jetzt eine Kompressionsbibliothek aus dem xz-Tool mit der Sicherheit von kompletten IT-System zu tun?

Das hängt mit einem der wichtigsten Admin-Werkzeugen, dem SSH (Secure Shell) zusammen, der auf jedem Linux-System per Default zu finden ist. Dieser Service sorgt für einen sicheren, verschlüsselten Low-Level-Zugang zu Servern aller Art durch Systemadministratoren. Unter Linux und Unix generell ist es üblich, mittels SSH auf der Kommandozeile des jeweiligen Server einzuloggen. Das geht effizienter als über graphische Desktops, und wenn dieser gar nicht läuft ist es der einzige Weg, es sei denn man sitzt physisch direkt mit Monitor und Tastatur an dem Server.

Nicht auszumalen, wenn also exakt dieser SSH, mit dem man über das Internet andere Server erreichen kann, eine Sicherheitslücke hat. Und man kann davon ausgehen, dass weltweit die SSH-Zugänge in die Zig-Millionen geht. Somit wäre eine Hintertür exakt in dieser Software, mit der sich aus der Ferne Befehle ausführen ließe, der Heilige Gral für jeden Geheimdienst.

Aber SSH ist nicht umsonst derart beliebt. Wurde es doch Sicherheitsnerds auf der Basis modernster Sicherheitskonzepte entwickelt und in den letzten Jahrzehnten immer weiter auf Sicherheit hin getrimmt.

Das Problem war weniger schlampiger Programmcode, sondern mehr die Faktoren Mensch und Vertrauen. Der SSH-Service ist nicht ein einziges Programm, sondern er greift auf bereits laufende Ressourcen des jeweiligen Linux-Systems zu. So werden von ihm mehr als 20 dynamische Bibliotheken geladen. Darunter ist eben auch die besagte liblzma.so, durch die Funktionen zur (De-)Kompression im xz-Format bereitgestellt werden. Die XZ Utils bieten die von den etablierten Linux-Packprogrammen gzip und bzip2 gewohnte Handhabung gepackter Dateien für den fortschrittlichen Lempel-Ziv-Markow-Datenkompressionsalgorithmus (LZMA) sowie eine Basis für dessen einfache Integration in andere Programme.
Fakt ist, dass sich in das Projekt eine Person mit dem Decknamen Jia Tan eingeschleust und sich dann das Vertrauen erschlichen hatte. Er war seit 2021 in dem Projekt engagiert. Parallel wurde auf den ursprünglichen Maintainer Druck durch Angreifer mit anderen falschen Identitäten ausgeübt, bis eben der Maintainer Jia Tan 2023 immer weitergehende Zugriffsrechte gewährte.

Eine komplette Chronologie ist hier zu finden.

Wie funktioniert jetzt diese Hintertür?

Jia Tan platzierte in die Version 5.6.0 von xz Schadcode, der selber nicht im öffentlich einsehbaren Quellcode des XZ-Projekts liegt. Sondern er sorgte dafür, dass der Build-Prozess den Code aus angeblichen Test-Dateien extrahierte und in das finale Binary der liblzma-Bibliothek einbaute. somit lässt sich der Backdoor-Code nur in den Release-Tarballs des Projekts finden.
Da diese Hintertür nur in Binärform vorliegt und selber mittels Anti-Debugging-Maßnahmen schützt, gibt es bislang keine detaillierte Analyse. Was man aber sagen kann, ist, dass die Hintertür sich nur durch den SSH-Prozess nutzen lässt, also wenn dieser mit „usr/bin/sshd“ initialisiert wird. Nach bisherigem Wissen greift die Bibliothek eine Funktion aus dem Login-Prozess auf sich selber um. Somit landen die Versuche sich mit einem RSA-Public-Key mittels RSA_public_decrypt() anzumelden immer in dem Hintertür-Code. Jetzt wird der aktuell dazu verwendete öffentliche Schlüssel verifiziert und die Kommandobefehle extrahiert, um sie dann auf dem Server auszuführen.
Warum verifiziert die Malware zusätzlich noch die öffentlichen Schlüssel? Das ist jetzt wirklich dreist, denn nicht jeder soll dieses Einfallstor nutzen können, sondern nur die die auch die richtige Signatur der Befehlssequenz liefern können. Nun und das können nur Jia Tan und die hinter ihm stehenden Angreifer mit ihrem privaten Schlüssel. Das ist eine klassische NOBUS-Backdoor („Nobody but us“), wie sie Geheimdienste gerne nutzen.

Und mal ganz ehrlich! So wie das organisiert wurde, kann das nicht eine einzelne Person umgesetzt haben. 2021 beginnt ein Entwickler an dem Projekt mit zu arbeiten und offensichtlich da schon unter Scheinidentitäten. Gleichzeitig setzen andere Personen den Maintainer unter Druck und zuletzt wurden auch die einzelnen Linux-Distributionen angehalten, Ihre Repositories bezüglich der XZ-Utils zu updaten. Zusätzlich entwickelt ein Einzelner nicht nur das Backdoor-Script und die API zur Bibliothek, um das Script unter bestimmten Bedingungen aufrufen und während einer SSH-Session nutzen zu können. Das ist derart komplex, dass das nicht aus einer Laune eines Einzelnen entstanden sein kann. Sondern die gesamte Logistik, die dort drin steckt und die Raffinesse deuten auf Hintermänner und Geheimdienste.

Welche Versionen sind betroffen?

Der Schadcode befindet sich in den aktuellen XZ-Tools xz-5.6.0 und xz-5.6.1 sowie den zugehörigen liblzma-Bibliotheken. Auch einige Kanditaten konnten bereits in die Unstable- und Testing-Repositories der Linux-Distributionen vordringen. Jedoch weder Debian, Ubuntu noch RedHat haben sie in die Stable-Repositories aufgenommen.
Aber genau daraufhin hatten eine Reihe von Personen sehr intensiv hingearbeitet. Möglicherweise aus der gleichen Ecke wie dieser Jia Tan mit Tarnidentitäten.

War es jetzt Zufall oder die Gewissenhaftigkeit des Software-Entwicklers Andres Freund oder gar Beides? Jedenfalls wurde er hellhörig als seltsame CPU-Lasten bei fehlgeschlagenen SSH-Login-Versuchen bei den neuen Versionen von liblzma auftraten, bei den Vorgängerversionen aber nicht. So konnte er den maliziösen Code in in einem Script des Tar-File entdecken und schlug am Karfreitag 2024 Alarm. Selbst das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnte. Auch RedHat veröffentlichte den Vorfall als CVE-2024-3094.

Ohne dieses Hinterfragen und vor allem die freie Verfügbarkeit des Programm-Codes wäre es womöglich zu einem Super-GAU auf vielen Millionen Systemen gekommen, deren Türen und Tore für eine kleine Gruppe sperrangelweit offen gestanden wären.

Welches Fazit lässt sich daraus ziehen?

Jetzt wird es mit großer Wahrscheinlichkeit Stimmen geben, die den Beweis für die Untauglichkeit des OpenSource-Konzept erbracht sehen, wenn Jeder und Jede ungeprüft an Stellen nachrücken können, die man in einem Unternehmen als hoch kritisch deklarieren würde.

Wie sich obigen Artikel von Evan Boehs entnehmen lässt, wurde der Maintainer des XZ-Projektes psychisch durch Dritte – offensichtlich Komplizen von Jia Tan – solange unter Druck gesetzt, bis er einem Co-Maintainer zustimmte. Das ist bei Github leicht umsetzbar, indem man einem anderen Mitglied Zugriff auf das Projekt gewährt. Somit liegt der Schwachpunkt eindeutig im Supply-Chain-Management (SCM) des Projektes.
Es ist zwar „nur“ eine kleine Bibliothek, die die Komprimierung von Dateien gemäß dem Lempel-Ziv-Markow-Algorithmus (LZMA) unterstützt, aber dadurch, dass sie zentral von vielen anderen Programmen genutzt werden kann, wie in diesem Fall dem SSH, wird sie kritisch im Sinne von IT-Sicherheit. Hier trägt im Prinzip eine einzelne Person die Verantwortung von der Entwicklung, der Wartung, der Fehlerbehebung und Weiterentwicklung bis hin zum Deployment. Gleichzeitig hängen so viele andere Projekte weltweit an diesem einen Projekt. Das kann nur zur Überforderung führen.
In der OpenSource-Community hat sich das Mehr-Augenprinzip als das Richtigere erwiesen. Warum schafft man nicht Strukturen zum Beispiel von GitHub, die Verkettung zu anderen IT-Projekten aufzeigt und gleichzeitig Releases erst dann freigibt, wenn aus unterschiedlichen abhängigen Projekten das Okay in ausreichender Mehrheit kommt?
Das müsste man nicht überall einführen, aber zumindest bei Projekten, die sozusagen „systemrelevant“ oder besser sicherheitskritisch eingestuft werden. Das wäre zum Beispiel der SSH-Service, vor allem wenn er von mehreren Betriebssystemen gleichermaßen eingesetzt wird.

So war in diesem Krimi weniger das OpenSource-Konzept das Problem, im Gegenteil die Aufmerksamkeit des Postgres-Entwicklers und der offene Quellcode haben das Problem aufdecken lassen. Sondern es ist noch der laxe Umgang mit den Zuständigkeiten und noch zu weniger Prüfstellen vor einem Release.