Risiken bei der Nutzung quelloffener Komponenten Die Open-Source-Lieferkette als Einfallstor

Von Kevin Bocek *

Anbieter zum Thema

Im Zuge der digitalen Transformation vertrauen Unternehmen immer stärker auf Cloud-native Software, die Open-Source-Komponenten nutzt. Böswillige Akteure wissen das und sehen darin eine große Chance.

Neben Sicherheitsprozessen in der Entwicklung ist es auch wichtig, Open-Source-Quellen abzusichern und Manipulationen zu erkennen.
Neben Sicherheitsprozessen in der Entwicklung ist es auch wichtig, Open-Source-Quellen abzusichern und Manipulationen zu erkennen.
(© artinspiring - stock.adobe.com)

Im vergangenen Jahr ist die Zahl der Angriffe auf Open-Source-Komponenten zur Infizierung von Software-Lieferketten laut einer Studie des Anbieters Sonatype im Vergleich zum Vorjahr um 430 Prozent gestiegen. Cyber-Kriminelle bewegen sich „stromaufwärts“, um die Quelle der Software anzugreifen. Sie biegen dann links ab, um die Entwickler ins Visier zu nehmen. Dadurch erhöht sich die Anzahl der Ziele, die sie infizieren können, ohne dass der Arbeitsaufwand steigt.

Die Infiltrierung von Open-Source-Bibliotheken kann auch ein verdeckter Ansatz sein als ein direkter Angriff auf Organisationen, denn wenn sie bereits Teil einer vertrauenswürdigen Lieferkette sind, werden ihre bösartigen Aktivitäten 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. Der Bericht stellt fest, dass kommerzieller Code heute hauptsächlich aus Open-Source-Software besteht. Wenn böswillige Akteure erfolgreich sind, können sie mit diesen Angriffen sowohl Maschinenidentitäten 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, so dass es nicht möglich ist, jede einzelne in der Geschwindigkeit der Entwickler zu verifizieren.

Letztendlich liegt die Chance, die Softwareentwicklung erfolgreich zu schützen, in den Händen der Entwickler. Die Zukunft liegt darin, den 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. Es gibt schlicht keinen Grund für die Annahme, dass eine zuvor vertrauenswürdige Lieferkette verändert wurde oder möglicherweise nicht rechtmäßig ist.

Unternehmen sind heute auf Schnelligkeit bedacht. Entwickler beschleunigen deshalb 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 und enthalten in der Regel Elemente aus anderen Open-Source-Projekten. Dies kann dazu führen, dass der Code versehentlich 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 kein Überprüfungs- und Genehmigungsverfahren gibt, entwickeln sich diese langsam zu kostenlosen Malware-Hosting-Services.

Eine der häufigsten Angriffstechniken ist das Typosquatting, bei dem Namen nachgeahmt werden, die häufig verwendeten Paketen ähneln. Die Idee der Angreifer ist hierbei, dass Entwickler und Administratoren versehentlich den beabsichtigten Namen falsch eingeben und das bösartige Paket installieren.

Beispiele dafür sind 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, Maschinenidentitä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 wurden und potenziell unerwünschte Anwendungen (PUA) enthielten. Sie waren entweder in den Image-Schichten versteckt oder wurden während der Laufzeit in die instanziierten Container heruntergeladen.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Softwareentwicklung und DevOps

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

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 lassen sich Angriffe verhindern?

Entwickler sind sich oft 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 ohnehin schon überforderten 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.

In Zusammenarbeit mit Ingenieuren von Cloudbees, Veracode und Sophos stellt Venafi ein Open-Source-Konzept für die Sicherung von Software zur Verfügung. Das Konzept wurde von Entwicklern für Entwickler entwickelt, um einen unmittelbaren Einfluss auf die Sicherheit zu haben. Nutzung, Feedback und Beiträge sind hier erwünscht.

Fazit: Codesignierung muss standardisiert werden

Kevin Bocek
Kevin Bocek
(Bild: Venafi)

Wenn die Sicherheitsverfahren rund um das Codesigning nicht schnell in Angriff genommen werden, werden Angriffe, die Open-Source-Softwaretechniken nutzen, nur noch häufiger und erfolgreicher werden. Unternehmen müssen sicherstellen, dass die Entwickler mit der Automatisierung und den 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 neu eingereichten Code überprüfen.

* Kevin Bocek ist VP Security Strategy & Threat Intelligence bei Venafi.

(ID:47641689)