Supply Chains
Hinterlassen Open-Source-Lieferketten Sicherheitslücken im Unternehmen?
Von Kevin Bocek, Vice President, Security Strategy & Threat Intelligence bei Venafi
Im vergangenen Jahr ist die Zahl der Angriffe auf Open-Source-Komponenten zur Infizierung von Software-Lieferketten im Vergleich zum Vorjahr um 430 Prozent gestiegen. Im Zuge der digitalen Transformation sind Unternehmen immer stärker auf Cloud-native Software angewiesen, die Open-Source-Komponenten nutzt. Böswillige Akteure wissen das und sehen darin eine große Chance. Sie bewegen sich „stromaufwärts“, um die Quelle der Software anzugreifen, und nehmen durch „Shift Left“ die Entwickler ins Visier, die die Software erstellen. So erhöht sich die Zahl der Ziele, die sie infizieren können, exponentiell, ohne dass der Arbeitsaufwand steigt.
Die Infiltrierung von Open-Source-Bibliotheken kann auch ein Ansatz sein, der verdeckter als ein direkter Angriff auf Organisationen ist, denn wenn sie bereits Teil einer vertrauenswürdigen Lieferkette sind, werden ihre bösartigen Aktivitäten nicht entdeckt. Ein direkter Angriff auf ein Unternehmen ist schwieriger und führt in der Regel zu langsameren und weniger guten Ergebnissen. Der Bericht „2020 Open Source Security and Risk Analysis“ von Synopsys hat gezeigt, wie effektiv diese Taktik sein kann. Im Bericht wird festgestellt, dass der meiste kommerzielle Code heute hauptsächlich aus Open-Source-Software besteht.
Wenn böswillige Akteure erfolgreich sind, können sie mit diesen Angriffen sowohl die Identität von Computern als auch sensible Daten stehlen. Obwohl die Folgen dieser Angriffe verheerend sein können, gibt es immer noch keine Sicherheitsstandards für Open-Source-Software. Jedes Stück Software in einer Open-Source-Bibliothek sollte mit einem Codesigning-Zertifikat (auch bekannt als Codesigning-Maschinenidentität) authentifiziert werden. Heutzutage werden Codesigning-Maschinen-Identitäten jedoch nicht gut verwaltet, sodass es nicht möglich ist, jede einzelne in der Geschwindigkeit der Entwickler zu überprüfen.
Letztendlich liegt die Chance, die Softwareentwicklung erfolgreich zu schützen, in den Händen der Entwickler. Die Zukunft liegt darin, Ingenieuren einen einfachen und schnellen Schutz innerhalb der Software-Pipelines zu ermöglichen und die Sicherheit der entwickelten Produkte zu gewährleisten.
Verdeckte Operationen
Angriffe auf die Software-Lieferkette sind sehr schwer zu erkennen, da es keinen Grund für den Verdacht gibt, dass eine zuvor vertrauenswürdige Lieferkette verändert wurde oder möglicherweise nicht rechtmäßig ist. Da Unternehmen heute auf Schnelligkeit bedacht sind, beschleunigen Entwickler ihre Prozesse, indem sie Funktionen nutzen, die in Softwarebibliotheken oder -modulen implementiert sind, die zuvor von jemand anderem geschrieben wurden (und die bereits nachweislich korrekt funktionieren). Diese Projekte beruhen auf Beiträgen von freiwilligen Entwicklern und enthalten in der Regel Elemente aus anderen Open-Source-Projekten. Das kann dazu führen, dass der Code unabsichtlich missbraucht wird, da bekannte Schwachstellen versehentlich oder absichtlich durch das Hinzufügen von bösartigem Code eingebaut werden können. Für ein Unternehmen ist es einfach unmöglich, jeden einzelnen Code zu überprüfen, um eine Schwachstelle oder eine Bedrohung zu entdecken. Indem sie diese Repositories ins Visier nehmen, vergrößern die Angreifer die Angriffsfläche erheblich. Da es für die Open-Source-Paket-Repositories keinen Überprüfungs- und Genehmigungsprozess gibt, werden diese langsam zu einem kostenlosen Malware-Hosting-Service.
Eine der häufigsten Angriffstechniken ist das Typosquatting, bei dem Namen nachgeahmt werden, die häufig verwendeten Paketen sehr ähnlich sind. Die Hoffnung ist, dass Entwickler und Administratoren versehentlich den beabsichtigten Namen falsch eingeben und das bösartige Paket installieren. Zum Beispiel python-dateutil und jeIlyfish (mit einem großen I statt einem L). Diese Pakete verhalten sich dann genauso wie die Originale, mit dem Unterschied, dass sie auch versuchen, Rechneridentitäten und andere sensible Informationen vom Entwickler oder Benutzer ihrer Software zu stehlen.
In einem weiteren Beispiel für eine aktuelle Bedrohung entdeckte Aqua Security eine Infrastruktur von 23 Container-Images, die in Docker Hub gespeichert sind und potenziell unerwünschte Anwendungen (PUA) enthalten, die entweder in den Image-Schichten versteckt sind oder während der Laufzeit in die instanziierten Container heruntergeladen werden. Docker Hub ist ein beliebtes Open-Source-Repository für Container-Images und wird im Entwicklungszyklus häufig eingesetzt. Entwickler integrieren häufig ihre CI/CD-Pipeline mit Docker Hub, um automatische Image-Builds auszulösen und neue Images als Teil des CI/CD-Workflows direkt im Repository zu veröffentlichen. Wenn es Angreifern gelingt, ein Image zu kompromittieren, könnten sie effektiv eine große Benutzerbasis gefährden.
Wie können Angriffe verhindert werden?
Entwickler, die so schnell wie möglich vorankommen wollen, sind sich des Risikos, das diese Repositories darstellen, nicht bewusst. Mit mehr Sicherheitsregeln und einer Standardisierung bei der Verwendung von Codesigning in Open Source könnten diese Paketprobleme jedoch verhindert werden. Es ist jetzt von entscheidender Bedeutung, dass die Entwickler einen Überprüfungsprozess in ihren Arbeitsablauf einbauen, zusammen mit einer Überprüfung auf bekannte Schwachstellen.
Allerdings darf nicht die gesamte Last auf die bereits überlasteten Softwareentwickler abgewälzt werden, da es für sie weder zumutbar noch realistisch ist, jeden einzelnen Code zu überprüfen. Die Verwalter von Open-Source-Repositories müssen einen Überprüfungs- und Genehmigungsprozess für jeden eingereichten Code einführen, da sie sonst Gefahr laufen, zu einem zuverlässigen und skalierbaren Malware-Verbreitungskanal zu werden.
Codesigning muss standardisiert werden
Wenn die Sicherheitsverfahren rund um das Codesigning nicht schnell angegangen werden, dann werden Angriffe, die Open-Source-Softwaretechniken nutzen, noch viel häufiger und verheerender. Unternehmen müssen sicherstellen, dass die Entwickler mit der Automatisierung und klaren Prozessen ausgestattet sind, die erforderlich sind, um Sicherheits- und Schwachstellenprüfungen in neue Software einzubauen; auch die Repositories müssen die Last übernehmen und den neu eingereichten Code überprüfen.
