Dependency Confusion
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
In allen Fällen muss der Angreifer nur ein bösartiges Paket mit dem Namen der von der Opferfirma verwendeten Bibliotheken veröffentlichen.
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.
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.
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.
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.
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
