hacktricks/pentesting-web/dependency-confusion.md
2024-02-10 15:36:32 +00:00

6 KiB

Abhängigkeitsverwirrung

Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Grundlegende Informationen

Zusammenfassend tritt eine Abhängigkeitsverwirrung auf, wenn ein Projekt eine Bibliothek mit einem falsch geschriebenen Namen, einer nicht vorhandenen oder einer nicht spezifizierten Version verwendet und das verwendete Abhängigkeitsrepository das Sammeln von aktualisierten Versionen aus öffentlichen Repositories ermöglicht.

  • Falsch geschrieben: Importieren Sie reqests anstelle von requests
  • Nicht vorhanden: Importieren Sie company-logging, eine interne Bibliothek, die nicht mehr existiert
  • Nicht spezifizierte Version: Importieren Sie eine interne vorhandene company-requests-Bibliothek, aber das Repository überprüft öffentliche Repositories, um festzustellen, ob es höhere Versionen gibt.

Ausnutzung

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

Falsch geschrieben & Nicht vorhanden

Wenn Ihr Unternehmen versucht, eine nicht interne Bibliothek zu importieren, wird das Repository der Bibliotheken höchstwahrscheinlich in öffentlichen Repositories danach suchen. Wenn ein Angreifer es erstellt hat, wird Ihr Code und die ausgeführten Maschinen höchstwahrscheinlich kompromittiert.

Nicht spezifizierte Version

Es ist sehr üblich, 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 ist (wie Python requests), 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 in diesem Beispiel requests-company, und das Bibliotheksrepository das Überprüfen neuer Versionen auch extern zulässt, wird nach einer neueren öffentlich verfügbaren Version gesucht.
Wenn ein Angreifer weiß, dass das Unternehmen die requests-company-Bibliothek Version 1.0.1 verwendet (geringfügige Updates zulässt), kann er die Bibliothek requests-company Version 1.0.2 veröffentlichen und das Unternehmen wird diese Bibliothek anstelle der internen verwenden.

AWS-Behebung

Diese Schwachstelle wurde in AWS CodeArtifact gefunden (lesen Sie die Details in diesem Blog-Beitrag).
AWS hat dies behoben, indem es ermöglicht wurde, anzugeben, ob eine Bibliothek intern oder extern ist, um das Herunterladen interner Abhängigkeiten aus externen Repositories zu vermeiden.

Suche nach verwundbaren Bibliotheken

In dem ursprünglichen Beitrag zur Abhängigkeitsverwirrung hat der Autor nach Tausenden von freigegebenen package.json-Dateien gesucht, die Abhängigkeiten von JavaScript-Projekten enthalten.

Referenzen

Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!