CVE-2024–3094 — auch bekannt als xz-backdoor oder xz-trojan — ist der besorgniserregendste Software-Supply-Chain-Angriff bis dato.
Ein als Jia Tan (Github JiaT75) identifizierter Entwickler nutzte Social Engineering, um in das Open-Source-Projekt Tukaani einzusteigen, und erwarb über die nächsten Jahre das Vertrauen der Community.
Schließlich erlangte Jia den Maintainer-Status für das XZ-Utils-Projekt.
Letztendlich nutzte Jia seinen Status, um eine clevere Verschleierung im Quellcode und in Binärdateien zu implementieren, um eine Hintertür in den XZ-Utils-Versionen 5.6.0 und 5.6.1 zu erstellen. Wäre dies bis zur Integration mit wichtigen Distributionen unentdeckt geblieben, hätten Millionen von Debian- und Red Hat-Releases betroffen sein können.
Eine gut geschriebene Chronologie der Ereignisse ist hier veröffentlicht.
xz ist der fortschrittlichste Angriff auf eine Software-Lieferkette
Angriffe auf die Software-Lieferkette (Software Supply Chain Attacks) beinhalten das Einschleusen von bösartigem Code oder Komponenten auf einer tieferen Ebene als der der Anwendung selbst. Dieser Angriff auf die „Lieferkette“ des Software-Builds trägt dazu bei, einen Vorteil bei der Verteilung zu erlangen, da mehr als ein nachgelagertes Projekt dieselbe Lieferkette nutzen könnte.
In der Vergangenheit zielten Kompromittierungen auf weit verbreitete Anwendungen (z. B. MOVEit – CVE-2023–34362), eine gemeinsam genutzte Komponente (z. B. log4j) oder einen Teil der Build-Umgebung (z. B. SolarWinds, Codecov) ab.
Andererseits beginnt die xz-Hintertür damit, zunächst die Liste der „Maintainer“ (Entwickler) des Projekts zu kompromittieren. Dies geschah, indem eine spezifische Identität für diesen Zweck geschaffen wurde – JiaT75 (keine Aufzeichnungen über die Beiträge dieses Benutzers vor 2021), das Vertrauen des Projektbesitzers im Laufe der Zeit gewonnen wurde und schließlich Social Engineering eingesetzt wurde, um den Projektbesitzer unter Druck zu setzen, diesen Benutzer als Maintainer zu akzeptieren.
Sobald man sich in einer vertrauenswürdigen Rolle befindet, ist es nur menschlich, dass Code-Reviews einer Vertrauensschieflage unterliegen, wodurch selbst eine einfache Verschleierung eine große Wirkung erzielen kann.
Die technische Seite des Öffnens der Hintertür ist ebenfalls clever. Sie umfasst die Verwendung fehlerhafter Binärdateien, um Code-Reviews zu umgehen, das Laden dieser Dateien als Skripte unter Verwendung einfacher, aber aufgeteilter Befehlssequenzen und das Aufteilen des gesamten Hintertür-Eintrags auf viele verschiedene Änderungen. In jedem größeren, sich schnell entwickelnden oder ressourcenarmen Projekt könnten diese bei Code-Reviews von einer Vielzahl von Teams übersehen werden – ganz zu schweigen davon, wenn der Einreichende bereits ein „vertrauenswürdiger“ Maintainer ist.
In der Kombination der oben genannten Punkte können wir uns keine andere Software-Lieferkette vorstellen, die vor dem Exploit so viele Vorbereitungsebenen aufwies.
Könnte jetzt oder bald wieder passieren
Viele Teile der xz-Hintertür wurden aufgrund des vertrauenswürdigen Charakters des Betreuers implementiert, der über Jahre hinweg durch Social Engineering aufgebaut worden war.
Mit über 50 Millionen aktiven Open-Source-Projekten bleibt die Wahrscheinlichkeit hoch, dass „vertrauenswürdige“ Betreuer auf den richtigen Zeitpunkt warten, um eine böswillige Änderung einzuführen, oder diese bereits eingeführt haben, aber noch unentdeckt sind.
Dies unterscheidet sich von log4shell (CVE-2021–44228) oder einer gleichwertigen Schwachstelle, bei der sich die Entwickler bei der ersten Implementierung keinen spezifischen Exploit vorgestellt haben. Daher können Forscher nach der Entdeckung immer noch schnell nachforschen und spezifische Schwachstellen aufdecken.
Im Gegensatz dazu würde ein „vertrauenswürdiger“ Betreuer, der einen bekannten Exploit einführt, dies absichtlich tun und daher versuchen, die Änderungen wann immer möglich zu verschleiern. Aus diesem Grund war die erste Reaktion von Tukaanis Entwickler, Lasse Collin, —
Ich wäre selbst bei älteren Versionen von xz skeptisch, bis das Gegenteil bewiesen ist.
Keines der bekannten Sicherheitswerkzeuge würde xz abfangen
Obwohl Interlynk ein Anbieter von Sicherheitswerkzeugen ist, haben wir keine klaren Beweise dafür gesehen, warum ein bestimmtes Werkzeug oder eine bestimmte Technologie eine solche Änderung im Vorfeld erkennen würde.
OpenSSF deutete zuerst an, dass die OpenSSF-Scorecard für xz utils-Projekte niedrig ausfallen würde, was eine zutreffende Aussage ist.
Allerdings würden spezifische Überprüfungen immer zugunsten des Rufs des Projekts für ein unglaublich nützliches und zuverlässiges Komprimierungswerkzeug ignoriert werden. Ich kann mir nicht vorstellen, welche SAST/DAST-Muster die Herangehensweise als problematisch einstufen würden, insbesondere wenn man bedenkt, dass das betroffene Skript vorab in einen Blob konvertiert wurde. Eine Änderung des Laufzeitverhaltens könnte zwar etwas Rauschen erzeugen, aber als Teil von `sshd` wird dies wahrscheinlich nicht in jeder Situation Verdacht erregen.
Wir verstehen das Bedürfnis der Sicherheitsanbieter-Community, ihre Rolle in diesem Gespräch zu bekräftigen, aber wir glauben, dass die eigentliche Diskussion innerhalb von Open-Source-Communities stattfinden muss und bei Bedarf durch Werkzeuge unterstützt werden kann.
Die Wurzel dieses Problems liegt darin, dass es ein komplexes Problem ist, zu wissen, ob jemand ein "Mandschurei-Kandidat" ist, da die Beweise in seinem Kopf verbleiben.
SBOM wird eine Backdoor nicht erkennen
Interlynk sichert die Software-Lieferkette durch die Automatisierung des SBOM-Flusses. Im Fall der xz-Hintertür würde eine SBOM dabei helfen, zu identifizieren, wann und was sich in der Lieferkette geändert hat, welche Version jede Komponente hat und wie es um die Integrität der Komponenten (einschließlich Testdaten) steht.
Zusätzlich erstellt Interlynk eine Risikobewertung basierend auf der OpenSSF-Scorecard selbst, dem Alter und der Nutzung des Pakets, der Anzahl der Betreuer und einigen anderen Signalen. Die spezifische Version hätte niedrig begonnen (5.4) und wäre im Laufe der Zeit im Wert gestiegen (6.8 bis Ende Mai).
Diese Informationen würden jedoch Richtlinienverstöße auslösen, wenn sie auf Risiko konfiguriert wären, würden aber von den Produktsicherheitsteams angesichts des verdienten Vertrauens in das Projekt wahrscheinlich ignoriert werden.
Wir behaupten daher nicht, dass ein bestehendes SBOM-Programm (oder ein anderes Sicherheitstool) die Integration der xz-Hintertür abgefangen hätte.
Wie bereits angedeutet, ist SBOM kein Allheilmittel für alle Risiken der Software-Lieferkette. Es spielt jedoch eine wesentliche Rolle bei der Gewährleistung der Integrität und der Organisation von Maßnahmen nach der Behebung.
Aber SBOM ist eine Lösung für die Behebung
Stellen Sie sich vor, diese xz-Hintertür wäre Ende Juni statt Ende März entdeckt worden. Bis dahin wäre sie wahrscheinlich in mehrere Linux-Distributionen gelangt und auf Millionen von Servern installiert worden.
Jeder Produktsicherheits- und DevOps-Experte kennt das Gefühl, was als Nächstes kommt – die Beantwortung von Fragen wie:
Sind wir infiziert?
Welche Produkte und Versionen sind infiziert?
Wie können wir sie patchen?
Wie fragen wir unsere Lieferanten, ob sie infiziert sind?
Was ist mit unseren Drittanbietern?
Wie beweisen wir unseren Compliance-Teams, dass dies nachverfolgt wird?
Dies ist nicht das erste Mal, dass diese Situation eintritt, und es wird nicht das letzte Mal sein.
Mit SBOM hätte die gesamte Nachverfolgung jedoch in einer einzigen Schnittstelle erfolgen können.
Alle Assets mit SBOM sind der spezifischen Version der Software und der spezifischen Version der Komponenten zugeordnet.
Ein Upgrade-Plan würde die SBOM ebenfalls aktualisieren und zeigen, wie die Komponentenversion auf die behobene Version umgestellt wird.
Eine begleitende VEX würde es Upstream- und Downstream-Partnern ermöglichen, dies in Echtzeit zu kommunizieren.
Das wird nicht aufhören, aber SBOM ist der Baustein, um die Bemühungen zur Schadensbegrenzung zu koordinieren.
Wir sind hier, um eine gesunde, sichere und unglaubliche Open-Source-Community um uns herum zu unterstützen.
Kontaktieren Sie uns unter hello@interlynk.io für ein Gespräch.