XZ Utils: Open Source durch Social Engineering infiltrieren
Stellen Sie sich vor, Sie wachen auf und stellen fest, dass ein scheinbar harmloses Open-Source-Tool, das tief in Ihre Systeme integriert ist, sich heimlich in eine Bedrohung verwandelt hat.
XZ Utils: Die stille Säule
XZ Utils ist vielleicht nicht allgemein bekannt, aber allgegenwärtig: SSH-Sitzungen, Linux-Distributionen (96,3 % der Top 1.000.000 Webserver laufen unter Linux), Paketmanager und Systembibliotheken sind stark auf dieses hocheffiziente Kompressionstool angewiesen, vergleichbar mit zip.
Danke, dass Sie ThreatLink lesen! Abonnieren Sie kostenlos, um neue Beiträge zu erhalten und meine Arbeit zu unterstützen.Abonniert
Diese weite Verbreitung machte XZ Utils zu einem idealen Ziel. Die Angreifer erkannten, dass eine Kompromittierung von XZ Utils potenziell die Kompromittierung Tausender Systeme, Anwendungen und Drittanbieter bedeuten konnte.
Sie können dieses Tool ganz einfach selbst in Ihrem Terminal testen, zum Beispiel, indem Sie eine beliebige Datei komprimieren oder dekomprimieren:
Andres Freund
Im März 2024 bemerkte der Microsoft-Ingenieur Andres Freund eine ungewöhnliche Latenz (500 Millisekunden) bei SSH-Verbindungen auf einem Debian-Rechner.
Dieses scheinbar unbedeutende Detail führte ihn zur Entdeckung von Schadcode. Solch subtile Anomalien zu erkennen, liegt nicht jedem.
Den Hack verstehen
Der Angriff geht auf einen Mitwirkenden namens „Jia Tan“ zurück, der sich ab 2021 schrittweise im Projekt XZ Utils engagierte. Durch regelmäßige, wertvolle Beiträge gewann Jia das Vertrauen der Community.
Bis 2023 hatte er Commit-Rechte erlangt und die Versionen 5.6.0 und 5.6.1 von XZ Utils veröffentlicht, die jeweils eine akribisch versteckte Backdoor enthielten.
Die Veröffentlichung dieser Versionen bedeutete, dass alle von XZ Utils abhängigen Tools – die große Mehrheit – über eine neue „stabile“ Version informiert und zum Upgrade von den Vorgängerversionen angeregt wurden.
Vereinfacht gesagt passiert Folgendes: Beim Schreiben von Code erstellen wir normalerweise Tests, um zu prüfen, ob sich die Anwendung wie erwartet verhält. In diesem Fall (XZ) werden dafür oft absichtlich beschädigte Testdateien verwendet, um zu sehen, wie die Bibliothek reagiert.
Um angesichts des offenen Quellcodes nicht entdeckt zu werden, entwickelte der Angreifer einen mehrstufigen Ansatz, der sich vereinfacht so darstellen lässt:
Schadcode wurde in einer scheinbar beschädigten Testdatei namens
bad-3-corrupt_lzma2.xzversteckt.Beim Kompilieren „reparierte“ ein Makro (
build-to-host) diese beschädigte Datei.Das Skript extrahierte und entschlüsselte dann eine weitere Datei (
good-large_compressed.lzma) und bettete sie in die final kompilierte Binärdatei ein, wodurch die Backdoor aktiviert wurde.
Alles geschah vor aller Augen, als Open Source:
Natürlich wurde die Schwachstelle mit dem maximalen Schweregrad von 10/10 bewertet.
Das Ende des Artikels lesen Sie direkt auf ThreatLink