Was für ein Morgen, wenn man so etwas liest, dann kräuseln sich einem erst einmal die Nägel. Aber fangen wir vorn an:

Die XZ Utilities beinhalten u.a. das XZ Kompressionsprogramm, was aber nicht Ziel des Angriffs war, sondern die Libs, die andere Programm benutzen um XZ und LZ Kompressionen durchzuführen. Das sind Kompressionsverfahren, die teilweise noch aus tiefster Vergangenheit stammen. In den 80er hatten wir auf dem Amiga schon LZH Kompressionsprogramme, die komprimierte Archive erzeugt oder ausgepackt haben.

XZ ist eine aktuelle Weiterentwicklung davon, die u.a. für die Kompression des Linuxkernelimages in /boot benutzt wird.

xz-utils / liblzma backdoored

Ohne Euch zu sehr mit Details zu nerven, zunächst mal was wir wissen:

Der Angriff wurde seit ~2.5 Jahren vorbereitet.

Ein GitAccount namens „Jin Tan/JinT75“ unterstützte den Author von XZ Lasse Collin vor 2-2.5 Jahren das erste mal offiziell. Erwähnt wird er von Collin im Juni 2022 im Zuge des JAVA Teils von XZ. Aus dem Post von Collin geht hervor, daß der User schon seit einiger Zeit hinter den Kulissen mit Collin kommuniziert und „Aushilft“.

Das XZ Projekt wird von Collin als Hobbyprojekt klassifiziert, da er auch quasi der Einzige ist, der daran Änderungen macht. Das dürfte der Grund sein, wieso sich die Angreifer XZ ausgesucht haben, denn Collin gibt in dem Post selbst an, daß er Psychische Probleme hat und sich nicht um das Projekt kümmern kann.  Da sind ideale Voraussetzungen für die Angreifer, da er ein dankbares Ziel für Hilfe ist.

Durch die Kette, das Systemd auf die XZ liblzma setzt und SSH mit Systemd daher angreifbar ist, machte XZ zum Ziel. Auch andere externe Teile, die von SSH genutzt werden, könnten betroffen sein, nur das da noch keiner nachgesehen hat.

Betroffen sind bislang nur Paketversionen >= 5.6.0 xz-libs

Die offensichtlichen Backdoor Commits auf Github sind bislang nur für die Version 5.6.0 und 5.6.1 identifiziert worden.
Bei Debian läuft aber eine Diskussion, ob man nicht auf 5.3.1 zurück gehen müßte, weil da die ersten, nicht eindeutig zuordenbaren Commits von „Jin Tan“ beginnen. Es müsse schliesslich alles als Teil der Backdoor angesehen werden.

Natürlich würde ein Angreifer den Author erstmal mit hilfreichem Code anfixen, so daß er Vertrauen aufbaut. Insofern sind vermutlich nicht alle Codezeilen ein Problem. Wissen kann man das natürlich nicht, da die Backdoor vielleicht nur die neueste Ausartung des Angriffs darstellt.

Nehmen wir an, im Code wurde ein Bufferoverflow eingebaut, mit dem ein RCE möglich ist, wenn z.b. ein TAR Archiv ausgepackt wird. Das könnte schon vor 2 Jahren in den 5.4er Zweig eingebaut worden sein, insofern ist die Annahme, das alles von „Jin Tan“ Schadcode ist vernünftig und alles muß überprüft werden.

Der Bugtracker von Debian ist überlastet, wenn Ihr da Heute am Tag des Postings draufklickt, nicht wundern wenn es lange dauert, oder gar nicht geht: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024

Debian und Redhat Buildinformationen triggern die Backdoor beim Bau

Im Makefile der Backdoor gibt es Hinweise darauf, daß die diese nur funktioniert, wenn glibc, der gcc und der Gnu Linker ld vorhanden ist. Für andere Plattformen wird die Backdoor nicht gebaut. Gleichzeitig gibt es Filter für X86_64 Architekturen, Debian und Redhatbasierte Distrokennungen.

OpenSUSE, Redhat,Fedora, Debian und Ubuntu haben reagiert

wobei hier anzumerken ist, daß der Versuch den Patch bei Ubuntu unterzubringen gefailed ist. Da war die Betafrist für die neue Version kurz vor dem Ablauf und den Ubuntu Leuten zu heikel. Gute Prinzipien helfen offenbar.

Fedora 38, 39 und alle Mobility Images sind bislang nicht betroffen

Fedora 38 und 39 basieren noch auf der 5.4.1 Version von XZ und sind daher bislang nicht betroffen. Fedora Mobility basiert auf Fedora 39.

Bitte daran denken, daß sich das ändern kann, wenn Schadcode in Form von Bufferoverflows im bisherigen Code auftauchen.

F40 soll vorsichtshalber reagieren, ist aber eh noch Beta, F41 ist abzuschalten.

Reguläre Benutzer werden noch nicht betroffen sein, daß Fedora 40 in der 5.6.0 erstmals auftaucht noch in der Betaphase ist und daher nicht produktiv ist Einsatz sein sollte. Für Fedora 40 wird auch ein Downgrade vorbereitet. Fedora 41 ist Bleeding Edge Software, das sollte niemand ernsthaft einsetzen.

Der Hack besteht am Ende aus einem unautorisierten Login via SSH

Die Kette von Ereignissen der Backdoor führt in letzter Konsequenz zu einem unautorisierten Login via SSH, zumindest war das die Absicht. Laut Analysen des getarnten Codes analysiert der Schadcode den Login kryptographisch. Da ein direkter Login mit einem beliebigen User nicht möglich ist, das würde schliesslich sofort auffallen, weil alle Botnetze direkt Zugriff bekommen würden, wird hier wohl zusätzlich ein Key ausgewertet.

Vermutung – Wer steckt hinter dem Angriff?

Hier müssen wir vorsichtig sein, weil einiges suspekt aussieht, es aber vielleicht nicht ist.

Vor einer Stunde ( 9:30 Ortszeit ) wurden Informationen gepostet, daß die Authorengruppe zu der auch der „Jin Tan“ Account zählt, an einer Unzahl von OSS-Projekten beteiligt war, die fast alle Kryptographischen Bezug haben z.B.:

That actor is involved in so many PR/commits/review in openssl and systemd, protobuf-c. llvms, util-linux. torvalds/linux, make-ca, cpython, curl, libxcrypt, dosbox-x, rust…
16 repo contributed to this year, 47 repos in 2023, 38 in 2024.
Some of his PRs are reviewed in conjunction with xen0n or xry111 is reviewing PRs from him. xen0n has contributed 36 repos this year, 101 in 2023 and 136 in 2024.

Quelle: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

Die Gruppe versucht die LOONGSON Architektur in die Software einzupflegen, jetzt ratet mal, wessen CPUs das sind. Genau: Die neuen CPUs der Chinesen.  Da ist natürlich der erste Reflex ein Selbstläufer 😉

Die meisten Commits sind allerdings für den XZ Angriff irrelevante Anpassungen, da sie sich nur auf als LOONGSON gebaute Programme beziehen. Ein Generalverdacht existiert nicht.

Der Author des obigen Posts wurde dann von anderen korrekter weise darauf hingewiesen, daß er hier keine unbewiesenen Anschuldigungen machen soll, einige der LOONGSON Gruppen wären persönliche Bekannte. Fragt sich nur, von wem, denn auch über diese Leute wissen wir rein gar nichts 🙂

Ihr könnt erkennen, das driftet derart schnell in Verschwörungstheorien ab, da muß man richtig vorsichtig sein.

Fakt ist: die Backdoor ist da.

Alles andere muß sich finden, in dem die Repobesitzer die Commits der Verdächtigen überprüfen und zur Aufklärung beitragen.

Wer hier helfen will und abgedrehte C Erfahrungen hat , z.b. Fefe, die können ja mal die 700 Commits von „Jin Tan“ im XZ Repo unter die Lupe nehmen. Bei Exploitcode für C bin ich praktisch raus.

Quellen:

https://boehs.org/node/everything-i-know-about-the-xz-backdoor

https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html

https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024

TheSameSam Gist zum XZ Vorfall