Supply-Chain-Angriffe – Bedrohungen und Schutzmechanismen (Teil 1)

• Die Verwendung von Frameworks und Bibliotheken ermöglicht es Entwicklern, sich auf das Wesentliche – den Business-Mehrwert – zu konzentrieren, statt das Rad an gewissen Stellen zum x-ten Mal neu zu erfinden.
• Die Nutzung von Managed Services, z. B. für Single Sign-on (SSO) oder Active Directory Services, ermöglicht es, bestehende Third-Party-Funktionalität in die eigene Anwendung zu integrieren, um ebenfalls den Fokus auf Business-Mehrwert legen zu können.
• Es ist zum De-facto-Standard geworden, dass Entwicklungsteams Container-Images verwenden, um ihre Anwendungen containerisiert auszuliefern; für die Container-Images wird in der Regel auf von anderen Unternehmen, Organisationen oder Einzelpersonen erstellte Images zurückgegriffen.

Diese Aufzählung ist als unvollständig anzusehen, was Komponenten angeht, die das Ziel von Supply-Chain-Angriffen sind! Sie soll uns jedoch als Anhaltspunkt für Angriffsvektoren, tatsächlich durchgeführte Supply-Chain-Angriffe sowie Schutzmassnahmen dienen.

Dass Supply-Chain-Angriffe zum einen eine sehr hohe Dynamik und zum anderen hohe Bedeutung haben und an Bedeutung zunehmen werden, zeigt eine Studie von Juniper Research [01]: Während 2023 der global geschätzte Schaden durch Supply-Chain-Angriffe bei ca. 45 Milliarden US-Dollar lag, erwarten die Autoren der Studie, dass dieser Schaden im Jahr 2026 bereits 81 Milliarden US-Dollar beträgt – mit steigender Tendenz in den Jahren nach 2026.

Für Unternehmen und Organisationen ist es deshalb essenziell, die Bedrohungen durch Supply-Chain-Angriffe zu kennen und zu wissen, wie man sich davor effektiv schützen kann!

Das Einbinden von Frameworks und Bibliotheken – in dieser Sektion als Abhängigkeiten zusammengefasst – ist ein fester Bestandteil der heutigen Softwareentwicklung. Die Gründe dafür sind unter anderem beträchtliche Effizienzsteigerungen, wie in der Einleitung dargestellt.

Im Folgenden beleuchten wir, welche Angriffsvektoren Abhängigkeiten für Supply-Chain-Angriffe bieten, welcher Schaden daraus entstehen und wie man sich gegen diese Angriffe schützen kann.

Angriffsvektoren

Aufgrund der Bedeutung von Abhängigkeiten versuchen Angreifer regelmässig und gezielt, bösartige Abhängigkeiten in Softwareprojekte einzuschleusen. Um das zu erreichen, nutzen Angreifer unter anderem folgende Möglichkeiten:

Möglichkeit 1: Angreifer erstellen ein bösartiges Paket in Anlehnung eines anderen weitverbreiteten gutartigen Pakets, wobei die Angreifer dem bösartigen Paket einen zum Verwechseln ähnlichen Namen geben. Das Vergeben solcher Namen ist als Typosquattingbekannt.

Die Firma Phylum bspw. deckte im Oktober 2024 eine Angriffskampagne auf, bei der das gutartige npm-Paket (1) namens «puppeteer», welches wöchentlich Millionen von Downloads verzeichnet [02], für solch einen Typosquatting-Angriff ausgewählt wurde. Die Angreifer veröffentlichten schädliche npm-Pakete unter den Namen «pupeter» und «pupetier» [03].

Die npm-Pakete «pupeter» und «pupetier» wurden nach dem Aufdecken der Kampagne aus der npm-Registry entfernt; auch deswegen wurden diese beiden Pakete zusammengezählt nur ca. ein Dutzend Mal heruntergeladen.

Möglichkeit 2: Angreifer erstellen ein bösartiges Paket und versuchen gezielt, dass es Entwickler einer ausgewählten Gruppe einbinden.

Ebenfalls die Firma Phylum deckte solch eine Kampagne im August 2023 auf [04]. Im Rahmen dieser von Phylum als «ausgeklügelt» bezeichneten Kampagne wurden in die npm-Registry unter anderem die Pakete «ynf-core-loader» und «ynf-dx-webpack-plugins» hochgeladen (2). Da diese Pakete nicht mittels Typosquatting benannt wurden, geht Phylum von einer gezielten Kampagne aus, die vermutlich mit Social Engineering kombiniert wurde, um das Paket gezielt bei bestimmten Personen zu installieren. Sofern diese Vermutung stimmt, bedeutet dies, dass die Angreifer Kontakt mit den Opfern hatten, um diese für das Einbinden der bösartigen Pakete zu überzeugen.

Möglicher Schaden

In der Regel verwenden Angreifer sogenannte Install Hooks, damit der eigentlich schädliche Code, für den die Pakete erstellt wurden, bereits während der Paket-Installation ausgeführt wird. Dieser schädliche Code kann z. B. eine Backdoor sein – also ein Mechanismus, mittels dessen sich die Angreifer einen für die Opfer nicht offensichtlichen, dauerhaften Zugang zum infiltrierten Entwicklerrechner schaffen.

Vom betroffenen Entwicklerrechner aus bieten sich den Angreifern nun verschiedene Möglichkeiten, unter anderem:

• Die Angreifer können Quellcode abgreifen – z. B. um sich Wettbewerbsvorteile zu verschaffen oder um Quellcode gezielt auf Schwachstellen zu untersuchen und damit gezielt produktive Systeme zu kompromittieren.
• Die Angreifer können das Entwicklersystem nutzen, um von dort aus Zugang zu weiteren firmen- oder organisationsinternen Systemen zu bekommen.

Wenn bösartige Pakete zu spät entdeckt werden, infiltrieren sie im Laufe der Zeit auch andere Entwicklerrechner oder gar CI-/CD-Systeme (Continuous Integration / Continuous Delivery).

Solch ein Befall macht eine umfassende Analyse notwendig, insbesondere im Hinblick auf die Systeme, auf die Angreifer Zugriff hatten resp. nach wie vor noch Zugriff haben. In der Regel ist eine vollständige Bereinigung/Neuinstallation der betroffenen Systeme notwendig. Dies ist ein immenser Schaden, ausgelöst nur durch das Hereinziehen einer Abhängigkeit in ein Softwareprojekt!

Entwickler selbst stellen gegen diesen Angriffsvektor die erste und wichtigste Verteidigungslinie dar. Insofern ist es naheliegend, dass Schutzmassnahmen Entwickler betreffen. Im Folgenden finden sich zwei Schutzmassnahmen; diese Liste ist als unvollständig anzusehen.

Schutzmassnahme 1: Braucht es wirklich eine neue Abhängigkeit?
Zuerst sollte das Entwicklungsteam die Frage klären, ob eine benötigte Funktionalität wirklich das Einbinden eines neuen Pakets erfordert.

Mittlerweile gibt es Pakete für viele kleine Funktionalitäten, wie das Prüfen einer Zeichenkette, ob diese eine Zahl darstellt [05]. Gerade im Hinblick auf die Sicherheit sollten Entwicklungsteams gut abwägen, ob sie ein Paket wirklich als Abhängigkeit einbinden wollen.

Es ist absolut vertretbar, eine Funktionalität zu entwickeln, für die es zwar schon ein Paket gibt, die aber einen begrenzten Scope hat, sodass man die Eigenentwicklung und Wartung dieser Funktionalität rechtfertigen kann.

Schutzmassnahme 2: Pakete prüfen!
Vor dem Einbinden eines neuen Pakets sollte dieses Paket von Entwicklern näher beleuchtet werden. Die Antworten auf folgende Fragen helfen dabei, einzuschätzen, ob ein Paket bösartig sein könnte:
1. Wie lange gibt es dieses Paket bereits?
2. Wie viele Downloads/Sterne/Forks hat dieses Paket?
3. Ist der Quellcode zu diesem Paket öffentlich einsehbar und fest mit einer bestimmten Version in der Paket-Registry verknüpft?
4. Welche offenen Issues und Kommentare gibt es zu diesem Paket?

Die Antworten auf diese Fragen geben aber keine 100-prozentige Sicherheit. Das zeigte bspw. das Hinzufügen einer Backdoor in die weitverbreitete Bibliothek xz [06].

Wie oben beschrieben, können Supply-Chain-Angriffe mit Social Engineering kombiniert werden und werden so noch gefährlicher. Der Schutz vor Social Engineering ist ein eigenes Feld, über das ganze Bücher geschrieben wurden [07], sodass wir hier nicht weiter darauf eingehen.

SBOM ist das Akronym für «Software Bill of Materials» (Deutsch: Software-Stückliste). Eine SBOM listet unter anderem alle eingebundenen Abhängigkeiten inkl. deren Versionen und transitiven Abhängigkeiten auf. Mittels dieser Informationen kann man nun die Abhängigkeiten gegen Listen bekannter Schwachstellen prüfen, um zu sehen, ob Bedrohungen vorliegen.

SBOMs stellen damit jedoch keinen Schutz gegen bösartige Pakete dar! Denn damit ein Paket als Abhängigkeit in einer SBOM auftaucht, muss es zuerst den Abhängigkeiten einer Software hinzugefügt worden sein. Wie jedoch oben beschrieben, führen viele bösartige Pakete ihren Schadcode bereits während der Installation aus.

SBOMs können damit lediglich aufdecken, dass ein böswilliges Paket eingebunden wurde, und stellen somit keinen direkten Schutz dar.

Zusammenfassung

Dieser Blog-Beitrag hat in Supply-Chain-Angriffe eingeführt, einige der vielen Supply-Chain-Angriffsvektoren grob vorgestellt sowie den Angriffsvektor «Frameworks und Bibliotheken» im Detail beleuchtet.

In einem zweiten Blog-Beitrag werden wir weitere Angriffsvektoren, deren Auswirkungen und Schutzmassnahmen betrachten.

Referenzen

(1) npm steht für Node Package Manager und ist ein Paketmanager im JavaScript-/TypeScript-Ökosystem.
(2) Die npm-Registry ist aufgrund ihrer weiten Verbreitung ein häufiges Angriffsziel. Andere Paket-Registries können theoretisch und werden praktisch ebenfalls für diese Angriffe missbraucht.

[01]​ https://www.juniperresearch.com/press/study-reveals-staggering-cost-of-software-supply/
[02] ​https://www.npmjs.com/package/puppeteer
[03]​ https://blog.phylum.io/supply-chain-security-typosquat-campaign-targeting-puppeteer-users/
[04]​ https://blog.phylum.io/sophisticated-highly-targeted-attacks-continue-to-plague-npm/
[05]​ https://www.npmjs.com/package/is-number
[06]​ https://www.heise.de/hintergrund/Die-xz-Hintertuer-das-verborgene-Oster-Drama-der-IT-9673038.html
[07]​ https://www.mitp.de/Unsere-Autoren/Kevin-D-Mitnick/Die-Kunst-der-Taeuschung.html