Die XZ Utils-Backdoor unter Linux weist auf ein umfassenderes Sicherheitsproblem in der Lieferkette hin, dessen Behebung mehr als nur Gemeinschaftsgeist erfordert.
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.
In der XZ Utils-Datenkomprimierungsbibliothek, die in den wichtigsten Linux-Distributionen verwendet wird, wurde eine schwerwiegende Sicherheitslücke (CVE-2024-3094) entdeckt, die durch eine von Angreifern eingeführte Hintertür verursacht wurde. Dieses Problem mit hoher Schweregradstufe kann zur Remote-Ausführung von Code führen und stellt ein erhebliches Risiko für den Software-Build-Prozess dar.Der Fehler betrifft die frühen Versionen (5.6.0 und 5.6.1) von XZ Utils in Fedora Rawhide, sodass Unternehmen dringend aufgefordert sind, einen Patch zu implementieren. Dieser Vorfall unterstreicht die wichtige Rolle von Freiwilligen aus der Community bei der Pflege von Open-Source-Software und macht deutlich, dass Sicherheitsmaßnahmen und Zugriffskontrollen im Softwareentwicklungszyklus verstärkt werden müssen.
Vorstandsvorsitzender, Chairman und Mitbegründer
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約
Vorstandsvorsitzender, Chairman und Mitbegründer
Pieter Danhieux ist ein weltweit anerkannter Sicherheitsexperte mit mehr als 12 Jahren Erfahrung als Sicherheitsberater und 8 Jahren als Principal Instructor für SANS, wo er offensive Techniken lehrt, wie man Organisationen, Systeme und Einzelpersonen auf Sicherheitsschwächen hin untersucht und bewertet. Im Jahr 2016 wurde er als einer der "Coolest Tech People in Australia" (Business Insider) ausgezeichnet, erhielt die Auszeichnung "Cyber Security Professional of the Year" (AISA - Australian Information Security Association) und besitzt die Zertifizierungen GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
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.
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.
Klicken Sie auf den folgenden Link, um die PDF-Datei dieser Ressource herunterzuladen.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenデモを予約
Vorstandsvorsitzender, Chairman und Mitbegründer
Pieter Danhieux ist ein weltweit anerkannter Sicherheitsexperte mit mehr als 12 Jahren Erfahrung als Sicherheitsberater und 8 Jahren als Principal Instructor für SANS, wo er offensive Techniken lehrt, wie man Organisationen, Systeme und Einzelpersonen auf Sicherheitsschwächen hin untersucht und bewertet. Im Jahr 2016 wurde er als einer der "Coolest Tech People in Australia" (Business Insider) ausgezeichnet, erhielt die Auszeichnung "Cyber Security Professional of the Year" (AISA - Australian Information Security Association) und besitzt die Zertifizierungen GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
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.
目次
Vorstandsvorsitzender, Chairman und Mitbegründer
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約[ダウンロード]Ressourcen für den Einstieg
Themen und Inhalte der Secure-Code-Schulung
Unsere branchenführenden Inhalte werden unter Berücksichtigung der Aufgaben unserer Kunden ständig weiterentwickelt, um mit der sich ständig verändernden Softwareentwicklungsumgebung Schritt zu halten. Sie decken alle Themen von KI bis hin zu XQuery-Injection ab und sind für verschiedene Aufgabenbereiche konzipiert, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätssicherungsfachleuten. Werfen Sie einen Blick auf die Inhalte unseres Content-Katalogs, sortiert nach Themen und Aufgabenbereichen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
「Cybermon 2025 Beat the Boss」 kann nun das ganze Jahr über bei SCW gespielt werden. Führen Sie anspruchsvolle AI/LLM-Sicherheitsherausforderungen ein, um die sichere AI-Entwicklung in großem Maßstab zu stärken.
Erläuterung des Cyber-Resilience-Gesetzes: Bedeutung für die Entwicklung sicherer Software
Erfahren Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams auf Secure-by-Design-Praktiken, Schwachstellenprävention und die Kompetenzentwicklung von Entwicklern vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 ist der erste Teil der zehnteiligen Reihe „Enablers of Success“ und zeigt, wie sichere Programmierung mit geschäftlichen Ergebnissen wie Risikominderung und Geschwindigkeit verknüpft werden kann, um Programme langfristig zu optimieren.
