Die XZ Utils-Hintertür in Linux weist auf ein umfassenderes Sicherheitsproblem in der Lieferkette hin, und wir brauchen mehr als Gemeinschaftsgeist, um es in Schach zu halten

Nach der Entdeckung eines heimtückischen Kompromisses in der Software-Lieferkette wurde die Cybersicherheitsbranche erneut in höchste Alarmbereitschaft versetzt. Die Sicherheitslücke, die die XZ Utils-Datenkomprimierungsbibliothek betrifft, die im Lieferumfang der wichtigsten Linux-Distributionen enthalten ist, ist unter CVE-2024-3094 protokolliert und läuft auf eine Hintertür hinaus, die bewusst von einem einst vertrauenswürdigen freiwilligen Systembetreuer eingefügt wurde. Sie ermöglicht in einigen Fällen die Ausführung von Remotecode (RCE), wenn sie erfolgreich ausgenutzt wird, und stellt ein schwerwiegendes Problem dar, das in etablierten Software-Build-Prozessen schweren Schaden anrichten kann.

Zum Glück entdeckte ein anderer Betreuer diese Bedrohung, bevor der bösartige Code in stabile Linux-Versionen gelangte, aber sie stellt immer noch ein Problem für diejenigen dar, die mit den Versionen 5.6.0. und 5.6.1 von XZ Utils als Teil von Fedora Rawhide begonnen haben, und Organisationen sind zum Patchen gedrängt es hat Priorität auf Notfallebene. Wenn diese Entdeckung nicht rechtzeitig gemacht würde, wäre es aufgrund des Risikoprofils einer der verheerendsten Supply-Chain-Angriffe aller Zeiten, der SolarWinds vielleicht sogar in den Schatten stellen würde.

Die Abhängigkeit von Freiwilligen aus der Gemeinde bei der Wartung kritischer Systeme ist umfassend dokumentiert, wird jedoch nur selten erörtert, bis schwerwiegende Probleme wie dieser Vorfall an die Oberfläche kommen. Ihre unermüdliche Arbeit ist zwar für die Wartung von Open-Source-Software unerlässlich, dies unterstreicht jedoch die Notwendigkeit, den Sicherheitskompetenzen und dem Sicherheitsbewusstsein auf Entwicklerebene große Bedeutung beizumessen, ganz zu schweigen von verschärften Zugriffskontrollen rund um Software-Repositorys.

Was ist die XZ Utils-Hintertür und wie wird sie entschärft?

Am 29. März, Red Hat hat eine dringende Sicherheitswarnung veröffentlicht um Benutzer von Fedora Linux 4.0 und Fedora Rawhide darüber zu informieren, dass die neuesten Versionen der „XZ“ -Komprimierungstools und -Bibliotheken bösartigen Code enthalten, der offenbar speziell entwickelt wurde, um unbefugten Zugriff durch Dritte zu erleichtern. Wie dieser bösartige Code eingeschleust wurde, wird in Zukunft wahrscheinlich Gegenstand intensiver Studien sein, aber es handelt sich 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 der Community und erlangte schließlich den Status eines „vertrauenswürdigen Betreuers“, nachdem mehrere Sockpuppet-Accounts das Vertrauen in den ehrenamtlichen Projekteigentümer Lasse Collin untergraben hatten:

‍

‍

Dieses ungewöhnliche Szenario ist ein Paradebeispiel dafür, dass eine hochtechnische Person immer noch Opfer von Taktiken wird, die normalerweise nur gegen weniger versierte Personen eingesetzt werden, und zeigt, dass präzise, rollenbasierte Schulungen zum Sicherheitsbewusstsein erforderlich sind. Es war nur der Neugier und dem schnellen Denken des Microsoft-Softwareingenieurs und PostgreSQL-Betreuers zu verdanken. Andres Freund, dass die Hintertür entdeckt und Versionen zurückgesetzt wurden, wodurch der möglicherweise verheerendste Supply-Chain-Angriff der letzten Zeit gestoppt wurde.

Die Hintertür selbst wird offiziell als Sicherheitslücke mit dem höchstmöglichen Schweregrad eingestuft in Das NIST-Register. Ursprünglich wurde angenommen, dass es die Umgehung der SSH-Authentifizierung ermöglicht, aber weitere Untersuchungen ergaben, dass es die unauthentifizierte Remotecodeausführung auf anfälligen Linux-Systemen ermöglichte, darunter Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed und einigen Versionen von Debian.

Jia Tan scheint große Anstrengungen unternommen zu haben, um das bösartige Paket zu verschleiern. Wenn es während des Build-Prozesses dazu veranlasst wird, sich selbst zu erstellen, behindert es die Authentifizierung in SSHD über systemd. Wie Roter Hut detailliert, unter den richtigen Umständen könnte diese Störung es einem Angreifer ermöglichen, die SSHD-Authentifizierung zu durchbrechen und sich unbefugten Fernzugriff auf das gesamte System zu verschaffen.

‍

Microsoft hat unter anderem veröffentlichte umfassende Leitlinien zum Scannen von Systemen nach Exploit-Fällen und zur Abschwächung seiner Auswirkungen sowie zu den empfohlenen Sofortmaßnahmen von CISA ist, dass betroffene Entwickler und Benutzer XZ Utils auf eine kompromisslose Version herunterstufen sollten, wie XZ Utils 5.4.6 Stable.

Es ist unglaublich schwierig, diese Art von Angriffen zu verhindern — insbesondere bei der Verwendung von Open-Source-Komponenten in Software —, da die Sicherheit der Lieferkette kaum gewährleistet und transparent ist. Wir haben bereits versehentliche Fehler in der Software-Lieferkette bekämpft, aber dieses Risiko hat sich auf Sicherheitslücken erhöht, die bewusst böswillig eingepflanzt wurden, um die Open-Source-Sicherheit zu gefährden.

Die meisten Entwickler werden einen Angriff dieser Art nur stoppen können, wenn sie über ein ausgeprägtes Sicherheitsbewusstsein, gesunde Sicherheitskenntnisse und eine Prise Paranoia verfügen. Es geht fast darum, dass die Denkweise eines Bedrohungsakteurs erforderlich ist. Eine Hauptüberlegung sollte sich jedoch immer auf Quellcode-Repositorys konzentrieren, die sind intern gesteuert (d. h. nicht Open Source). Diese sollten nur Personen zugänglich sein, die über nachgewiesene, relevante Sicherheitskenntnisse verfügen. AppSec-Experten könnten eine Einrichtung wie Sicherheitskontrollen auf Filialebene in Betracht ziehen, sodass nur sicherheitserfahrene Entwickler Änderungen am endgültigen Master-Branch vornehmen können.

Freiwillige Betreuer sind Helden, aber es (sollte) ein ganzes Dorf brauchen, um sichere Software aufrechtzuerhalten

Für diejenigen, die nicht im Bereich der Softwaretechnik tätig sind, ist die Vorstellung, dass eine temperamentvolle Gemeinschaft von Freiwilligen kritische Systeme in ihrer eigenen Zeit sorgfältig wartet, ein schwer zu verstehendes Konzept, aber das liegt in der Natur der Open-Source-Entwicklung, und es ist nach wie vor ein Bereich, in dem Sicherheitsexperten, die die Lieferkette schützen, ein kritisches Risiko darstellt.

Open-Source-Software ist ein wichtiger Bestandteil des digitalen Ökosystems praktisch jedes Unternehmens, und vertrauenswürdige Betreuer (von denen die meisten in gutem Glauben handeln) sind wirklich heldenhaft in ihrem selbstlosen Streben nach technischem Fortschritt und Integrität, aber es ist eine Farce, sie isoliert liefern zu lassen. In diesen Zeiten, in denen DevSecops im Mittelpunkt stehen, ist Sicherheit eine gemeinsame Verantwortung, und jeder Entwickler muss mit dem Wissen und den richtigen Tools ausgestattet sein, um die Sicherheitsprobleme zu bewältigen, denen er in seinem Arbeitsalltag wahrscheinlich begegnen wird. Sicherheitsbewusstsein und praktische Fähigkeiten sollten im Softwareentwicklungsprozess nicht verhandelbar sein, und es liegt an den Sicherheitsverantwortlichen, Veränderungen auf Unternehmensebene zu beeinflussen.
‍

‍Bauen Sie noch heute eine blühende Sicherheitskultur in Ihrem Unternehmen auf mit detaillierten Lehrveranstaltungen von Secure Code Warrior.