Linux über große Hintertür gehackt? Alles was du zum XZ Backdoor wissen solltest

[DMW007]

Die GNU/Linux Gemeinschaft ist seit kurzem schockiert über eine Hintertür, die am Osterfreitag (29.03.2024) nach ihrer Entdeckung veröffentlicht wurde. Dabei handelt es sich um gar keine Lücke im Linux-Kernel, sondern um eine Bibliothek zum Entpacken von XZ-Archiven. Dieses Format gewinnt seit Jahren zunehmend an Beliebtheit, da es kleinere Archive verspricht. Beispielsweise setzt auch das Raspberry Pi OS seit einiger Zeit auf XZ-Archive, um ihre Abbilder zu komprimieren. Einige Distributionen haben es daher mittlerweile vorinstalliert, wie es mit den Kommandozeilenwerkzeugen anderer Packprogramme (z.B. ZIP, TarGz usw) seit längerem der Fall ist. Darüber hinaus setzt das verbreitete Init-System auf xz und benötigt es als Abhängigkeit.

Allerdings ist die Hintertür aus verschiedenen Gründen komplexer: Sie besteht aus mehreren Teilen, ein wichtiger davon wurde nur in den binären Releases eingebaut. Wer den Code selbst kompiliert, besitzt eine laut derzeitigen Infos saubere Version. Dazu kommt, dass der manipulierte Code nicht nur beim erstellen oder entpacken von XZ Archiven ausgeführt wird: Über Systemd leitet der Schadcode unter bestimmten Umständen Funktionsaufrufe vom SSH-Daemon an eigene Funktionen weiter, da einige Distributionen SSHD mit Systemd patchen, um den Status weiterreichen zu können. Es handelt sich daher um keinen Fehler von OpenSSH - die Konstellation entsteht durch das Patchen der Distributionen mit Systemd. Obwohl XZ nicht direkt in SSHD referenziert wird, kann daher XZ auf dessen Code zugreifen. Dies nutzt der Backdoor aus, um mit einem präparierten SSH-Schlüssel den Zugangsschutz auszuhebeln und Code auszuführen.

Durch diese umfangreiche Verkettung ist der Beitrag etwas länger geworden. Er geht nicht auf jedes Detail ein, aber versucht die derzeitigen Informationen auf gut 21 Minuten zusammen zu fassen und einzuordnen. In den kommenden Tagen und Wochen werden sicher weitere Erkenntnisse entstehen. Insbesondere zum Angreifer sind derzeit noch einige Fragen offen. Es deutet sich an, dass es sich um einen staatlich motivierten Hacker (z.B. im Auftrag eines Geheimdienstes) handelt, der möglicherweise noch weitere Projekte kompromittiert hat.

Hier geht es zum kompletten Beitrag im U-Labs Portal

[U-Labs YouTube]

Kommentar von @nocheaven8427:
Herzlichen Dank für die Infos

Kommentar von @harkai-ne2yb:
Danke für dieses sehr informativer Video

Kommentar von @rubenlara3386:
Vielen Dank für deine Arbeit und die wichtige Info!

[U-Labs YouTube]

Kommentar von @hugoschmitz6649:
Ich hab jetzt nicht 100% zugehört, hattest du erwähnt das der Hauptentwickler aufgrund persönlicher Probleme angemerkt hat das er froh, um die Hilfe war und gleichzeitig weniger kontrolliert hat?
Weil das ist ja auch ein Aspekt. Das eigentlich der Hauptveranwortliche auch ein Code review machen sollte, was aber in diesem Fall aus den Gründen nicht so gründlich ausfiel.

Und was für den Laien vielleicht auch nicht so verständlich ist. Bei der grossen Anzahl an Commits können zwischenzeitlich auch viele (gute) Sicherheitsrelevante Änderungen eingeflossen sein. Daher kann man nicht so ohne weiteres alles zurück setzen (was aber im Gespräch ist, wenn ich es richtig gelesen habe) da man ansonsten auch behobene Sicherheitslücken wieder einbauen würde, was noch mehr Verwirrung stiften könnte.

[DMW007]

Solltest du, beides ist drin. Das Ressourcenthema zum Beispiel im Punkt was besser gemacht werden kann mit Verweis auf OpenSSL Heartbleed. Zu tief bin ich bewusst nicht darauf eingegangen, es soll ein Überblick mit Fokus auf die Hintertür sein, ohne dabei zu lang zu werden. Diese beiden Themen sind ausführlicher mMn in einem eigenen Beitrag besser aufgehoben. Gerade der Umgang mit den Commits von ihm wird noch für einige Beschäftigung sorgen. Er hat alleine 750 zum xz Projekt beigetragen. Da können wie du sagtest wohlwollende Sicherheitsfixe drin sein, die jetzt ggf. in der älteren Version fehlen. Genau so können in den älteren Commits weitere bewusst eingepflegte Exploits enthalten sein, die bisher nur nicht gefunden wurden.

Das geht noch weiter. Beispielsweise hat der auch bei einem Schwachstellenscanner von Google einen Pull Request gemacht, der eingepflegt wurde und wohl eine Sicherheitsfunktion deaktiviert. Oder es wurde Druck auf Distributionen ausgeübt, die infizierte Version unter falschem Vorwand einzufügen. Gibt ein paar solcher Dinge, auf die ich bei der Recherche gestoßen bin, die ich im Video nur am Rand oder gar nicht erwähne. Zum einen um den Rahmen nicht zu sprengen, zum anderen weil das alles sehr frisch und dynamisch ist. Ich habe die Aufnahme vom Video mehrfach verschoben, weil mein Artikel auf U-Labs mehrfach von den aktuellen Infos überholt wurde. Hier macht es denke ich Sinn, die weitere Analyse abzuwarten.

Beim Zurücksetzen herrscht auch noch Uneinigkeit. Die von dir erwähnte Diskussion gibt es, weil manche es als sicherer ansehen, präventiv auf eine noch ältere Version zurück zu gehen. Die würde bei Debian aber Abhängigkeiten brechen, weil bei größeren Sprüngen auch z.B. Bugfixe fehlen. Wenn man es 100% sauber machen will, ist das nur ein Workaround für die akute Gefahr und man muss mindestens seit dem Zeitpunkt wo der böswillige Akteur Commit-Rechte bekommen hat (ca. die letzten 2,5 Jahre) einem gründlichen Audit unterziehen. Am besten wäre natürlich die gesamte Codebasis zu prüfen. Dann würde ebenfalls auffallen, ob es andere Schwachstellen gibt, die ggf. gar nicht in dem Zusammenhang stehen und versehentlich eingebaut wurden. Anschließend braucht es eine neue Aufstellung für die zukünftige saubere Pflege mit entsprechenden Ressourcen.

[U-Labs YouTube]

Kommentar von @volkerbehrens:
Danke für das Video, ich hab das schon bei Heise verfolgt aber du hast das nochmal gut zusammengefasst und illustriert.

[U-Labs YouTube]

Kommentar von @robinhood20233:
Danke für das Interessante Video.

Kommentar von @dukenukem9781:
Danke. Gutes Video.

Kommentar von @ricrendrer:
Danke dir für die gute Erklärung!

Kommentar von @meswalive:
Danke für die Infos!

Kommentar von @KurtCHose481:
Vielen Dank für das aufschlussreiche Video!

[U-Labs YouTube]

Kommentar von @christianbottger493:
xkcd 2347

[DMW007]

Danke! Das war das Original und passt so generisch besser, als die Variante mit ffmpeg. Ich dachte mir schon, dass es vom Stil her wohl ein XKCD sein musste, hatte das Originale aber nicht mehr gefunden und wollte bei dem brisanten Thema nicht noch Zeit mit der Suche nach einem Meme verlieren.

[U-Labs YouTube]

Kommentar von @mellinika420:
Zusammenhang mit Windows Updates denkbar? Seit kurzem komm ich nicht mehr auf meinen WD Passport der passwortgeschützt war...

[DMW007]

Dass MS die Bibliothek auch in Windows eingebaut haben könnte und die das über ein Update raus patchen, oder was meinst du mit Windows Updates Zusammenhang?
WD Passport sagt mir nichts. Ich erinnere mich nur an My Drive, da hat sich WD mal hacken lassen und hat den Betroffenen erst empfohlen, die Geräte offline zu nehmen. Später gab es einen Patch und wiederum etwas später hat WD alle Geräte abgeklemmt, die den Patch nicht installiert haben. Könnte auch so was sein. Wenn das irgendwas mit Cloud ist, würde ich es erst mal lokal versuchen um herauszufinden, ob bei denen etwas down ist oder das Problem auf deiner Seite liegt.