Dependency Confusion
Reading time: 3 minutes
tip
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Unterstützen Sie HackTricks
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.
Grundinformationen
Zusammenfassend tritt eine Dependency Confusion-Sicherheitsanfälligkeit auf, wenn ein Projekt eine Bibliothek mit einem falsch geschriebenen Namen, nicht existierenden oder mit einer nicht angegebenen Version verwendet und das verwendete Abhängigkeitsrepository es erlaubt, aktualisierte Versionen aus öffentlichen Repositories zu sammeln.
- Falsch geschrieben: Importiere
reqests
anstelle vonrequests
- Nicht existent: Importiere
company-logging
, eine interne Bibliothek, die nicht mehr existiert - Nicht angegebene Version: Importiere eine interne existierende
company-requests
-Bibliothek, aber das Repo überprüft öffentliche Repos, um zu sehen, ob es größere Versionen gibt.
Ausnutzung
warning
In allen Fällen muss der Angreifer nur ein bösartiges Paket mit dem Namen der von der Opferfirma verwendeten Bibliotheken veröffentlichen.
Falsch geschrieben & Nicht existent
Wenn deine Firma versucht, eine Bibliothek zu importieren, die nicht intern ist, wird das Bibliotheksrepo höchstwahrscheinlich danach in öffentlichen Repositories suchen. Wenn ein Angreifer sie erstellt hat, ist es sehr wahrscheinlich, dass dein Code und die laufenden Maschinen kompromittiert werden.
Nicht angegebene Version
Es ist sehr häufig, dass Entwickler keine Version der verwendeten Bibliothek angeben oder nur eine Hauptversion angeben. Dann versucht der Interpreter, die neueste Version herunterzuladen, die diesen Anforderungen entspricht.
Wenn die Bibliothek eine bekannte externe Bibliothek (wie python requests
) ist, kann ein Angreifer nicht viel tun, da er keine Bibliothek mit dem Namen requests
erstellen kann (es sei denn, er ist der ursprüngliche Autor).
Wenn die Bibliothek jedoch intern ist, wie requests-company
in diesem Beispiel, und das Bibliotheksrepo es erlaubt, auch extern nach neuen Versionen zu suchen, wird es nach einer neueren Version suchen, die öffentlich verfügbar ist.
Wenn ein Angreifer weiß, dass die Firma die requests-company
-Bibliothek Version 1.0.1 verwendet (kleine Updates erlaubt). Kann er die Bibliothek requests-company
Version 1.0.2 veröffentlichen und die Firma wird diese Bibliothek anstelle der internen verwenden.
AWS Fix
Diese Sicherheitsanfälligkeit wurde in AWS CodeArtifact gefunden (lies die Details in diesem Blogbeitrag).
AWS hat dies behoben, indem es erlaubt, anzugeben, ob eine Bibliothek intern oder extern ist, um zu vermeiden, dass interne Abhängigkeiten aus externen Repositories heruntergeladen werden.
Finden von verwundbaren Bibliotheken
Im ursprünglichen Beitrag über Dependency Confusion suchte der Autor nach Tausenden von exponierten package.json-Dateien, die die Abhängigkeiten von JavaScript-Projekten enthielten.
Referenzen
- https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
- https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d
tip
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Unterstützen Sie HackTricks
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.