Dependency Confusion
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
reqestsanstelle vonrequestsNicht existent: Importiere
company-logging, eine interne Bibliothek, die nicht mehr existiertNicht 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
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 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
Last updated