Die XZ Utils-Hintertür in Linux deutet auf ein größeres Sicherheitsproblem in der Lieferkette hin, und wir brauchen mehr als nur Gemeinschaftsgeist, um es in Schach zu halten

Die Cybersicherheitsbranche wurde erneut in höchste Alarmbereitschaft versetzt, nachdem eine heimtückische Kompromittierung der Software-Lieferkette entdeckt worden war. Die Schwachstelle betrifft die Datenkompressionsbibliothek XZ Utils, die mit den wichtigsten Linux-Distributionen ausgeliefert wird. Sie ist unter CVE-2024-3094 registriert und besteht aus einer Hintertür, die von einem einst vertrauenswürdigen freiwilligen Systembetreuer absichtlich eingebaut wurde. Diese Hintertür, die bei erfolgreicher Ausnutzung in einigen Fällen die Ausführung von Remotecode (RCE) ermöglicht, stellt ein hochgradig gefährliches Problem dar, das in etablierten Softwareerstellungsprozessen schwerwiegenden Schaden anrichten kann.

Glücklicherweise entdeckte ein anderer Systembetreuer diese Bedrohung, bevor der bösartige Code in stabile Linux-Versionen eindringen konnte, aber sie stellt immer noch ein Problem für diejenigen dar, die mit der Version 5.6.0. und 5.6.1. von XZ Utils als Teil von Fedora Rawhide begonnen haben, und Unternehmen werden dringend aufgefordert, sie als Priorität für den Notfall zu patchen. Sollte diese Entdeckung nicht rechtzeitig gemacht werden, wäre dies aufgrund des Risikoprofils einer der verheerendsten Angriffe auf die Lieferkette, der vielleicht sogar SolarWinds in den Schatten stellt.

Die Abhängigkeit von freiwilligen Helfern aus der Community bei der Wartung kritischer Systeme ist weithin dokumentiert, wird aber nur selten diskutiert, bis Probleme von großer Tragweite wie dieser Vorfall an die Oberfläche drängen. Während ihre unermüdliche Arbeit für die Wartung von Open-Source-Software unerlässlich ist, unterstreicht dieser Vorfall die Notwendigkeit, den Schwerpunkt auf Sicherheitskenntnisse und -bewusstsein auf der Ebene der Entwickler zu legen, ganz zu schweigen von verstärkten Zugangskontrollen für Software-Repos.

Was ist die XZ Utils-Backdoor und wie wird sie entschärft?

Am 29. März veröffentlichte Red Hat eine dringende Sicherheitswarnung, um die Benutzer von Fedora Linux 40 und Fedora Rawhide darüber zu informieren, dass die neuesten Versionen der "XZ"-Kompressions-Tools und -Bibliotheken bösartigen Code enthalten, der anscheinend speziell entwickelt wurde, um unbefugten Zugriff durch Dritte zu ermöglichen.Wie dieser bösartige Code eingeschleust wurde, wird wahrscheinlich Gegenstand intensiver Untersuchungen in der Zukunft sein, aber es läuft auf eine ausgeklügelte, geduldige, jahrelange Social-Engineering-Übung seitens des Bedrohungsakteurs, eines pseudonymen Angreifers namens "Jia Tan", hinaus. Diese Person verbrachte unzählige Stunden damit, das Vertrauen anderer Betreuer zu gewinnen, indem sie über zwei Jahre lang legitime Beiträge zum XZ Utils-Projekt und zur Community leistete und sich schließlich den Status eines "vertrauenswürdigen Betreuers" verdiente, nachdem mehrere Sockpuppet-Accounts das Vertrauen in den freiwilligen Projekteigentümer Lasse Collin untergraben hatten:

‍

‍

Dieses ungewöhnliche Szenario ist ein Paradebeispiel dafür, dass eine hochtechnische Person dennoch Opfer einer Taktik wird, die normalerweise nur gegen weniger versierte Personen angewandt wird, und zeigt die Notwendigkeit einer präzisen, rollenbasierten Schulung des Sicherheitsbewusstseins. Nur der Wissbegierde und dem schnellen Denken des Microsoft-Software-Ingenieurs und PostgreSQL-Wartungsbeauftragten Andres Freund ist es zu verdanken, dass die Hintertür entdeckt und die Versionen zurückgesetzt wurden, wodurch der möglicherweise verheerendste Angriff auf die Lieferkette in jüngster Zeit verhindert wurde.

Die Backdoor selbst wird in der NIST-Registrierung offiziell als Schwachstelle der höchstmöglichen Schwere eingestuft. Ursprünglich war man davon ausgegangen, dass sie die Umgehung der SSH-Authentifizierung ermöglicht. Weitere Untersuchungen ergaben jedoch, dass sie die unauthentifizierte Remote-Code-Ausführung auf anfälligen Linux-Systemen ermöglicht, darunter Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed und einige Versionen von Debian.

Jia Tan hat sich anscheinend große Mühe gegeben, das Schadpaket zu verschleiern, das, wenn es sich während des Build-Prozesses selbst konstruiert, die Authentifizierung in SSHd über systemd behindert.Wie Red Hat ausführte, könnte diese Störung unter den richtigen Umständen einem Angreifer ermöglichen, die SSHd-Authentifizierung zu umgehen und unbefugten Fernzugriff auf das gesamte System zu erhalten.

‍

Unter anderem hat Microsoft umfassende Anleitungen zum Scannen von Systemen auf Instanzen des Exploits und zur Abschwächung seiner Auswirkungen veröffentlicht. Die CISA empfiehlt als Sofortmaßnahme, dass betroffene Entwickler und Benutzer XZ Utils auf eine nicht kompromittierte Version wie XZ Utils 5.4.6 Stable herabstufen sollten.

Die Verhinderung dieser Angriffsart ist unglaublich schwierig - insbesondere bei der Verwendung von Open-Source-Komponenten in Software -, da es nur sehr wenig Sicherheit und Transparenz in Bezug auf die Sicherheit der Lieferkette gibt. Wir haben bereits zufällige Fehler in der Software-Lieferkette bekämpft, aber dieses Risiko hat sich auf Sicherheitsfehler ausgeweitet, die absichtlich mit dem Ziel eingeschleust wurden, die Open-Source-Sicherheit zu gefährden.

Die meisten Entwickler werden nicht in der Lage sein, einen Angriff dieser Art zu stoppen, es sei denn, sie verfügen über ein ausgeprägtes Sicherheitsbewusstsein, gesundes Sicherheitswissen und eine Prise Paranoia. Es ist fast so, als würde man eine Denkweise eines Bedrohungsakteurs benötigen. Ein Hauptaugenmerk sollte jedoch immer auf Quellcode-Repos liegen, die intern kontrolliert werden (d. h. nicht Open-Source). Diese sollten nur Personen zugänglich sein, die über verifizierte, relevante Sicherheitskenntnisse verfügen. AppSec-Experten könnten eine Einrichtung wie Sicherheitskontrollen auf Zweig-Ebene in Erwägung ziehen, die es nur sicherheitskompetenten Entwicklern erlaubt, Änderungen am endgültigen Master-Zweig vorzunehmen.

Freiwillige Maintainer sind Helden, aber es braucht (sollte) ein Dorf, um sichere Software zu erhalten

Für diejenigen, die nicht aus dem Bereich der Softwaretechnik kommen, ist die Vorstellung, dass eine temperamentvolle Gemeinschaft von Freiwilligen kritische Systeme in ihrer Freizeit akribisch pflegt, schwer zu begreifen, aber das liegt in der Natur der Open-Source-Entwicklung und stellt für Sicherheitsexperten, die die Lieferkette schützen, weiterhin ein kritisches Risiko dar.

Open-Source-Software ist ein unverzichtbarer Bestandteil des digitalen Ökosystems praktisch jedes Unternehmens, und die vertrauenswürdigen Maintainer (von denen die meisten in gutem Glauben handeln) sind in ihrem selbstlosen Streben nach technologischem Fortschritt und Integrität wahrhaft heldenhaft, aber es ist eine Farce, sie bei ihrer Arbeit zu isolieren. In diesen DevSecOps-zentrierten Zeiten ist Sicherheit eine geteilte Verantwortung, und jeder Entwickler muss mit dem Wissen und den passenden Werkzeugen ausgestattet sein, um die Sicherheitsprobleme zu bewältigen, auf die er in seinem Arbeitsalltag wahrscheinlich stoßen wird. Sicherheitsbewusstsein und praktische Fähigkeiten sollten im Softwareentwicklungsprozess nicht verhandelbar sein, und es liegt an den Sicherheitsverantwortlichen, den Wandel auf Unternehmensebene zu beeinflussen.
‍

‍Bauen Sienoch heute eine erfolgreiche Sicherheitskultur in Ihrem Unternehmen auf mit ausführlichen Courses von Secure Code Warrior.