Die Hintertür von XZ Utils unter Linux verdeutlicht ein umfassenderes Problem der Sicherheit in der Lieferkette, und wir brauchen mehr als nur Gemeinschaftsgeist, um es in den Griff zu bekommen.
Der Bereich Cybersicherheit wurde erneut in Alarmbereitschaft versetzt, nachdem eine heimtückische Kompromittierung der Software-Lieferkette entdeckt wurde. Die Schwachstelle, die die mit den wichtigsten Linux-Distributionen gelieferte Datenkomprimierungsbibliothek XZ Utils betrifft, ist unter CVE-2024-3094 registriert und lässt sich als eine Hintertür zusammenfassen, die absichtlich von einem freiwilligen Betreuer des ehemals zuverlässigen Systems eingefügt wurde. Da sie in bestimmten Fällen die Ausführung von Remote-Code (RCE) ermöglicht, wenn sie erfolgreich ausgenutzt wird, stellt sie ein sehr ernstes Problem dar, das zu schwerwiegenden Schäden in etablierten Softwareentwicklungsprozessen führen kann.
Glücklicherweise hat ein anderer Verantwortlicher diese Bedrohung entdeckt, bevor der bösartige Code in die stabilen Versionen von Linux gelangte, aber sie stellt dennoch ein Problem für diejenigen dar, die begonnen haben, die Versionen 5.6.0 und 5.6.1 von XZ Utils im Rahmen von Fedora Rawhide zu verwenden, und Organisationen werden aufgefordert, im Notfall vorrangig einen Patch zu installieren. Wäre diese Entdeckung nicht rechtzeitig gemacht worden, hätte das Risikoprofil dies zu einem der verheerendsten Angriffe gemacht, die jemals auf die Lieferkette verzeichnet wurden, und möglicherweise sogar SolarWinds in den Schatten gestellt.
Die Abhängigkeit von Freiwilligen aus der Community für die Wartung kritischer Systeme ist weithin dokumentiert, wird jedoch selten thematisiert, bevor Probleme mit starken Auswirkungen wie dieser Vorfall auftreten. Obwohl ihre unermüdliche Arbeit für die Wartung freier Software unerlässlich ist, zeigt dies doch, wie wichtig es ist, den Schwerpunkt ernsthaft auf die Sicherheitskompetenzen und das Sicherheitsbewusstsein der Entwickler zu legen und nicht zu vergessen, die Zugriffskontrollen für Software-Repositorys zu verstärken.
Was ist die Hintertür XZ Utils und wie wird sie abgeschwächt?
Am 29. März veröffentlichte Red Hat eine dringende Sicherheitswarnung, um Benutzer von Fedora Linux 4.0 und Fedora Rawhide darüber zu informieren, dass die neuesten Versionen der Komprimierungstools und „XZ”-Bibliotheken bösartigen Code enthalten, der offenbar speziell entwickelt wurde, um Dritten den unbefugten Zugriff zu erleichtern. Die Art und Weise, wie dieser bösartige Code eingeschleust wurde, wird wahrscheinlich in Zukunft eingehend untersucht werden, aber es handelt sich um eine ausgeklügelte, geduldige und langwierige Social-Engineering-Maßnahme seitens des Angreifers, einem pseudonymen Angreifer namens „Jia Tan”. Diese Person hat unzählige Stunden damit verbracht, das Vertrauen anderer Verantwortlicher zu gewinnen, über zwei Jahre lang legitime Beiträge zum Projekt und zur XZ Utils-Community zu leisten und schließlich den Status eines „vertrauenswürdigen Maintainers” zu erlangen, nachdem mehrere Fake-Accounts das Vertrauen in den ehrenamtlichen Projektleiter Lasse Collin untergraben hatten:
Dieses ungewöhnliche Szenario ist ein hervorragendes Beispiel dafür, dass selbst technisch versierte Personen Opfer von Taktiken werden, die normalerweise weniger erfahrenen Personen vorbehalten sind. Dies zeigt, wie wichtig eine präzise und rollenbasierte Sicherheitsschulung ist. Nur dank der Neugier und der Geistesgegenwart des Microsoft-Softwareentwicklers und PostgreSQL-Verantwortlichen Andrés Freund wurde die Hintertür entdeckt und die Versionen zurückgezogen, wodurch der möglicherweise verheerendste Angriff auf die Lieferkette in der jüngeren Geschichte verhindert werden konnte.
Die Hintertür selbst wird im NIST-Register offiziell als Schwachstelle mit dem höchstmöglichen Schweregrad eingestuft. Ursprünglich wurde angenommen, dass sie die Umgehung der SSH-Authentifizierung ermöglicht, doch eine eingehendere Untersuchung ergab, dass sie die Ausführung von nicht authentifiziertem Remote-Code auf anfälligen Linux-Systemen ermöglicht, darunter Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed und bestimmte Versionen von Debian.
Jia Tan scheint große Anstrengungen unternommen zu haben, um das bösartige Paket zu verbergen, das, wenn es während des Generierungsprozesses ausgelöst wird, die Authentifizierung in SSHD über systemd behindert. Wie Chapeau rouge ausführlich beschrieben, könnte diese Störung unter bestimmten Umständen einem Angreifer ermöglichen, die SSHD-Authentifizierung zu umgehen und sich unbefugten Fernzugriff auf das gesamte System zu verschaffen.
Microsoft, entre autres, a des directives complètes publiées sur l'analyse des systèmes à la recherche d'instances de l'exploit et sur l'atténuation de ses effets, et sur les mesures immédiates recommandées par CISA est que les développeurs et utilisateurs concernés doivent rétrograder XZ Utils vers une version non compromise, comme XZ Utils 5.4.6 Stable.
Es ist äußerst schwierig, diese Art von Angriffen zu verhindern, insbesondere wenn es um die Verwendung von Open-Source-Komponenten in Software geht, da die Sicherheit der Lieferkette sehr begrenzt und wenig transparent ist. Wir haben bereits mit versehentlichen Schwachstellen in der Software-Lieferkette zu kämpfen gehabt, aber dieses Risiko hat sich erhöht und umfasst nun auch absichtlich implantierte Sicherheitslücken, die darauf abzielen, die Sicherheit von freier Software zu kompromittieren.
Die meisten Entwickler werden nicht in der Lage sein, einen Angriff dieser Art zu stoppen, wenn sie nicht über ein ausgeprägtes Sicherheitsbewusstsein, fundierte Sicherheitskenntnisse und eine gewisse Paranoia verfügen. Es geht fast darum, eine Denkweise wie die eines Angreifers zu verlangen. Ein Hauptaugenmerk sollte jedoch immer auf intern kontrollierten Quellcode-Repositorys (d. h. nicht Open Source) liegen. Sie sollten nur Personen mit entsprechenden und überprüften Sicherheitskompetenzen zugänglich sein. AppSec-Fachleute können eine Konfiguration wie Sicherheitskontrollen auf Branch-Ebene in Betracht ziehen, die es nur sicherheitserfahrenen Entwicklern erlauben, Änderungen am endgültigen Hauptzweig vorzunehmen.
Freiwillige Maintainer sind Helden, aber es braucht (sollte es zumindest) ein ganzes Dorf, um eine Software sicher zu halten.
Für diejenigen, die nicht im Bereich Software-Engineering tätig sind, ist es schwer zu verstehen, dass eine dynamische Gemeinschaft von Freiwilligen kritische Systeme in ihrem eigenen Tempo sorgfältig wartet, aber das ist die Natur der Open-Source-Entwicklung, die weiterhin ein kritisches Risiko für Sicherheitsexperten darstellt, die die Lieferkette schützen.
Freie Software ist ein wesentlicher Bestandteil des digitalen Ökosystems praktisch aller Unternehmen, und vertrauenswürdige Verantwortliche (von denen die meisten in gutem Glauben handeln) zeigen wahren Heldenmut in ihrem selbstlosen Streben nach technologischem Fortschritt und Integrität, aber es ist lächerlich, sie isoliert arbeiten zu lassen. In Zeiten, in denen DevSecOps im Mittelpunkt steht, ist Sicherheit eine gemeinsame Verantwortung, und jeder Entwickler muss über das erforderliche Wissen und die geeigneten Tools verfügen, um Sicherheitsprobleme zu bewältigen, denen er im Laufe seines Arbeitstages begegnen kann. Sicherheitsbewusstsein und praktische Fähigkeiten sollten im Softwareentwicklungsprozess nicht verhandelbar sein, und es ist Aufgabe der Sicherheitsverantwortlichen, Veränderungen auf Unternehmensebene zu beeinflussen.
Schaffen Sie noch heute eine florierende Sicherheitskultur in Ihrem Unternehmen dank Kurs von Secure Code Warrior.
Eine kritische Sicherheitslücke, CVE-2024-3094, wurde in der von den wichtigsten Linux-Distributionen verwendeten Datenkomprimierungsbibliothek XZ Utils entdeckt, die von einem böswilligen Akteur durch eine Hintertür eingeführt wurde. Dieses sehr schwerwiegende Problem kann zur Ausführung von Remote-Code führen, was erhebliche Risiken für Softwareentwicklungsprozesse mit sich bringt. Die Schwachstelle betrifft die ersten Versionen (5.6.0 und 5.6.1) von XZ Utils in Fedora Rawhide, weshalb Organisationen dringend aufgefordert werden, Patches zu implementieren. Der Vorfall unterstreicht die wichtige Rolle der Freiwilligen in der Community bei der Wartung von Open-Source-Software und macht deutlich, dass Sicherheitspraktiken und Zugriffskontrollen während des gesamten Softwareentwicklungszyklus verstärkt werden müssen.
Vorstandsvorsitzender, Chairman und Mitbegründer
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo 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.
Der Bereich Cybersicherheit wurde erneut in Alarmbereitschaft versetzt, nachdem eine heimtückische Kompromittierung der Software-Lieferkette entdeckt wurde. Die Schwachstelle, die die mit den wichtigsten Linux-Distributionen gelieferte Datenkomprimierungsbibliothek XZ Utils betrifft, ist unter CVE-2024-3094 registriert und lässt sich als eine Hintertür zusammenfassen, die absichtlich von einem freiwilligen Betreuer des ehemals zuverlässigen Systems eingefügt wurde. Da sie in bestimmten Fällen die Ausführung von Remote-Code (RCE) ermöglicht, wenn sie erfolgreich ausgenutzt wird, stellt sie ein sehr ernstes Problem dar, das zu schwerwiegenden Schäden in etablierten Softwareentwicklungsprozessen führen kann.
Glücklicherweise hat ein anderer Verantwortlicher diese Bedrohung entdeckt, bevor der bösartige Code in die stabilen Versionen von Linux gelangte, aber sie stellt dennoch ein Problem für diejenigen dar, die begonnen haben, die Versionen 5.6.0 und 5.6.1 von XZ Utils im Rahmen von Fedora Rawhide zu verwenden, und Organisationen werden aufgefordert, im Notfall vorrangig einen Patch zu installieren. Wäre diese Entdeckung nicht rechtzeitig gemacht worden, hätte das Risikoprofil dies zu einem der verheerendsten Angriffe gemacht, die jemals auf die Lieferkette verzeichnet wurden, und möglicherweise sogar SolarWinds in den Schatten gestellt.
Die Abhängigkeit von Freiwilligen aus der Community für die Wartung kritischer Systeme ist weithin dokumentiert, wird jedoch selten thematisiert, bevor Probleme mit starken Auswirkungen wie dieser Vorfall auftreten. Obwohl ihre unermüdliche Arbeit für die Wartung freier Software unerlässlich ist, zeigt dies doch, wie wichtig es ist, den Schwerpunkt ernsthaft auf die Sicherheitskompetenzen und das Sicherheitsbewusstsein der Entwickler zu legen und nicht zu vergessen, die Zugriffskontrollen für Software-Repositorys zu verstärken.
Was ist die Hintertür XZ Utils und wie wird sie abgeschwächt?
Am 29. März veröffentlichte Red Hat eine dringende Sicherheitswarnung, um Benutzer von Fedora Linux 4.0 und Fedora Rawhide darüber zu informieren, dass die neuesten Versionen der Komprimierungstools und „XZ”-Bibliotheken bösartigen Code enthalten, der offenbar speziell entwickelt wurde, um Dritten den unbefugten Zugriff zu erleichtern. Die Art und Weise, wie dieser bösartige Code eingeschleust wurde, wird wahrscheinlich in Zukunft eingehend untersucht werden, aber es handelt sich um eine ausgeklügelte, geduldige und langwierige Social-Engineering-Maßnahme seitens des Angreifers, einem pseudonymen Angreifer namens „Jia Tan”. Diese Person hat unzählige Stunden damit verbracht, das Vertrauen anderer Verantwortlicher zu gewinnen, über zwei Jahre lang legitime Beiträge zum Projekt und zur XZ Utils-Community zu leisten und schließlich den Status eines „vertrauenswürdigen Maintainers” zu erlangen, nachdem mehrere Fake-Accounts das Vertrauen in den ehrenamtlichen Projektleiter Lasse Collin untergraben hatten:
Dieses ungewöhnliche Szenario ist ein hervorragendes Beispiel dafür, dass selbst technisch versierte Personen Opfer von Taktiken werden, die normalerweise weniger erfahrenen Personen vorbehalten sind. Dies zeigt, wie wichtig eine präzise und rollenbasierte Sicherheitsschulung ist. Nur dank der Neugier und der Geistesgegenwart des Microsoft-Softwareentwicklers und PostgreSQL-Verantwortlichen Andrés Freund wurde die Hintertür entdeckt und die Versionen zurückgezogen, wodurch der möglicherweise verheerendste Angriff auf die Lieferkette in der jüngeren Geschichte verhindert werden konnte.
Die Hintertür selbst wird im NIST-Register offiziell als Schwachstelle mit dem höchstmöglichen Schweregrad eingestuft. Ursprünglich wurde angenommen, dass sie die Umgehung der SSH-Authentifizierung ermöglicht, doch eine eingehendere Untersuchung ergab, dass sie die Ausführung von nicht authentifiziertem Remote-Code auf anfälligen Linux-Systemen ermöglicht, darunter Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed und bestimmte Versionen von Debian.
Jia Tan scheint große Anstrengungen unternommen zu haben, um das bösartige Paket zu verbergen, das, wenn es während des Generierungsprozesses ausgelöst wird, die Authentifizierung in SSHD über systemd behindert. Wie Chapeau rouge ausführlich beschrieben, könnte diese Störung unter bestimmten Umständen einem Angreifer ermöglichen, die SSHD-Authentifizierung zu umgehen und sich unbefugten Fernzugriff auf das gesamte System zu verschaffen.
Microsoft, entre autres, a des directives complètes publiées sur l'analyse des systèmes à la recherche d'instances de l'exploit et sur l'atténuation de ses effets, et sur les mesures immédiates recommandées par CISA est que les développeurs et utilisateurs concernés doivent rétrograder XZ Utils vers une version non compromise, comme XZ Utils 5.4.6 Stable.
Es ist äußerst schwierig, diese Art von Angriffen zu verhindern, insbesondere wenn es um die Verwendung von Open-Source-Komponenten in Software geht, da die Sicherheit der Lieferkette sehr begrenzt und wenig transparent ist. Wir haben bereits mit versehentlichen Schwachstellen in der Software-Lieferkette zu kämpfen gehabt, aber dieses Risiko hat sich erhöht und umfasst nun auch absichtlich implantierte Sicherheitslücken, die darauf abzielen, die Sicherheit von freier Software zu kompromittieren.
Die meisten Entwickler werden nicht in der Lage sein, einen Angriff dieser Art zu stoppen, wenn sie nicht über ein ausgeprägtes Sicherheitsbewusstsein, fundierte Sicherheitskenntnisse und eine gewisse Paranoia verfügen. Es geht fast darum, eine Denkweise wie die eines Angreifers zu verlangen. Ein Hauptaugenmerk sollte jedoch immer auf intern kontrollierten Quellcode-Repositorys (d. h. nicht Open Source) liegen. Sie sollten nur Personen mit entsprechenden und überprüften Sicherheitskompetenzen zugänglich sein. AppSec-Fachleute können eine Konfiguration wie Sicherheitskontrollen auf Branch-Ebene in Betracht ziehen, die es nur sicherheitserfahrenen Entwicklern erlauben, Änderungen am endgültigen Hauptzweig vorzunehmen.
Freiwillige Maintainer sind Helden, aber es braucht (sollte es zumindest) ein ganzes Dorf, um eine Software sicher zu halten.
Für diejenigen, die nicht im Bereich Software-Engineering tätig sind, ist es schwer zu verstehen, dass eine dynamische Gemeinschaft von Freiwilligen kritische Systeme in ihrem eigenen Tempo sorgfältig wartet, aber das ist die Natur der Open-Source-Entwicklung, die weiterhin ein kritisches Risiko für Sicherheitsexperten darstellt, die die Lieferkette schützen.
Freie Software ist ein wesentlicher Bestandteil des digitalen Ökosystems praktisch aller Unternehmen, und vertrauenswürdige Verantwortliche (von denen die meisten in gutem Glauben handeln) zeigen wahren Heldenmut in ihrem selbstlosen Streben nach technologischem Fortschritt und Integrität, aber es ist lächerlich, sie isoliert arbeiten zu lassen. In Zeiten, in denen DevSecOps im Mittelpunkt steht, ist Sicherheit eine gemeinsame Verantwortung, und jeder Entwickler muss über das erforderliche Wissen und die geeigneten Tools verfügen, um Sicherheitsprobleme zu bewältigen, denen er im Laufe seines Arbeitstages begegnen kann. Sicherheitsbewusstsein und praktische Fähigkeiten sollten im Softwareentwicklungsprozess nicht verhandelbar sein, und es ist Aufgabe der Sicherheitsverantwortlichen, Veränderungen auf Unternehmensebene zu beeinflussen.
Schaffen Sie noch heute eine florierende Sicherheitskultur in Ihrem Unternehmen dank Kurs von Secure Code Warrior.
Der Bereich Cybersicherheit wurde erneut in Alarmbereitschaft versetzt, nachdem eine heimtückische Kompromittierung der Software-Lieferkette entdeckt wurde. Die Schwachstelle, die die mit den wichtigsten Linux-Distributionen gelieferte Datenkomprimierungsbibliothek XZ Utils betrifft, ist unter CVE-2024-3094 registriert und lässt sich als eine Hintertür zusammenfassen, die absichtlich von einem freiwilligen Betreuer des ehemals zuverlässigen Systems eingefügt wurde. Da sie in bestimmten Fällen die Ausführung von Remote-Code (RCE) ermöglicht, wenn sie erfolgreich ausgenutzt wird, stellt sie ein sehr ernstes Problem dar, das zu schwerwiegenden Schäden in etablierten Softwareentwicklungsprozessen führen kann.
Glücklicherweise hat ein anderer Verantwortlicher diese Bedrohung entdeckt, bevor der bösartige Code in die stabilen Versionen von Linux gelangte, aber sie stellt dennoch ein Problem für diejenigen dar, die begonnen haben, die Versionen 5.6.0 und 5.6.1 von XZ Utils im Rahmen von Fedora Rawhide zu verwenden, und Organisationen werden aufgefordert, im Notfall vorrangig einen Patch zu installieren. Wäre diese Entdeckung nicht rechtzeitig gemacht worden, hätte das Risikoprofil dies zu einem der verheerendsten Angriffe gemacht, die jemals auf die Lieferkette verzeichnet wurden, und möglicherweise sogar SolarWinds in den Schatten gestellt.
Die Abhängigkeit von Freiwilligen aus der Community für die Wartung kritischer Systeme ist weithin dokumentiert, wird jedoch selten thematisiert, bevor Probleme mit starken Auswirkungen wie dieser Vorfall auftreten. Obwohl ihre unermüdliche Arbeit für die Wartung freier Software unerlässlich ist, zeigt dies doch, wie wichtig es ist, den Schwerpunkt ernsthaft auf die Sicherheitskompetenzen und das Sicherheitsbewusstsein der Entwickler zu legen und nicht zu vergessen, die Zugriffskontrollen für Software-Repositorys zu verstärken.
Was ist die Hintertür XZ Utils und wie wird sie abgeschwächt?
Am 29. März veröffentlichte Red Hat eine dringende Sicherheitswarnung, um Benutzer von Fedora Linux 4.0 und Fedora Rawhide darüber zu informieren, dass die neuesten Versionen der Komprimierungstools und „XZ”-Bibliotheken bösartigen Code enthalten, der offenbar speziell entwickelt wurde, um Dritten den unbefugten Zugriff zu erleichtern. Die Art und Weise, wie dieser bösartige Code eingeschleust wurde, wird wahrscheinlich in Zukunft eingehend untersucht werden, aber es handelt sich um eine ausgeklügelte, geduldige und langwierige Social-Engineering-Maßnahme seitens des Angreifers, einem pseudonymen Angreifer namens „Jia Tan”. Diese Person hat unzählige Stunden damit verbracht, das Vertrauen anderer Verantwortlicher zu gewinnen, über zwei Jahre lang legitime Beiträge zum Projekt und zur XZ Utils-Community zu leisten und schließlich den Status eines „vertrauenswürdigen Maintainers” zu erlangen, nachdem mehrere Fake-Accounts das Vertrauen in den ehrenamtlichen Projektleiter Lasse Collin untergraben hatten:
Dieses ungewöhnliche Szenario ist ein hervorragendes Beispiel dafür, dass selbst technisch versierte Personen Opfer von Taktiken werden, die normalerweise weniger erfahrenen Personen vorbehalten sind. Dies zeigt, wie wichtig eine präzise und rollenbasierte Sicherheitsschulung ist. Nur dank der Neugier und der Geistesgegenwart des Microsoft-Softwareentwicklers und PostgreSQL-Verantwortlichen Andrés Freund wurde die Hintertür entdeckt und die Versionen zurückgezogen, wodurch der möglicherweise verheerendste Angriff auf die Lieferkette in der jüngeren Geschichte verhindert werden konnte.
Die Hintertür selbst wird im NIST-Register offiziell als Schwachstelle mit dem höchstmöglichen Schweregrad eingestuft. Ursprünglich wurde angenommen, dass sie die Umgehung der SSH-Authentifizierung ermöglicht, doch eine eingehendere Untersuchung ergab, dass sie die Ausführung von nicht authentifiziertem Remote-Code auf anfälligen Linux-Systemen ermöglicht, darunter Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed und bestimmte Versionen von Debian.
Jia Tan scheint große Anstrengungen unternommen zu haben, um das bösartige Paket zu verbergen, das, wenn es während des Generierungsprozesses ausgelöst wird, die Authentifizierung in SSHD über systemd behindert. Wie Chapeau rouge ausführlich beschrieben, könnte diese Störung unter bestimmten Umständen einem Angreifer ermöglichen, die SSHD-Authentifizierung zu umgehen und sich unbefugten Fernzugriff auf das gesamte System zu verschaffen.
Microsoft, entre autres, a des directives complètes publiées sur l'analyse des systèmes à la recherche d'instances de l'exploit et sur l'atténuation de ses effets, et sur les mesures immédiates recommandées par CISA est que les développeurs et utilisateurs concernés doivent rétrograder XZ Utils vers une version non compromise, comme XZ Utils 5.4.6 Stable.
Es ist äußerst schwierig, diese Art von Angriffen zu verhindern, insbesondere wenn es um die Verwendung von Open-Source-Komponenten in Software geht, da die Sicherheit der Lieferkette sehr begrenzt und wenig transparent ist. Wir haben bereits mit versehentlichen Schwachstellen in der Software-Lieferkette zu kämpfen gehabt, aber dieses Risiko hat sich erhöht und umfasst nun auch absichtlich implantierte Sicherheitslücken, die darauf abzielen, die Sicherheit von freier Software zu kompromittieren.
Die meisten Entwickler werden nicht in der Lage sein, einen Angriff dieser Art zu stoppen, wenn sie nicht über ein ausgeprägtes Sicherheitsbewusstsein, fundierte Sicherheitskenntnisse und eine gewisse Paranoia verfügen. Es geht fast darum, eine Denkweise wie die eines Angreifers zu verlangen. Ein Hauptaugenmerk sollte jedoch immer auf intern kontrollierten Quellcode-Repositorys (d. h. nicht Open Source) liegen. Sie sollten nur Personen mit entsprechenden und überprüften Sicherheitskompetenzen zugänglich sein. AppSec-Fachleute können eine Konfiguration wie Sicherheitskontrollen auf Branch-Ebene in Betracht ziehen, die es nur sicherheitserfahrenen Entwicklern erlauben, Änderungen am endgültigen Hauptzweig vorzunehmen.
Freiwillige Maintainer sind Helden, aber es braucht (sollte es zumindest) ein ganzes Dorf, um eine Software sicher zu halten.
Für diejenigen, die nicht im Bereich Software-Engineering tätig sind, ist es schwer zu verstehen, dass eine dynamische Gemeinschaft von Freiwilligen kritische Systeme in ihrem eigenen Tempo sorgfältig wartet, aber das ist die Natur der Open-Source-Entwicklung, die weiterhin ein kritisches Risiko für Sicherheitsexperten darstellt, die die Lieferkette schützen.
Freie Software ist ein wesentlicher Bestandteil des digitalen Ökosystems praktisch aller Unternehmen, und vertrauenswürdige Verantwortliche (von denen die meisten in gutem Glauben handeln) zeigen wahren Heldenmut in ihrem selbstlosen Streben nach technologischem Fortschritt und Integrität, aber es ist lächerlich, sie isoliert arbeiten zu lassen. In Zeiten, in denen DevSecOps im Mittelpunkt steht, ist Sicherheit eine gemeinsame Verantwortung, und jeder Entwickler muss über das erforderliche Wissen und die geeigneten Tools verfügen, um Sicherheitsprobleme zu bewältigen, denen er im Laufe seines Arbeitstages begegnen kann. Sicherheitsbewusstsein und praktische Fähigkeiten sollten im Softwareentwicklungsprozess nicht verhandelbar sein, und es ist Aufgabe der Sicherheitsverantwortlichen, Veränderungen auf Unternehmensebene zu beeinflussen.
Schaffen Sie noch heute eine florierende Sicherheitskultur in Ihrem Unternehmen dank Kurs von Secure Code Warrior.
Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenDemo 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.
Der Bereich Cybersicherheit wurde erneut in Alarmbereitschaft versetzt, nachdem eine heimtückische Kompromittierung der Software-Lieferkette entdeckt wurde. Die Schwachstelle, die die mit den wichtigsten Linux-Distributionen gelieferte Datenkomprimierungsbibliothek XZ Utils betrifft, ist unter CVE-2024-3094 registriert und lässt sich als eine Hintertür zusammenfassen, die absichtlich von einem freiwilligen Betreuer des ehemals zuverlässigen Systems eingefügt wurde. Da sie in bestimmten Fällen die Ausführung von Remote-Code (RCE) ermöglicht, wenn sie erfolgreich ausgenutzt wird, stellt sie ein sehr ernstes Problem dar, das zu schwerwiegenden Schäden in etablierten Softwareentwicklungsprozessen führen kann.
Glücklicherweise hat ein anderer Verantwortlicher diese Bedrohung entdeckt, bevor der bösartige Code in die stabilen Versionen von Linux gelangte, aber sie stellt dennoch ein Problem für diejenigen dar, die begonnen haben, die Versionen 5.6.0 und 5.6.1 von XZ Utils im Rahmen von Fedora Rawhide zu verwenden, und Organisationen werden aufgefordert, im Notfall vorrangig einen Patch zu installieren. Wäre diese Entdeckung nicht rechtzeitig gemacht worden, hätte das Risikoprofil dies zu einem der verheerendsten Angriffe gemacht, die jemals auf die Lieferkette verzeichnet wurden, und möglicherweise sogar SolarWinds in den Schatten gestellt.
Die Abhängigkeit von Freiwilligen aus der Community für die Wartung kritischer Systeme ist weithin dokumentiert, wird jedoch selten thematisiert, bevor Probleme mit starken Auswirkungen wie dieser Vorfall auftreten. Obwohl ihre unermüdliche Arbeit für die Wartung freier Software unerlässlich ist, zeigt dies doch, wie wichtig es ist, den Schwerpunkt ernsthaft auf die Sicherheitskompetenzen und das Sicherheitsbewusstsein der Entwickler zu legen und nicht zu vergessen, die Zugriffskontrollen für Software-Repositorys zu verstärken.
Was ist die Hintertür XZ Utils und wie wird sie abgeschwächt?
Am 29. März veröffentlichte Red Hat eine dringende Sicherheitswarnung, um Benutzer von Fedora Linux 4.0 und Fedora Rawhide darüber zu informieren, dass die neuesten Versionen der Komprimierungstools und „XZ”-Bibliotheken bösartigen Code enthalten, der offenbar speziell entwickelt wurde, um Dritten den unbefugten Zugriff zu erleichtern. Die Art und Weise, wie dieser bösartige Code eingeschleust wurde, wird wahrscheinlich in Zukunft eingehend untersucht werden, aber es handelt sich um eine ausgeklügelte, geduldige und langwierige Social-Engineering-Maßnahme seitens des Angreifers, einem pseudonymen Angreifer namens „Jia Tan”. Diese Person hat unzählige Stunden damit verbracht, das Vertrauen anderer Verantwortlicher zu gewinnen, über zwei Jahre lang legitime Beiträge zum Projekt und zur XZ Utils-Community zu leisten und schließlich den Status eines „vertrauenswürdigen Maintainers” zu erlangen, nachdem mehrere Fake-Accounts das Vertrauen in den ehrenamtlichen Projektleiter Lasse Collin untergraben hatten:
Dieses ungewöhnliche Szenario ist ein hervorragendes Beispiel dafür, dass selbst technisch versierte Personen Opfer von Taktiken werden, die normalerweise weniger erfahrenen Personen vorbehalten sind. Dies zeigt, wie wichtig eine präzise und rollenbasierte Sicherheitsschulung ist. Nur dank der Neugier und der Geistesgegenwart des Microsoft-Softwareentwicklers und PostgreSQL-Verantwortlichen Andrés Freund wurde die Hintertür entdeckt und die Versionen zurückgezogen, wodurch der möglicherweise verheerendste Angriff auf die Lieferkette in der jüngeren Geschichte verhindert werden konnte.
Die Hintertür selbst wird im NIST-Register offiziell als Schwachstelle mit dem höchstmöglichen Schweregrad eingestuft. Ursprünglich wurde angenommen, dass sie die Umgehung der SSH-Authentifizierung ermöglicht, doch eine eingehendere Untersuchung ergab, dass sie die Ausführung von nicht authentifiziertem Remote-Code auf anfälligen Linux-Systemen ermöglicht, darunter Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed und bestimmte Versionen von Debian.
Jia Tan scheint große Anstrengungen unternommen zu haben, um das bösartige Paket zu verbergen, das, wenn es während des Generierungsprozesses ausgelöst wird, die Authentifizierung in SSHD über systemd behindert. Wie Chapeau rouge ausführlich beschrieben, könnte diese Störung unter bestimmten Umständen einem Angreifer ermöglichen, die SSHD-Authentifizierung zu umgehen und sich unbefugten Fernzugriff auf das gesamte System zu verschaffen.
Microsoft, entre autres, a des directives complètes publiées sur l'analyse des systèmes à la recherche d'instances de l'exploit et sur l'atténuation de ses effets, et sur les mesures immédiates recommandées par CISA est que les développeurs et utilisateurs concernés doivent rétrograder XZ Utils vers une version non compromise, comme XZ Utils 5.4.6 Stable.
Es ist äußerst schwierig, diese Art von Angriffen zu verhindern, insbesondere wenn es um die Verwendung von Open-Source-Komponenten in Software geht, da die Sicherheit der Lieferkette sehr begrenzt und wenig transparent ist. Wir haben bereits mit versehentlichen Schwachstellen in der Software-Lieferkette zu kämpfen gehabt, aber dieses Risiko hat sich erhöht und umfasst nun auch absichtlich implantierte Sicherheitslücken, die darauf abzielen, die Sicherheit von freier Software zu kompromittieren.
Die meisten Entwickler werden nicht in der Lage sein, einen Angriff dieser Art zu stoppen, wenn sie nicht über ein ausgeprägtes Sicherheitsbewusstsein, fundierte Sicherheitskenntnisse und eine gewisse Paranoia verfügen. Es geht fast darum, eine Denkweise wie die eines Angreifers zu verlangen. Ein Hauptaugenmerk sollte jedoch immer auf intern kontrollierten Quellcode-Repositorys (d. h. nicht Open Source) liegen. Sie sollten nur Personen mit entsprechenden und überprüften Sicherheitskompetenzen zugänglich sein. AppSec-Fachleute können eine Konfiguration wie Sicherheitskontrollen auf Branch-Ebene in Betracht ziehen, die es nur sicherheitserfahrenen Entwicklern erlauben, Änderungen am endgültigen Hauptzweig vorzunehmen.
Freiwillige Maintainer sind Helden, aber es braucht (sollte es zumindest) ein ganzes Dorf, um eine Software sicher zu halten.
Für diejenigen, die nicht im Bereich Software-Engineering tätig sind, ist es schwer zu verstehen, dass eine dynamische Gemeinschaft von Freiwilligen kritische Systeme in ihrem eigenen Tempo sorgfältig wartet, aber das ist die Natur der Open-Source-Entwicklung, die weiterhin ein kritisches Risiko für Sicherheitsexperten darstellt, die die Lieferkette schützen.
Freie Software ist ein wesentlicher Bestandteil des digitalen Ökosystems praktisch aller Unternehmen, und vertrauenswürdige Verantwortliche (von denen die meisten in gutem Glauben handeln) zeigen wahren Heldenmut in ihrem selbstlosen Streben nach technologischem Fortschritt und Integrität, aber es ist lächerlich, sie isoliert arbeiten zu lassen. In Zeiten, in denen DevSecOps im Mittelpunkt steht, ist Sicherheit eine gemeinsame Verantwortung, und jeder Entwickler muss über das erforderliche Wissen und die geeigneten Tools verfügen, um Sicherheitsprobleme zu bewältigen, denen er im Laufe seines Arbeitstages begegnen kann. Sicherheitsbewusstsein und praktische Fähigkeiten sollten im Softwareentwicklungsprozess nicht verhandelbar sein, und es ist Aufgabe der Sicherheitsverantwortlichen, Veränderungen auf Unternehmensebene zu beeinflussen.
Schaffen Sie noch heute eine florierende Sicherheitskultur in Ihrem Unternehmen dank Kurs von Secure Code Warrior.
Inhaltsverzeichnis
Vorstandsvorsitzender, Chairman und Mitbegründer
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen, die Ihnen den Einstieg erleichtern
Themen und Inhalte der Schulung zum sicheren Code
Unsere hochmodernen Inhalte werden ständig weiterentwickelt, um mit den ständigen Veränderungen in der Softwareentwicklungslandschaft Schritt zu halten und gleichzeitig Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis hin zu XQuery-Injection und sind für eine Vielzahl von Positionen konzipiert, von Architekten über Ingenieure bis hin zu Produktmanagern und Qualitätssicherungsmitarbeitern. Verschaffen Sie sich einen Überblick über die Inhalte unseres Katalogs, sortiert nach Themen und Rollen.
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, die Ihnen den Einstieg erleichtern
Cybermon ist zurück: Die missions „Beat the Boss“ sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzen Sie fortschrittliche Sicherheitsherausforderungen im Zusammenhang mit KI und LLM ein, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet das für die Entwicklung sicherer Software bereits ab der Konzeption?
Entdecken Sie, was das europäische Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams durch Sicherheitsmaßnahmen bereits in der Entwurfsphase, durch die Vermeidung von Schwachstellen und durch die Stärkung der Fähigkeiten der Entwickler darauf vorbereiten können.
Moderator 1: Definierte und messbare Erfolgskriterien
Enabler 1 gibt den Startschuss für unsere 10-teilige Serie mit dem Titel „Enablers of Success“ und zeigt, wie sichere Codierung mit geschäftlichen Ergebnissen wie Risikominderung und Schnelligkeit kombiniert werden kann, um die langfristige Reife von Programmen sicherzustellen.
