Die Hintertür von XZ Utils unter Linux weist auf ein umfassenderes 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 in der Software-Lieferkette entdeckt wurde. Die Schwachstelle, die die Datenkomprimierungsbibliothek XZ Utils betrifft, die in den wichtigsten Linux-Distributionen enthalten ist, ist unter dem Code CVE-2024-3094 registriert und lässt sich auf eine Hintertür zurückführen, die absichtlich von einem freiwilligen Systemadministrator eingebaut wurde, der ihr einst vertraute. Die Ermöglichung der Remote-Code-Ausführung (RCE) in einigen Fällen, wenn sie richtig ausgenutzt wird, stellt ein sehr ernstes Problem dar, da sie schwere Schäden in den etablierten Softwareentwicklungsprozessen verursachen kann.
Glücklicherweise entdeckte ein anderer Maintainer diese Bedrohung, bevor der bösartige Code in die stabilen Versionen von Linux gelangte, aber es bleibt ein Problem für diejenigen, die mit der Ausführung der Versionen 5.6.0 und 5.6.1 von XZ Utils als Teil von Fedora Rawhide begonnen haben, und Organisationen werden aufgefordert, das Problem als Notfallpriorität zu beheben. Wäre diese Entdeckung nicht rechtzeitig gemacht worden, hätte das Risikoprofil dies zu einem der verheerendsten Angriffe auf die Lieferkette in der Geschichte gemacht, vielleicht sogar noch schlimmer als SolarWinds.
Die Abhängigkeit von Freiwilligen aus der Community zur Wartung kritischer Systeme ist weithin dokumentiert, wird jedoch selten diskutiert, bis Themen mit großer Tragweite wie dieser Vorfall ans Licht kommen. Obwohl ihre unermüdliche Arbeit für die Wartung von Open-Source-Software unerlässlich ist, zeigt dies doch, dass Entwickler besonders auf Sicherheitsfähigkeiten und -bewusstsein achten müssen, ganz zu schweigen von der Verstärkung der Zugriffskontrollen auf Software-Repositorys.
Was ist die Hintertür von XZ Utils und wie kann man sie entschärfen?
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 Bibliotheken und Komprimierungstools „XZ” bösartigen Code enthalten, der offenbar speziell dafür entwickelt wurde, unbefugten Zugriff durch Dritte zu ermöglichen. Die Art und Weise, wie dieser bösartige Code eingeschleust wurde, wird wahrscheinlich in Zukunft Gegenstand intensiver Untersuchungen sein, aber es handelt sich um eine ausgeklügelte, geduldige und mehrjährige Social-Engineering-Aktion des Angreifers, einem pseudonymen Angreifer namens „Jia Tan”. Diese Person verbrachte unzählige Stunden damit, das Vertrauen anderer Betreuer zu gewinnen, indem sie über zwei Jahre lang legitime Beiträge zum Projekt und zur XZ Utils-Community leistete und schließlich den Status eines „vertrauenswürdigen Betreuers” erhielt, nachdem mehrere Sockpuppet-Konten das Vertrauen in den freiwilligen Projektinhaber Lasse Collin untergraben hatten:
Dieses ungewöhnliche Szenario ist ein hervorragendes Beispiel dafür, wie selbst eine hochqualifizierte Fachkraft Opfer von Taktiken wird, die normalerweise für weniger sachkundige Personen reserviert sind. Dies verdeutlicht die Notwendigkeit einer präzisen, funktionsbasierten Schulung zur Sensibilisierung für Sicherheitsfragen. Nur dank der Neugier und der schnellen Auffassungsgabe des Microsoft-Softwareentwicklers und PostgreSQL-Wartungsbeauftragten Andrés Freund wurde die Hintertür entdeckt und die Versionen zurückgezogen, wodurch der möglicherweise verheerendste Angriff auf die Lieferkette der letzten Zeit verhindert werden konnte.
Die Hintertür selbst wird offiziell als Schwachstelle der höchsten Schwere im NIST-Register erfasst. Ursprünglich wurde angenommen, dass sie die Umgehung der Authentifizierung über SSH ermöglichte, aber eine spätere Untersuchung ergab, dass sie die Remote-Ausführung von Code ohne Authentifizierung auf anfälligen Linux-Systemen ermöglichte, darunter Fedora Rawhide, Fedora 41, Kali Linux, openSUSE microOS, openSUSE Tumbleweed und einige Versionen von Debian.
Jia Tan scheint alles getan zu haben, um das bösartige Paket zu verbergen, das, wenn es so aktiviert wird, dass es sich während des Erstellungsprozesses selbst erstellt, die Authentifizierung in SSHd über systemd erschwert. Wie Red Hat im Detail ausführt, könnte diese Störung unter bestimmten Umständen einem Angreifer ermöglichen, die SSHd-Authentifizierung zu umgehen und unbefugten Fernzugriff auf das gesamte System zu erlangen.
Microsoft, entre otros, ha guía completa publicada sobre el análisis de los sistemas en busca de casos de explotación y la mitigación de su efecto, y la acción inmediata recomendada por CISA es que los desarrolladores y usuarios afectados deberían cambiar XZ Utils a una versión sin compromisos, como XZ Utils 5.4.6 Stable.
Die Verhinderung solcher Angriffe ist unglaublich schwierig, insbesondere wenn Open-Source-Komponenten in der Software verwendet werden, da es nur sehr wenige Garantien und Transparenz in Bezug auf die Sicherheit der Lieferkette gibt. Wir haben bereits mit zufälligen Fehlern in der Software-Lieferkette zu kämpfen gehabt, aber dieses Risiko hat sich erhöht und umfasst nun auch Sicherheitslücken, die absichtlich zu böswilligen Zwecken geschaffen wurden, um die Sicherheit von Open-Source-Software zu gefährden.
Die meisten Entwickler werden einen Angriff dieser Art nicht abwehren können, es sei denn, sie verfügen über ein ausgeprägtes Sicherheitsbewusstsein, fundierte Sicherheitskenntnisse und eine Prise Paranoia. Es ist fast so, als müsste man die Denkweise eines Angreifers annehmen. Ein Hauptaugenmerk sollte jedoch immer auf den intern kontrollierten (d. h. nicht Open-Source-)Quellcode-Repositorys liegen. Sie sollten nur für Personen zugänglich sein, die über relevante und nachgewiesene Sicherheitskenntnisse verfügen. AppSec-Experten könnten eine ähnliche Konfiguration wie bei Sicherheitskontrollen auf Filialebene in Betracht ziehen, die es nur sicherheitsbewussten Entwicklern erlaubt, Änderungen am letzten Master-Zweig vorzunehmen.
Freiwillige Maintainer sind Helden, aber es sollte ein ganzes Dorf nötig sein, um Software sicher zu halten.
Für diejenigen, die nicht aus dem Bereich der Softwareentwicklung kommen, ist die Vorstellung, dass eine engagierte Gemeinschaft von Freiwilligen in ihrer Freizeit kritische Systeme sorgfältig wartet, schwer zu verstehen, aber das ist die Natur der Open-Source-Entwicklung und bleibt ein kritischer Risikobereich für Sicherheitsexperten, die die Lieferkette schützen.
Open-Source-Software ist ein wichtiger Bestandteil des digitalen Ökosystems praktisch aller Unternehmen, und diejenigen, die für ihre Wartung verantwortlich sind (von denen die meisten in guter Absicht handeln), sind in ihrem selbstlosen Streben nach technologischem Fortschritt und Integrität wahrhaft heldenhaft, aber es ist absurd, sie isoliert arbeiten zu lassen. In Zeiten, in denen DevSecops im Mittelpunkt steht, ist Sicherheit eine gemeinsame Verantwortung, und alle Entwickler müssen über das erforderliche Wissen und die richtigen Werkzeuge verfügen, um Sicherheitsprobleme zu lösen, mit denen sie wahrscheinlich im Laufe ihres Arbeitstages konfrontiert werden. Sicherheitswissen und praktische Fähigkeiten sollten im Softwareentwicklungsprozess nicht verhandelbar sein, und es ist Aufgabe der Sicherheitsverantwortlichen, den Wandel auf Unternehmensebene zu beeinflussen.
Schaffen Sie noch heute eine erfolgreiche Sicherheitskultur in Ihrem Unternehmen mit umfassenden Informationen Kurse von Secure Code Warrior.
Es wurde eine kritische Sicherheitslücke, CVE-2024-3094, in der Datenkomprimierungsbibliothek XZ Utils entdeckt, die von den wichtigsten Linux-Distributionen verwendet wird und durch eine Hintertür von einem Angreifer eingeführt wurde. Dieses schwerwiegende Problem ermöglicht die mögliche Remote-Ausführung von Code, was ein erhebliches Risiko für Softwareentwicklungsprozesse darstellt. Der Fehler betrifft die ersten Versionen (5.6.0 und 5.6.1) von XZ Utils in Fedora Rawhide, und es ist dringend erforderlich, dass Unternehmen Patches implementieren. Der Vorfall unterstreicht die wichtige Rolle der Freiwilligen in der Community bei der Wartung von Open-Source-Software und macht deutlich, dass die Sicherheitspraktiken und die Zugriffskontrolle während des gesamten Softwareentwicklungszyklus verbessert werden müssen.
Vorstandsvorsitzender, Chairman und Mitbegründer
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchen
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 in der Software-Lieferkette entdeckt wurde. Die Schwachstelle, die die Datenkomprimierungsbibliothek XZ Utils betrifft, die in den wichtigsten Linux-Distributionen enthalten ist, ist unter dem Code CVE-2024-3094 registriert und lässt sich auf eine Hintertür zurückführen, die absichtlich von einem freiwilligen Systemadministrator eingebaut wurde, der ihr einst vertraute. Die Ermöglichung der Remote-Code-Ausführung (RCE) in einigen Fällen, wenn sie richtig ausgenutzt wird, stellt ein sehr ernstes Problem dar, da sie schwere Schäden in den etablierten Softwareentwicklungsprozessen verursachen kann.
Glücklicherweise entdeckte ein anderer Maintainer diese Bedrohung, bevor der bösartige Code in die stabilen Versionen von Linux gelangte, aber es bleibt ein Problem für diejenigen, die mit der Ausführung der Versionen 5.6.0 und 5.6.1 von XZ Utils als Teil von Fedora Rawhide begonnen haben, und Organisationen werden aufgefordert, das Problem als Notfallpriorität zu beheben. Wäre diese Entdeckung nicht rechtzeitig gemacht worden, hätte das Risikoprofil dies zu einem der verheerendsten Angriffe auf die Lieferkette in der Geschichte gemacht, vielleicht sogar noch schlimmer als SolarWinds.
Die Abhängigkeit von Freiwilligen aus der Community zur Wartung kritischer Systeme ist weithin dokumentiert, wird jedoch selten diskutiert, bis Themen mit großer Tragweite wie dieser Vorfall ans Licht kommen. Obwohl ihre unermüdliche Arbeit für die Wartung von Open-Source-Software unerlässlich ist, zeigt dies doch, dass Entwickler besonders auf Sicherheitsfähigkeiten und -bewusstsein achten müssen, ganz zu schweigen von der Verstärkung der Zugriffskontrollen auf Software-Repositorys.
Was ist die Hintertür von XZ Utils und wie kann man sie entschärfen?
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 Bibliotheken und Komprimierungstools „XZ” bösartigen Code enthalten, der offenbar speziell dafür entwickelt wurde, unbefugten Zugriff durch Dritte zu ermöglichen. Die Art und Weise, wie dieser bösartige Code eingeschleust wurde, wird wahrscheinlich in Zukunft Gegenstand intensiver Untersuchungen sein, aber es handelt sich um eine ausgeklügelte, geduldige und mehrjährige Social-Engineering-Aktion des Angreifers, einem pseudonymen Angreifer namens „Jia Tan”. Diese Person verbrachte unzählige Stunden damit, das Vertrauen anderer Betreuer zu gewinnen, indem sie über zwei Jahre lang legitime Beiträge zum Projekt und zur XZ Utils-Community leistete und schließlich den Status eines „vertrauenswürdigen Betreuers” erhielt, nachdem mehrere Sockpuppet-Konten das Vertrauen in den freiwilligen Projektinhaber Lasse Collin untergraben hatten:
Dieses ungewöhnliche Szenario ist ein hervorragendes Beispiel dafür, wie selbst eine hochqualifizierte Fachkraft Opfer von Taktiken wird, die normalerweise für weniger sachkundige Personen reserviert sind. Dies verdeutlicht die Notwendigkeit einer präzisen, funktionsbasierten Schulung zur Sensibilisierung für Sicherheitsfragen. Nur dank der Neugier und der schnellen Auffassungsgabe des Microsoft-Softwareentwicklers und PostgreSQL-Wartungsbeauftragten Andrés Freund wurde die Hintertür entdeckt und die Versionen zurückgezogen, wodurch der möglicherweise verheerendste Angriff auf die Lieferkette der letzten Zeit verhindert werden konnte.
Die Hintertür selbst wird offiziell als Schwachstelle der höchsten Schwere im NIST-Register erfasst. Ursprünglich wurde angenommen, dass sie die Umgehung der Authentifizierung über SSH ermöglichte, aber eine spätere Untersuchung ergab, dass sie die Remote-Ausführung von Code ohne Authentifizierung auf anfälligen Linux-Systemen ermöglichte, darunter Fedora Rawhide, Fedora 41, Kali Linux, openSUSE microOS, openSUSE Tumbleweed und einige Versionen von Debian.
Jia Tan scheint alles getan zu haben, um das bösartige Paket zu verbergen, das, wenn es so aktiviert wird, dass es sich während des Erstellungsprozesses selbst erstellt, die Authentifizierung in SSHd über systemd erschwert. Wie Red Hat im Detail ausführt, könnte diese Störung unter bestimmten Umständen einem Angreifer ermöglichen, die SSHd-Authentifizierung zu umgehen und unbefugten Fernzugriff auf das gesamte System zu erlangen.
Microsoft, entre otros, ha guía completa publicada sobre el análisis de los sistemas en busca de casos de explotación y la mitigación de su efecto, y la acción inmediata recomendada por CISA es que los desarrolladores y usuarios afectados deberían cambiar XZ Utils a una versión sin compromisos, como XZ Utils 5.4.6 Stable.
Die Verhinderung solcher Angriffe ist unglaublich schwierig, insbesondere wenn Open-Source-Komponenten in der Software verwendet werden, da es nur sehr wenige Garantien und Transparenz in Bezug auf die Sicherheit der Lieferkette gibt. Wir haben bereits mit zufälligen Fehlern in der Software-Lieferkette zu kämpfen gehabt, aber dieses Risiko hat sich erhöht und umfasst nun auch Sicherheitslücken, die absichtlich zu böswilligen Zwecken geschaffen wurden, um die Sicherheit von Open-Source-Software zu gefährden.
Die meisten Entwickler werden einen Angriff dieser Art nicht abwehren können, es sei denn, sie verfügen über ein ausgeprägtes Sicherheitsbewusstsein, fundierte Sicherheitskenntnisse und eine Prise Paranoia. Es ist fast so, als müsste man die Denkweise eines Angreifers annehmen. Ein Hauptaugenmerk sollte jedoch immer auf den intern kontrollierten (d. h. nicht Open-Source-)Quellcode-Repositorys liegen. Sie sollten nur für Personen zugänglich sein, die über relevante und nachgewiesene Sicherheitskenntnisse verfügen. AppSec-Experten könnten eine ähnliche Konfiguration wie bei Sicherheitskontrollen auf Filialebene in Betracht ziehen, die es nur sicherheitsbewussten Entwicklern erlaubt, Änderungen am letzten Master-Zweig vorzunehmen.
Freiwillige Maintainer sind Helden, aber es sollte ein ganzes Dorf nötig sein, um Software sicher zu halten.
Für diejenigen, die nicht aus dem Bereich der Softwareentwicklung kommen, ist die Vorstellung, dass eine engagierte Gemeinschaft von Freiwilligen in ihrer Freizeit kritische Systeme sorgfältig wartet, schwer zu verstehen, aber das ist die Natur der Open-Source-Entwicklung und bleibt ein kritischer Risikobereich für Sicherheitsexperten, die die Lieferkette schützen.
Open-Source-Software ist ein wichtiger Bestandteil des digitalen Ökosystems praktisch aller Unternehmen, und diejenigen, die für ihre Wartung verantwortlich sind (von denen die meisten in guter Absicht handeln), sind in ihrem selbstlosen Streben nach technologischem Fortschritt und Integrität wahrhaft heldenhaft, aber es ist absurd, sie isoliert arbeiten zu lassen. In Zeiten, in denen DevSecops im Mittelpunkt steht, ist Sicherheit eine gemeinsame Verantwortung, und alle Entwickler müssen über das erforderliche Wissen und die richtigen Werkzeuge verfügen, um Sicherheitsprobleme zu lösen, mit denen sie wahrscheinlich im Laufe ihres Arbeitstages konfrontiert werden. Sicherheitswissen und praktische Fähigkeiten sollten im Softwareentwicklungsprozess nicht verhandelbar sein, und es ist Aufgabe der Sicherheitsverantwortlichen, den Wandel auf Unternehmensebene zu beeinflussen.
Schaffen Sie noch heute eine erfolgreiche Sicherheitskultur in Ihrem Unternehmen mit umfassenden Informationen Kurse von Secure Code Warrior.
Die Cybersicherheitsbranche wurde erneut in höchste Alarmbereitschaft versetzt, nachdem eine heimtückische Kompromittierung in der Software-Lieferkette entdeckt wurde. Die Schwachstelle, die die Datenkomprimierungsbibliothek XZ Utils betrifft, die in den wichtigsten Linux-Distributionen enthalten ist, ist unter dem Code CVE-2024-3094 registriert und lässt sich auf eine Hintertür zurückführen, die absichtlich von einem freiwilligen Systemadministrator eingebaut wurde, der ihr einst vertraute. Die Ermöglichung der Remote-Code-Ausführung (RCE) in einigen Fällen, wenn sie richtig ausgenutzt wird, stellt ein sehr ernstes Problem dar, da sie schwere Schäden in den etablierten Softwareentwicklungsprozessen verursachen kann.
Glücklicherweise entdeckte ein anderer Maintainer diese Bedrohung, bevor der bösartige Code in die stabilen Versionen von Linux gelangte, aber es bleibt ein Problem für diejenigen, die mit der Ausführung der Versionen 5.6.0 und 5.6.1 von XZ Utils als Teil von Fedora Rawhide begonnen haben, und Organisationen werden aufgefordert, das Problem als Notfallpriorität zu beheben. Wäre diese Entdeckung nicht rechtzeitig gemacht worden, hätte das Risikoprofil dies zu einem der verheerendsten Angriffe auf die Lieferkette in der Geschichte gemacht, vielleicht sogar noch schlimmer als SolarWinds.
Die Abhängigkeit von Freiwilligen aus der Community zur Wartung kritischer Systeme ist weithin dokumentiert, wird jedoch selten diskutiert, bis Themen mit großer Tragweite wie dieser Vorfall ans Licht kommen. Obwohl ihre unermüdliche Arbeit für die Wartung von Open-Source-Software unerlässlich ist, zeigt dies doch, dass Entwickler besonders auf Sicherheitsfähigkeiten und -bewusstsein achten müssen, ganz zu schweigen von der Verstärkung der Zugriffskontrollen auf Software-Repositorys.
Was ist die Hintertür von XZ Utils und wie kann man sie entschärfen?
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 Bibliotheken und Komprimierungstools „XZ” bösartigen Code enthalten, der offenbar speziell dafür entwickelt wurde, unbefugten Zugriff durch Dritte zu ermöglichen. Die Art und Weise, wie dieser bösartige Code eingeschleust wurde, wird wahrscheinlich in Zukunft Gegenstand intensiver Untersuchungen sein, aber es handelt sich um eine ausgeklügelte, geduldige und mehrjährige Social-Engineering-Aktion des Angreifers, einem pseudonymen Angreifer namens „Jia Tan”. Diese Person verbrachte unzählige Stunden damit, das Vertrauen anderer Betreuer zu gewinnen, indem sie über zwei Jahre lang legitime Beiträge zum Projekt und zur XZ Utils-Community leistete und schließlich den Status eines „vertrauenswürdigen Betreuers” erhielt, nachdem mehrere Sockpuppet-Konten das Vertrauen in den freiwilligen Projektinhaber Lasse Collin untergraben hatten:
Dieses ungewöhnliche Szenario ist ein hervorragendes Beispiel dafür, wie selbst eine hochqualifizierte Fachkraft Opfer von Taktiken wird, die normalerweise für weniger sachkundige Personen reserviert sind. Dies verdeutlicht die Notwendigkeit einer präzisen, funktionsbasierten Schulung zur Sensibilisierung für Sicherheitsfragen. Nur dank der Neugier und der schnellen Auffassungsgabe des Microsoft-Softwareentwicklers und PostgreSQL-Wartungsbeauftragten Andrés Freund wurde die Hintertür entdeckt und die Versionen zurückgezogen, wodurch der möglicherweise verheerendste Angriff auf die Lieferkette der letzten Zeit verhindert werden konnte.
Die Hintertür selbst wird offiziell als Schwachstelle der höchsten Schwere im NIST-Register erfasst. Ursprünglich wurde angenommen, dass sie die Umgehung der Authentifizierung über SSH ermöglichte, aber eine spätere Untersuchung ergab, dass sie die Remote-Ausführung von Code ohne Authentifizierung auf anfälligen Linux-Systemen ermöglichte, darunter Fedora Rawhide, Fedora 41, Kali Linux, openSUSE microOS, openSUSE Tumbleweed und einige Versionen von Debian.
Jia Tan scheint alles getan zu haben, um das bösartige Paket zu verbergen, das, wenn es so aktiviert wird, dass es sich während des Erstellungsprozesses selbst erstellt, die Authentifizierung in SSHd über systemd erschwert. Wie Red Hat im Detail ausführt, könnte diese Störung unter bestimmten Umständen einem Angreifer ermöglichen, die SSHd-Authentifizierung zu umgehen und unbefugten Fernzugriff auf das gesamte System zu erlangen.
Microsoft, entre otros, ha guía completa publicada sobre el análisis de los sistemas en busca de casos de explotación y la mitigación de su efecto, y la acción inmediata recomendada por CISA es que los desarrolladores y usuarios afectados deberían cambiar XZ Utils a una versión sin compromisos, como XZ Utils 5.4.6 Stable.
Die Verhinderung solcher Angriffe ist unglaublich schwierig, insbesondere wenn Open-Source-Komponenten in der Software verwendet werden, da es nur sehr wenige Garantien und Transparenz in Bezug auf die Sicherheit der Lieferkette gibt. Wir haben bereits mit zufälligen Fehlern in der Software-Lieferkette zu kämpfen gehabt, aber dieses Risiko hat sich erhöht und umfasst nun auch Sicherheitslücken, die absichtlich zu böswilligen Zwecken geschaffen wurden, um die Sicherheit von Open-Source-Software zu gefährden.
Die meisten Entwickler werden einen Angriff dieser Art nicht abwehren können, es sei denn, sie verfügen über ein ausgeprägtes Sicherheitsbewusstsein, fundierte Sicherheitskenntnisse und eine Prise Paranoia. Es ist fast so, als müsste man die Denkweise eines Angreifers annehmen. Ein Hauptaugenmerk sollte jedoch immer auf den intern kontrollierten (d. h. nicht Open-Source-)Quellcode-Repositorys liegen. Sie sollten nur für Personen zugänglich sein, die über relevante und nachgewiesene Sicherheitskenntnisse verfügen. AppSec-Experten könnten eine ähnliche Konfiguration wie bei Sicherheitskontrollen auf Filialebene in Betracht ziehen, die es nur sicherheitsbewussten Entwicklern erlaubt, Änderungen am letzten Master-Zweig vorzunehmen.
Freiwillige Maintainer sind Helden, aber es sollte ein ganzes Dorf nötig sein, um Software sicher zu halten.
Für diejenigen, die nicht aus dem Bereich der Softwareentwicklung kommen, ist die Vorstellung, dass eine engagierte Gemeinschaft von Freiwilligen in ihrer Freizeit kritische Systeme sorgfältig wartet, schwer zu verstehen, aber das ist die Natur der Open-Source-Entwicklung und bleibt ein kritischer Risikobereich für Sicherheitsexperten, die die Lieferkette schützen.
Open-Source-Software ist ein wichtiger Bestandteil des digitalen Ökosystems praktisch aller Unternehmen, und diejenigen, die für ihre Wartung verantwortlich sind (von denen die meisten in guter Absicht handeln), sind in ihrem selbstlosen Streben nach technologischem Fortschritt und Integrität wahrhaft heldenhaft, aber es ist absurd, sie isoliert arbeiten zu lassen. In Zeiten, in denen DevSecops im Mittelpunkt steht, ist Sicherheit eine gemeinsame Verantwortung, und alle Entwickler müssen über das erforderliche Wissen und die richtigen Werkzeuge verfügen, um Sicherheitsprobleme zu lösen, mit denen sie wahrscheinlich im Laufe ihres Arbeitstages konfrontiert werden. Sicherheitswissen und praktische Fähigkeiten sollten im Softwareentwicklungsprozess nicht verhandelbar sein, und es ist Aufgabe der Sicherheitsverantwortlichen, den Wandel auf Unternehmensebene zu beeinflussen.
Schaffen Sie noch heute eine erfolgreiche Sicherheitskultur in Ihrem Unternehmen mit umfassenden Informationen Kurse von Secure Code Warrior.
Klicken Sie auf den untenstehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenEine Vorführung buchen
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 in der Software-Lieferkette entdeckt wurde. Die Schwachstelle, die die Datenkomprimierungsbibliothek XZ Utils betrifft, die in den wichtigsten Linux-Distributionen enthalten ist, ist unter dem Code CVE-2024-3094 registriert und lässt sich auf eine Hintertür zurückführen, die absichtlich von einem freiwilligen Systemadministrator eingebaut wurde, der ihr einst vertraute. Die Ermöglichung der Remote-Code-Ausführung (RCE) in einigen Fällen, wenn sie richtig ausgenutzt wird, stellt ein sehr ernstes Problem dar, da sie schwere Schäden in den etablierten Softwareentwicklungsprozessen verursachen kann.
Glücklicherweise entdeckte ein anderer Maintainer diese Bedrohung, bevor der bösartige Code in die stabilen Versionen von Linux gelangte, aber es bleibt ein Problem für diejenigen, die mit der Ausführung der Versionen 5.6.0 und 5.6.1 von XZ Utils als Teil von Fedora Rawhide begonnen haben, und Organisationen werden aufgefordert, das Problem als Notfallpriorität zu beheben. Wäre diese Entdeckung nicht rechtzeitig gemacht worden, hätte das Risikoprofil dies zu einem der verheerendsten Angriffe auf die Lieferkette in der Geschichte gemacht, vielleicht sogar noch schlimmer als SolarWinds.
Die Abhängigkeit von Freiwilligen aus der Community zur Wartung kritischer Systeme ist weithin dokumentiert, wird jedoch selten diskutiert, bis Themen mit großer Tragweite wie dieser Vorfall ans Licht kommen. Obwohl ihre unermüdliche Arbeit für die Wartung von Open-Source-Software unerlässlich ist, zeigt dies doch, dass Entwickler besonders auf Sicherheitsfähigkeiten und -bewusstsein achten müssen, ganz zu schweigen von der Verstärkung der Zugriffskontrollen auf Software-Repositorys.
Was ist die Hintertür von XZ Utils und wie kann man sie entschärfen?
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 Bibliotheken und Komprimierungstools „XZ” bösartigen Code enthalten, der offenbar speziell dafür entwickelt wurde, unbefugten Zugriff durch Dritte zu ermöglichen. Die Art und Weise, wie dieser bösartige Code eingeschleust wurde, wird wahrscheinlich in Zukunft Gegenstand intensiver Untersuchungen sein, aber es handelt sich um eine ausgeklügelte, geduldige und mehrjährige Social-Engineering-Aktion des Angreifers, einem pseudonymen Angreifer namens „Jia Tan”. Diese Person verbrachte unzählige Stunden damit, das Vertrauen anderer Betreuer zu gewinnen, indem sie über zwei Jahre lang legitime Beiträge zum Projekt und zur XZ Utils-Community leistete und schließlich den Status eines „vertrauenswürdigen Betreuers” erhielt, nachdem mehrere Sockpuppet-Konten das Vertrauen in den freiwilligen Projektinhaber Lasse Collin untergraben hatten:
Dieses ungewöhnliche Szenario ist ein hervorragendes Beispiel dafür, wie selbst eine hochqualifizierte Fachkraft Opfer von Taktiken wird, die normalerweise für weniger sachkundige Personen reserviert sind. Dies verdeutlicht die Notwendigkeit einer präzisen, funktionsbasierten Schulung zur Sensibilisierung für Sicherheitsfragen. Nur dank der Neugier und der schnellen Auffassungsgabe des Microsoft-Softwareentwicklers und PostgreSQL-Wartungsbeauftragten Andrés Freund wurde die Hintertür entdeckt und die Versionen zurückgezogen, wodurch der möglicherweise verheerendste Angriff auf die Lieferkette der letzten Zeit verhindert werden konnte.
Die Hintertür selbst wird offiziell als Schwachstelle der höchsten Schwere im NIST-Register erfasst. Ursprünglich wurde angenommen, dass sie die Umgehung der Authentifizierung über SSH ermöglichte, aber eine spätere Untersuchung ergab, dass sie die Remote-Ausführung von Code ohne Authentifizierung auf anfälligen Linux-Systemen ermöglichte, darunter Fedora Rawhide, Fedora 41, Kali Linux, openSUSE microOS, openSUSE Tumbleweed und einige Versionen von Debian.
Jia Tan scheint alles getan zu haben, um das bösartige Paket zu verbergen, das, wenn es so aktiviert wird, dass es sich während des Erstellungsprozesses selbst erstellt, die Authentifizierung in SSHd über systemd erschwert. Wie Red Hat im Detail ausführt, könnte diese Störung unter bestimmten Umständen einem Angreifer ermöglichen, die SSHd-Authentifizierung zu umgehen und unbefugten Fernzugriff auf das gesamte System zu erlangen.
Microsoft, entre otros, ha guía completa publicada sobre el análisis de los sistemas en busca de casos de explotación y la mitigación de su efecto, y la acción inmediata recomendada por CISA es que los desarrolladores y usuarios afectados deberían cambiar XZ Utils a una versión sin compromisos, como XZ Utils 5.4.6 Stable.
Die Verhinderung solcher Angriffe ist unglaublich schwierig, insbesondere wenn Open-Source-Komponenten in der Software verwendet werden, da es nur sehr wenige Garantien und Transparenz in Bezug auf die Sicherheit der Lieferkette gibt. Wir haben bereits mit zufälligen Fehlern in der Software-Lieferkette zu kämpfen gehabt, aber dieses Risiko hat sich erhöht und umfasst nun auch Sicherheitslücken, die absichtlich zu böswilligen Zwecken geschaffen wurden, um die Sicherheit von Open-Source-Software zu gefährden.
Die meisten Entwickler werden einen Angriff dieser Art nicht abwehren können, es sei denn, sie verfügen über ein ausgeprägtes Sicherheitsbewusstsein, fundierte Sicherheitskenntnisse und eine Prise Paranoia. Es ist fast so, als müsste man die Denkweise eines Angreifers annehmen. Ein Hauptaugenmerk sollte jedoch immer auf den intern kontrollierten (d. h. nicht Open-Source-)Quellcode-Repositorys liegen. Sie sollten nur für Personen zugänglich sein, die über relevante und nachgewiesene Sicherheitskenntnisse verfügen. AppSec-Experten könnten eine ähnliche Konfiguration wie bei Sicherheitskontrollen auf Filialebene in Betracht ziehen, die es nur sicherheitsbewussten Entwicklern erlaubt, Änderungen am letzten Master-Zweig vorzunehmen.
Freiwillige Maintainer sind Helden, aber es sollte ein ganzes Dorf nötig sein, um Software sicher zu halten.
Für diejenigen, die nicht aus dem Bereich der Softwareentwicklung kommen, ist die Vorstellung, dass eine engagierte Gemeinschaft von Freiwilligen in ihrer Freizeit kritische Systeme sorgfältig wartet, schwer zu verstehen, aber das ist die Natur der Open-Source-Entwicklung und bleibt ein kritischer Risikobereich für Sicherheitsexperten, die die Lieferkette schützen.
Open-Source-Software ist ein wichtiger Bestandteil des digitalen Ökosystems praktisch aller Unternehmen, und diejenigen, die für ihre Wartung verantwortlich sind (von denen die meisten in guter Absicht handeln), sind in ihrem selbstlosen Streben nach technologischem Fortschritt und Integrität wahrhaft heldenhaft, aber es ist absurd, sie isoliert arbeiten zu lassen. In Zeiten, in denen DevSecops im Mittelpunkt steht, ist Sicherheit eine gemeinsame Verantwortung, und alle Entwickler müssen über das erforderliche Wissen und die richtigen Werkzeuge verfügen, um Sicherheitsprobleme zu lösen, mit denen sie wahrscheinlich im Laufe ihres Arbeitstages konfrontiert werden. Sicherheitswissen und praktische Fähigkeiten sollten im Softwareentwicklungsprozess nicht verhandelbar sein, und es ist Aufgabe der Sicherheitsverantwortlichen, den Wandel auf Unternehmensebene zu beeinflussen.
Schaffen Sie noch heute eine erfolgreiche Sicherheitskultur in Ihrem Unternehmen mit umfassenden Informationen Kurse von Secure Code Warrior.
Inhaltsverzeichnis
Vorstandsvorsitzender, Chairman und Mitbegründer
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Schulung zum Thema sicherer Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Landschaft der Softwareentwicklung anzupassen und dabei Ihre Rolle zu berücksichtigen. Es werden Themen angeboten, die von KI bis hin zu XQuery-Injektion reichen und sich an verschiedene Positionen richten, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätskontrolleuren. Verschaffen Sie sich einen Überblick über unser Angebot an Inhalten nach Thema und Funktion.
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-Missionen von Beat the Boss sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über bei SCW verfügbar. Implementieren Sie fortschrittliche KI- und LLM-Sicherheitsherausforderungen, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet es für die Entwicklung sicherer Software?
Entdecken Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams mit sicheren Designpraktiken, der Vermeidung von Schwachstellen und der Entwicklung von Fähigkeiten für Entwickler darauf vorbereiten können.
SCW feiert sein 11-jähriges Bestehen: eine Lektion in Echtzeit über Anpassungsfähigkeit und kontinuierliche Verbesserung
2025 war ein großartiges Jahr für KI, Cybersicherheit und SCW. Ich gehe mit ruhiger Zuversicht und dem Optimismus, den nur harte und lohnende Arbeit mit sich bringen kann, auf das Jahr 2026 zu.