Dependency Confusion

{% hint style="success" %} Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Überprüfe die Abonnementpläne!
Tritt der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @hacktricks_live.
Teile Hacking-Tricks, indem du PRs zu den HackTricks und HackTricks Cloud GitHub-Repos einreichst.

{% endhint %}

{% embed url="https://websec.nl/" %}

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 von requests
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 neuere Versionen gibt.

Ausnutzung

{% hint style="warning" %} In allen Fällen muss der Angreifer nur ein bösartiges Paket mit dem Namen der von der Opferfirma verwendeten Bibliotheken veröffentlichen. {% endhint %}

Falsch geschrieben & Nicht existent

Wenn deine Firma versucht, eine Bibliothek zu importieren, die nicht intern ist, wird das Bibliotheksrepo wahrscheinlich in öffentlichen Repositories danach suchen. Wenn ein Angreifer sie erstellt hat, wird dein Code und die laufenden Maschinen höchstwahrscheinlich kompromittiert sein.

Nicht angegebene Version

Es ist sehr häufig, dass Entwickler keine Version der verwendeten Bibliothek angeben oder nur eine Hauptversion angeben. Dann wird der Interpreter versuchen, 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