xz-Attacke: Hintertür enträtselt, weitere Details zu betroffenen Distros

Inhaltsverzeichnis

Nach der Entdeckung einer Hintertür in den xz-Tools, die in vielen Open-Source-Plattformen enthalten sind, wurden am heutigen Karsamstag weitere Details bekannt. So handelt es sich bei der Backdoor um eine Möglichkeit für die Angreifer, eigenen Code auf den Zielsystemen auszuführen, den sie zuvor geschickt versteckt haben. Einen Netzwerk-Scanner zur Erkennung der Backdoor zu schreiben, scheint derzeit nicht möglich.

Clevere Hintertür führt Schadcode aus

In einem Diskussionsfaden auf der Social-Media-Plattform BlueSky analysiert der Sicherheitsexperte und Kryptograf Filippo Valsorda die Hintertür. Diese ist bemerkenswert einfallsreich entworfen und nutzt einen RSA-Schlüssel als Transportmedium für den Schadcode. Beim Aufbau einer neuen SSH-Verbindung zu einem Server mit trojanisierten xz-Bibliotheken wird jener bereits beim Schlüsselaustausch übertragen, auf Plausibilität überprüft und schließlich entschlüsselt und ausgeführt.

Somit können zwar Angreifer ohne Zugangsdaten Code ausführen, einen Netzwerk-Scanner wie für andere Sicherheitslücken können Sicherheitsexperten aber wohl nicht schreiben. Ihnen fehlt schlicht das Schlüsselmaterial der Backdoor-Autoren: Sobald die Hintertür eine ungültige Signatur erkennt, stellt sie ihre Arbeit ein und setzt die Ausführung von normalem OpenSSH-Code fort. Die Überprüfung auf Hintertüren kann also nur lokal erfolgen. Auch eine Yara-Regel für die Signatur der Backdoor steht mittlerweile bereit.

Projektübernahme mit Psychotricks

Der Angriff war offenbar von langer Hand geplant. Der Angreifer "Jia Tan" erstellte sein Github-Konto im Jahr 2021 und konzentrierte sich ab 2022 auf das xz-Projekt. Er hat mithilfe mehrerer Komplizen oder Fake-Accounts, die psychologischen Druck auf den Hauptentwickler aufgebaut haben, nicht nur Kontrolle über das Projekt erlangt, sondern auch Linux-Distributionen dazu gedrängt, die von ihm präparierten Versionen der Pakete schnellstmöglich in ihre Systeme zu übernehmen. So sei er bei einem Fedora-Autor vorstellig geworden und habe diesen aufgrund "toller neuer Features" überzeugen wollen, xz 5.6.x in die rpm-basierte Distribution aufzunehmen.

Ein Komplize mit dem Pseudonym "Hans Jansen" ging derweil beim Debian-Projekt Klinken putzen und warb um Aktualisierung des Pakets. Sein Vorwand: Die neue Version behebe ein Problem mit dem Programmier-Werkzeugkasten Valgrind – das jedoch erst durch den Einbau der Hintertür aufgetreten war. In Kommentaren lobten Pseudonyme wie "krygorin4545" und "misoeater91" den angeblichen Bugfix, vermutlich Fake-Accounts zur Stimmungsmache. Das Debian-Projekt entschied sich, die mit Hintertür versehene xz-Version in die instabile Version "Sid" aufzunehmen.

Betroffene Distributionen

Bereits seit Donnerstagabend gibt es aktualisierte Pakete für OpenSUSE "Tumbleweed" – diese Rolling-Release-Version von OpenSUSE ohne feste Versionen enthielt ebenfalls ein löchriges xz-Paket. In stabile Debian- oder Ubuntu-Versionen hat die Hintertür es nicht geschafft, wohl aber in Debian "testing" und "unstable". Andere betroffene Linux-Varianten hatten wir bereits in unserer ersten Meldung genannt.

Der macOS-Paketmanager Homebrew hingegen ist nicht direkt betroffen. Zwar enthält Homebrew eine mit Hintertür versehene Version von liblzma, die Hintertür wird jedoch nur bei deb- und rpm-basierten Distributionen als Teil des Paket-Erstellungsprozesses scharf geschaltet, schreibt einer der Entwickler auf Github.

Außerdem muss liblzma von OpenSSH geladen werden, obwohl diese Software die Bibliothek eigentlich nicht nutzt. Allerdings kann die Hintertür über indirekte Abhängigkeiten doch in OpenSSH landen. Beispielsweise patchen viele Distributionen OpenSSH, damit es systemd-notify unterstützt. Die systemd-Bibliothek libsystemd nutzt wiederum liblzma, sodass über diese Indirektion der Schadcode geladen wird.

Damit die Hintertür dann auch ausgeführt wird, müssen neben der gültigen Signatur noch weitere Vorbedingungen erfüllt sein:

1. Die Umgebungsvariable TERM – üblicherweise Kennzeichen für eine interaktive Terminal-Sitzung – darf nicht gesetzt sein,
2. Der Zielprozess muss /usr/sbin/sshd heißen,
3. weder die Umgebungsvariablen LD_DEBUG noch LD_PROFILE sind gesetzt,
4. eine Sprache ist mittels der Umgebungsvariable LANG festgelegt
5. keine Debugging-Session mittels rr oder gdb findet statt.

Trifft eine der Vorbedingungen nicht zu, verweigert die Hintertür den Dienst.

Lücken veröffentlichen: Ja oder nein?

Auf der Mailingliste oss-security (auf der die Hintertür durch ihren Entdecker entlarvt worden war) entspann sich unterdessen eine lebhafte Diskussion hochrangiger Security-Experten um das Für und Wider von Embargos auf Sicherheitslücken. Während Marc Deslauriers von Canonical die bei 0days üblichen Kommunikationssperren verteidigte, sprach sich Tavis Ormandy von Google für radikale Offenheit aus: Von Deslauriers leicht provokant gefragt, ob er die unverzügliche Veröffentlichung von Chrome-Sicherheitslücken befürworte, schrieb Ormandy: "Ja! Wenn jemand Wissen über irgendeine Software mit Backdoors oder [..] einem aktiven Zero-Day-Exploit hat, rate ich demjenigen – bitte –, dieses Wissen zu veröffentlichen."

Der Entdecker, Andres Freund, gab zu Protokoll, dass er die Verschwörung nur aufgrund "einer Reihe von Zufällen" entdeckt habe: Er beobachtete einige SSH-Prozesse mit überraschend hohem Ressourcenverbrauch, erinnerte sich des angeblichen Valgrind-Fehlers und zählte eins und eins zusammen.

Auch der Projektleiter des xz-Projekts, Lasse Collin, hat sich mittlerweile aus einer selbst verordneten Internet-Auszeit zu Wort gemeldet. Der Entwickler hat einige der durch Jia Tan gemachten Änderungen an der Projekt-Infrastruktur zurückgenommen und klargestellt, dass nur er selber Zugriff auf die Projektdaten unterhalb der Domain "tukaani.org" habe. Der böswillige Tan hatte durch die Übertragung der Git-Repositories zu Github größere Kontrolle über das Projekt an sich gerissen. Die Konten des Projekts und der Entwickler Tan und Collin bei Github sind derzeit gesperrt.

Rufe nach mehr Unterstützung für Open-Source-Projekte werden nun lauter. Der Entwickler der Python-Netzwerkbibliothek Twisted schrieb dazu auf Mastodon, er hoffe wirklich, die übliche Praxis, sein "gesamtes gottverdammtes Produkt auf den Schultern einer überarbeiteten Person ruhen zu lassen, die langsam einen Nervenzusammenbruch bekäme, ohne diese finanziell oder strukturell irgendwie zu unterstützen" würde nun in der gesamten Branche auf den Prüfstand gestellt.

Wer Hans Jansen, Jia Tan und ihre Komplizen sind, ist noch ungewiss. Die Komplexität und Rafinesse des Angriffs deutet, so die Meinung mancher Experten, auf einen staatlich gelenkten Angriff hin. Details liegen jedoch noch im Dunkeln – die Jagd nach den Tätern hat begonnen.

(cku)