Die XZ-Utils-Backdoor in Linux weist auf ein breiteres Sicherheitsproblem in der Lieferkette hin. Wir brauchen mehr als nur Gemeinschaftsgeist, um diese Bedrohungen abzuwehren.

Die Cybersicherheitsbranche wurde erneut in höchste Alarmbereitschaft versetzt, nachdem eine heimtückische Kompromittierung der Software-Lieferkette entdeckt wurde. Die Schwachstelle betrifft die XZ-Utils-Datenkomprimierungsbibliothek, die mit großen Linux-Distributionen ausgeliefert wird. Sie ist unter CVE-2024-3094 registriert und läuft auf eine Backdoor hinaus, die vorsätzlich von einem ehemals vertrauenswürdigen, freiwilligen Systembetreuer eingefügt wurde. Da sie in einigen Fällen bei erfolgreicher Ausnutzung eine Remotecodeausführung (RCE) ermöglicht, stellt sie ein hochkritisches Problem dar, das in etablierten Software-Build-Prozessen ernsthaften Schaden anrichten kann.

Glücklicherweise entdeckte ein anderer Betreuer diese Bedrohung, bevor der bösartige Code in stabile Linux-Releases gelangte. Dennoch stellt dies ein Problem für diejenigen dar, die bereits die Versionen 5.6.0 und 5.6.1 von XZ Utils als Teil von Fedora Rawhide einsetzen. Organisationen sind dringend aufgefordert, diese als Notfallmaßnahme zu patchen. Wäre diese Entdeckung nicht rechtzeitig erfolgt, hätte das Risikoprofil diesen Vorfall zu einem der verheerendsten Lieferkettenangriffe der Geschichte gemacht, der SolarWinds möglicherweise sogar in den Schatten gestellt hätte.

Die Abhängigkeit von freiwilligen Helfern bei der Wartung kritischer Systeme ist hinlänglich dokumentiert, wird jedoch selten thematisiert, bis Vorfälle mit großer Tragweite wie dieser an die Oberfläche gelangen. Während ihre unermüdliche Arbeit für die Pflege von Open-Source-Software unerlässlich ist, unterstreicht dies die Notwendigkeit, den Fokus verstärkt auf Sicherheitskompetenzen und das Bewusstsein auf Entwicklerebene zu legen – ganz zu schweigen von strengeren Zugriffskontrollen für Software-Repositories.

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

Am 29. März veröffentlichte Red Hat eine dringende Sicherheitswarnung, um Benutzer von Fedora Linux 40 und Fedora Rawhide darüber zu informieren, dass die neuesten Versionen der „XZ“-Komprimierungstools und -Bibliotheken bösartigen Code enthalten, der gezielt darauf ausgelegt zu sein scheint, unbefugten Zugriff durch Dritte zu ermöglichen. Wie dieser bösartige Code eingeschleust wurde, wird in Zukunft sicher Gegenstand intensiver Untersuchungen sein. Es handelt sich jedoch um eine ausgeklügelte, geduldige und jahrelange Social-Engineering-Übung des Bedrohungsakteurs, eines pseudonymen Angreifers namens „Jia Tan“. Diese Person verbrachte unzählige Stunden damit, das Vertrauen anderer Betreuer zu gewinnen, leistete über zwei Jahre lang legitime Beiträge zum XZ-Utils-Projekt und zur Community und erlangte schließlich den Status eines „vertrauenswürdigen Betreuers“, nachdem mehrere Sockenpuppen-Accounts das Vertrauen in den freiwilligen Projektinhaber Lasse Collin untergraben hatten:

‍

‍

Dieses ungewöhnliche Szenario ist ein Paradebeispiel dafür, dass selbst hochqualifizierte Fachkräfte Taktiken zum Opfer fallen können, die normalerweise gegen weniger versierte Personen eingesetzt werden. Es zeigt, wie wichtig präzise, rollenbasierte Sicherheitsschulungen sind. Nur der Neugier und dem schnellen Handeln des Microsoft-Softwareentwicklers und PostgreSQL-Betreuers Andres Freund ist es zu verdanken, dass die Backdoor entdeckt und die Versionen zurückgezogen wurden, wodurch ein Angriff verhindert wurde, der einer der verheerendsten Lieferkettenangriffe der jüngeren Geschichte hätte werden können.

Die Backdoor selbst wird offiziell als Schwachstelle mit der höchstmöglichen Kritikalität im NIST-Register geführt. Ursprünglich wurde angenommen, dass sie die Umgehung der SSH-Authentifizierung ermöglicht. Weitere Untersuchungen ergaben jedoch, dass sie eine nicht authentifizierte Remotecodeausführung auf anfälligen Linux-Systemen ermöglichte, darunter Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed und einige Debian-Versionen.

Jia Tan scheint große Anstrengungen unternommen zu haben, um das bösartige Paket zu verschleiern. Wenn es während des Build-Prozesses zur Selbstkonstruktion angeregt wird, behindert es die Authentifizierung in SSHd über systemd. 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 erlangen.

‍

Microsoft und andere haben umfassende Anleitungen zum Scannen von Systemen auf Instanzen des Exploits und zur Minderung seiner Auswirkungen veröffentlicht. Die von der CISA empfohlene Sofortmaßnahme besteht darin, dass betroffene Entwickler und Benutzer XZ Utils auf eine nicht kompromittierte Version, wie XZ Utils 5.4.6 Stable, zurückstufen sollten.

Die Prävention dieser Angriffsart ist unglaublich schwierig – insbesondere bei der Verwendung von Open-Source-Komponenten in Software –, da es kaum Gewissheit und Transparenz über die Sicherheit der Lieferkette gibt. Wir haben bereits versehentliche Fehler in der Software-Lieferkette bekämpft, aber dieses Risiko hat sich auf Sicherheitslücken ausgeweitet, die vorsätzlich mit böswilliger Absicht platziert wurden, um die Open-Source-Sicherheit zu gefährden.

Die meisten Entwickler werden einen Angriff dieser Art nicht stoppen können, es sei denn, sie verfügen über ein ausgeprägtes Sicherheitsbewusstsein, fundiertes Sicherheitswissen und eine gewisse Portion Paranoia. Es ist fast so, als bräuchte man die Denkweise eines Angreifers. Ein Hauptaugenmerk sollte jedoch immer auf Quellcode-Repositories 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-Profis könnten ein Setup mit Sicherheitskontrollen auf Branch-Ebene in Betracht ziehen, bei dem nur sicherheitserfahrene Entwickler Änderungen am finalen Master-Branch vornehmen dürfen.

Freiwillige Betreuer sind Helden, aber es sollte ein ganzes Dorf nötig sein, um sichere Software zu erhalten

Für Außenstehende ist die Vorstellung, dass eine engagierte Gemeinschaft von Freiwilligen in ihrer Freizeit kritische Systeme pflegt, schwer zu begreifen. Doch genau das ist das Wesen der Open-Source-Entwicklung, und sie bleibt ein Bereich kritischer Risiken für Sicherheitsexperten, die die Lieferkette schützen.

Open-Source-Software ist ein wesentlicher Bestandteil des digitalen Ökosystems fast jedes Unternehmens, und vertrauenswürdige Betreuer (von denen die meisten in gutem Glauben handeln) sind in ihrem selbstlosen Streben nach technologischem Fortschritt und Integrität wahrlich heldenhaft. Es ist jedoch absurd, sie isoliert arbeiten zu lassen. In diesen DevSecOps-orientierten Zeiten ist Sicherheit eine gemeinsame Verantwortung, und jeder Entwickler muss mit dem Wissen und den richtigen Werkzeugen ausgestattet sein, um die Sicherheitsprobleme zu bewältigen, denen er im Arbeitsalltag begegnet. Sicherheitsbewusstsein und praktische Fähigkeiten sollten im Softwareentwicklungsprozess nicht verhandelbar sein, und es liegt an den Sicherheitsverantwortlichen, Veränderungen auf Unternehmensebene voranzutreiben.
‍

‍Bauen Sie noch heute eine florierende Sicherheitskultur in Ihrem Unternehmen auf – mit den fundierten Kursen von Secure Code Warrior.