Dependency-Confusion-Angriff
Was ist Dependency-Confusion-Angriff?
Dependency-Confusion-AngriffSupply-Chain-Angriff, bei dem ein Angreifer ein bösartiges Paket mit dem Namen einer internen Abhängigkeit in einer öffentlichen Registry veröffentlicht, sodass Build-Tools die öffentliche Version laden.
Dependency Confusion nutzt das Standardverhalten von Paketmanagern (npm, pip, Maven, NuGet, RubyGems u. a.), die öffentliche und private Registries kombinieren. Der Angreifer ermittelt den Namen eines internen Pakets (geleakte Manifeste, öffentliche Repos, DNS), veröffentlicht in der öffentlichen Registry ein Paket gleichen Namens mit höherer Version und wartet, bis Build-Agents es einziehen. Alex Birsans Forschung 2021 zeigte, dass dutzende Großunternehmen anfällig waren. Gegenmaßnahmen sind unter anderem: explizite Registry-Scopes (npm Scoped Packages, NuGet Upstream Feeds, pip --index-url), Veröffentlichung interner Platzhalter in öffentlichen Registries, Blockieren ausgehender Auflösung, Paket-Signaturen mit Sigstore oder PGP sowie der Konsum über ein kuratiertes Artefakt-Repository, das Name und Quelle bindet. SLSA, SBOMs und kontinuierliches Monitoring neuer öffentlicher Pakete helfen ebenfalls.
● Beispiele
- 01
Internes Paket internal-utils wird durch ein bösartiges internal-utils@99.0.0 in npm ersetzt.
- 02
Build-Pipeline lädt pip-Abhängigkeit von PyPI statt aus dem privaten Index.
● Häufige Fragen
Was ist Dependency-Confusion-Angriff?
Supply-Chain-Angriff, bei dem ein Angreifer ein bösartiges Paket mit dem Namen einer internen Abhängigkeit in einer öffentlichen Registry veröffentlicht, sodass Build-Tools die öffentliche Version laden. Es gehört zur Kategorie Anwendungssicherheit der Cybersicherheit.
Was bedeutet Dependency-Confusion-Angriff?
Supply-Chain-Angriff, bei dem ein Angreifer ein bösartiges Paket mit dem Namen einer internen Abhängigkeit in einer öffentlichen Registry veröffentlicht, sodass Build-Tools die öffentliche Version laden.
Wie funktioniert Dependency-Confusion-Angriff?
Dependency Confusion nutzt das Standardverhalten von Paketmanagern (npm, pip, Maven, NuGet, RubyGems u. a.), die öffentliche und private Registries kombinieren. Der Angreifer ermittelt den Namen eines internen Pakets (geleakte Manifeste, öffentliche Repos, DNS), veröffentlicht in der öffentlichen Registry ein Paket gleichen Namens mit höherer Version und wartet, bis Build-Agents es einziehen. Alex Birsans Forschung 2021 zeigte, dass dutzende Großunternehmen anfällig waren. Gegenmaßnahmen sind unter anderem: explizite Registry-Scopes (npm Scoped Packages, NuGet Upstream Feeds, pip --index-url), Veröffentlichung interner Platzhalter in öffentlichen Registries, Blockieren ausgehender Auflösung, Paket-Signaturen mit Sigstore oder PGP sowie der Konsum über ein kuratiertes Artefakt-Repository, das Name und Quelle bindet. SLSA, SBOMs und kontinuierliches Monitoring neuer öffentlicher Pakete helfen ebenfalls.
Wie schützt man sich gegen Dependency-Confusion-Angriff?
Schutzmaßnahmen gegen Dependency-Confusion-Angriff kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Dependency-Confusion-Angriff?
Übliche alternative Bezeichnungen: Namespace-Confusion, Substitutionsangriff.
● Verwandte Begriffe
- appsec№ 1069
Software-Supply-Chain-Sicherheit
Disziplin zum Schutz jedes Glieds der Software-Produktion - Quellcode, Abhängigkeiten, Build, Signatur, Distribution und Deployment - gegen Manipulation, bösartigen Code und Integritätsverlust.
- attacks№ 1116
Supply-Chain-Angriff
Angriff, der einen vertrauenswürdigen Software-, Hardware- oder Dienstleister kompromittiert, um dessen nachgelagerte Kunden zu erreichen.
- attacks№ 1184
Typosquatting
Registrieren von Domain- oder Paketnamen, die Tipp- oder Sichtfälschungen legitimer Namen sind, um Nutzer und Entwickler abzufangen, die sich vertippen oder verlesen.
- appsec№ 305
Dependency Pinning
Die Praxis, Software-Abhängigkeiten auf exakte Versionen festzuschreiben, häufig zusammen mit kryptografischen Hashes, damit Builds stets dieselben Artefakte verwenden und resilient gegen Lieferketten-Manipulation sind.
- appsec№ 971
SCA (Software Composition Analysis)
Automatisierte Analyse der Open-Source- und Drittanbieterkomponenten einer Anwendung, um bekannte Schwachstellen, Lizenzprobleme und veraltete oder riskante Abhängigkeiten zu erkennen.
- appsec№ 784
Paketsignatur
Anbringen einer kryptografischen Signatur an einem Softwarepaket, damit Konsumenten Veröffentlicher und Unversehrtheit des Artefakts überprüfen können.
● Siehe auch
- № 1097Starjacking
- № 647Schaedliches npm-Paket
- № 1183Typosquatted Package