xz-Hintertür: 5 Lektionen
Ingenieurwesen
CVE-2024–3094 — auch bekannt als xz-backdoor oder xz-trojan — ist der bisher besorgniserregendste Angriff auf die Software-Lieferkette.
Ein Entwickler, der als Jia Tan (Github JiaT75) identifiziert wurde, verwendete Social Engineering, um in das Open-Source-Projekt Tukaani einzutreten und gewann über die nächsten Jahre das Vertrauen der Community.
Jia erhielt schließlich den Wartestatus für das XZ-Utils Projekt.
Schließlich nutzte Jia seinen Status, um geschickte Verschleierung im Quellcode und in Binärdateien einzuführen, um eine Hintertür in den Versionen 5.6.0 und 5.6.1 von XZ-Utils zu schaffen. Hätte dies bis zur Integration mit den Hauptdistributionen unentdeckt geblieben, könnten Millionen von Debian- und Red Hat-Versionen betroffen gewesen sein.
Eine gut geschriebene Zeitachse der Ereignisse ist hier veröffentlicht.
xz ist der fortschrittlichste Software-Lieferkettenangriff
Angriffe auf die Software-Lieferkette beinhalten das Einspeisen von bösartigem Code oder Komponenten auf einer Ebene, die tiefer als die Anwendung selbst liegt. Dieser Angriff auf die „Lieferkette“ des Software-Baus hilft, einen Vorteil bei der Verteilung zu gewinnen, da mehr als ein nachgelagertes Projekt dieselbe Lieferkette nutzen könnte.
In der Vergangenheit wurden Kompromisse häufig genutzte Anwendungen ins Visier genommen (z. B. MOVEit — CVE-2023–34362), eine gemeinsam genutzte Komponente (z. B. log4j) oder einen Teil der gebauten Umgebung (z. B. SolarWinds, Codecov).
Andererseits beginnt die xz-backdoor damit, zunächst die „Pflege“-Liste des Projekts zu kompromittieren. Dies wurde erreicht, indem eine spezifische Identität zu diesem Zweck geschaffen wurde — JiaT75 (keine Aufzeichnungen über die Beiträge dieses Nutzers vor 2021), durch Vertrauen verdienen vom Projektbesitzer über die Zeit und schließlich soziale Ingenieurkunst anwenden, um den Projektbesitzer unter Druck zu setzen, diesen Nutzer als Pfleger zu akzeptieren.
Einmal in einer vertrauenswürdigen Rolle ist es nur menschlich, dass Code-Reviews Vertrauensvorurteile haben und selbst einfache Obfuskierungen weitreichende Auswirkungen haben können.
Die technische Seite des Öffnens der Hintertür ist ebenso clever. Sie umfasst die Verwendung beschädigter Binärdateien, um Code-Reviews zu umgehen, das Laden dieser Dateien als Skripte mit einfachen, aber aufgeteilten Befehlssequenzen und das Aufteilen des gesamten Hintertür-Zugangs über viele verschiedene Änderungen. In jedem größeren, schnelllebigen oder ressourcenschwachen Projekt könnten diese während der Code-Reviews von einer Vielzahl von Teams übersehen werden — ganz zu schweigen davon, wenn der Einreicher bereits ein ‚vertrauenswürdiger‘ Pfleger ist.
Wenn man das Obige kombiniert, können wir an keine andere Software-Lieferkette denken, die so viele Ebenen der Vorbereitung vor dem Ausnutzen hat.
Könnte jetzt oder bald wieder passieren
Viele Teile des xz-backdoor wurden aufgrund der vertrauenswürdigen Natur des Maintainters implementiert, die über die Jahre sozial angelegt wurde.
Mit über 50 Millionen aktiven Open-Source-Projekten bleibt die Wahrscheinlichkeit hoch, dass 'vertrauenswürdige' Maintainer auf den richtigen Zeitpunkt warten, um eine bösartige Änderung einzuführen oder sie bereits eingeführt haben, aber unentdeckt bleiben.
Dies unterscheidet sich von log4shell (CVE-2021–44228) oder gleichwertigen Schwachstellen, bei denen die Entwickler bei der ersten Implementierung nicht an einen spezifischen Exploit dachten. Daher können Forscher nach der Entdeckung immer noch schnell untersuchen und spezifische Schwachstellen aufdecken.
Im Gegensatz dazu wäre ein 'vertrauenswürdiger' Maintainer, der einen bekannten Exploit einführt, absichtlich in seinem Verhalten und würde daher versuchen, die Änderungen, wann immer möglich, zu verschleiern. Aus diesem Grund war die erste Reaktion von Tukaanis Builder, Lasse Collin —
Ich wäre misstrauisch gegenüber sogar älteren Versionen von xz, bis das Gegenteil bewiesen ist.
Keines der bekannten Sicherheitswerkzeuge würde xz erfassen.
Während 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 Voraus bemerken würde.
OpenSSF hat zuerst vorgeschlagen, dass das OpenSSF Scorecard für xz Utils-Projekte niedrig bewertet werden würde, was eine wahre Aussage ist.
Allerdings würden spezifische Überprüfungen immer zugunsten des Rufs von Projekten für äußerst nützliche und zuverlässige Kompressionswerkzeuge ignoriert werden. Ich kann mir nicht vorstellen, welche SAST/DAST-Muster mit dem Ansatz problematisch sein werden, insbesondere wenn man bedenkt, dass das störende Skript vorab in ein Blob umgewandelt wurde. Eine Änderung des Laufzeitverhaltens könnte etwas Lärm erzeugen, aber Teil von `sshd` zu sein, wird wahrscheinlich nicht in jeder Situation Verdacht erregen.
Wir verstehen das Bedürfnis der Sicherheitsanbietergemeinschaft, ihre Rollen in diesem Gespräch zu bekräftigen, aber wir glauben, dass das wirkliche Gespräch innerhalb der Open-Source-Communities stattfinden muss und bei Bedarf durch Werkzeuge unterstützt werden kann.
Die Wurzel dieser Herausforderung besteht darin, dass es ein komplexes Problem ist, zu wissen, ob jemand ein Manchurian Candidate ist, da die Beweise in seinem Kopf bleiben.
SBOM wird ein Hintertürchen nicht erkennen
Interlynk sichert die Software-Lieferkette, indem es den SBOM-Fluss automatisiert. Im xz-backdoor würde ein SBOM helfen, zu identifizieren, wann und was sich in der Lieferkette geändert hat, welche Version jede Komponente hat und die Integrität der Komponenten (einschließlich Testdaten).
Darüber hinaus erstellt Interlynk einen Risikoscore auf der Grundlage des OpenSSF Scorecards selbst, mit dem Alter und der Nutzung des Pakets, der Anzahl der Wartenden und wenigen anderen Signalen. Die spezifische Version hätte niedrig begonnen (5.4) und im Laufe der Zeit an Wert gewonnen (6.8 bis Ende Mai).
Diese Informationen würden jedoch Richtlinienverstöße auslösen, wenn sie um Risiken konfiguriert sind, würden aber wahrscheinlich von den Produktsicherheitsteams ignoriert, angesichts des verdienten Vertrauens des Projekts.
Daher behaupten wir nicht, dass ein bestehendes SBOM-Programm (oder ein anderes Sicherheitswerkzeug) die Integration xz-backdoor erkannt hätte.
Wie angegeben, ist SBOM kein Allheilmittel für alle Risiken in der Software-Lieferkette. Es spielt jedoch eine wesentliche Rolle bei der Gewährleistung der Integrität und der Organisation der Nachbesserungsbemühungen.
Aber SBOM ist eine Lösung zur Behebung
Stellen Sie sich vor, dass dieser xz-backdoor Ende Juni entdeckt worden wäre, anstatt Ende März. Bis dahin wäre er wahrscheinlich in mehrere Linux-Distributionen eingedrungen und auf Millionen von Servern installiert worden.
Alle Produktsicherheits- und DevOps-Teams kennen das Gefühl, was als nächstes kommt – Fragen zu beantworten wie:
Sind wir infiziert?
Welche Produkte und Versionen sind infiziert?
Wie patchen wir sie?
Wie fragen wir unsere Lieferanten, ob sie infiziert sind?
Was ist mit unseren Anbietern?
Wie beweisen wir unseren Compliance-Teams, dass dies verfolgt wird?
Dies ist nicht das erste Mal, dass diese Übung stattgefunden hat, und es wird nicht das letzte Mal sein.
Allerdings hätte mit SBOM die gesamte Verfolgung in einer Benutzeroberfläche erfolgen können.
Alle Vermögenswerte mit SBOM sind mit der spezifischen Version der Software und der spezifischen Version der Komponenten verknüpft.
Ein Upgrade-Plan würde das SBOM mit ihr aktualisieren und die Komponentenversion, die auf die feste Version wechselt, anzeigen.
Ein begleitendes VEX würde es ermöglichen, dass upstream- und downstream-Partner dies in Echtzeit kommunizieren.
Das wird nicht aufhören, aber SBOM ist der Baustein zur Koordination von Maßnahmen zur Minderung dessen.
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.