Abhängigkeitsverwirrung

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

Arbeiten Sie in einem Cybersicherheitsunternehmen? Möchten Sie Ihr Unternehmen in HackTricks beworben sehen? oder möchten Sie Zugriff auf die neueste Version des PEASS oder HackTricks als PDF herunterladen? Überprüfen Sie die ABONNEMENTPLÄNE!
Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs
Holen Sie sich das offizielle PEASS & HackTricks-Merch
Treten Sie der 💬 Discord-Gruppe bei (https://discord.gg/hRep4RUj7f) oder der Telegram-Gruppe (https://t.me/peass) bei oder folgen Sie mir auf Twitter 🐦@carlospolopm.
Teilen Sie Ihre Hacking-Tricks, indem Sie PRs zum HackTricks-Repo und HackTricks-Cloud-Repo einreichen.

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

Grundlegende Informationen

Zusammengefasst tritt eine Abhängigkeitsverwirrung auf, wenn ein Projekt eine Bibliothek mit einem falsch geschriebenen Namen, nicht existierendem oder nicht spezifizierter Version verwendet und das verwendete Abhängigkeits-Repository es erlaubt, aktualisierte Versionen aus öffentlichen Repositories zu sammeln.

Falsch geschrieben: Importiere reqests anstelle von requests
Nicht existierend: Importiere company-logging, eine interne Bibliothek, die nicht mehr existiert
Nicht spezifizierte 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

{% hint style="warning" %} In allen Fällen muss der Angreifer nur ein bösartiges Paket mit dem Namen der Bibliotheken veröffentlichen, die vom Opferunternehmen verwendet werden. {% endhint %}

Falsch geschrieben & Nicht existierend

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

Nicht spezifizierte Version

Es ist sehr üblich, dass Entwickler keine Version spezifizieren 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 ist (wie Python requests), kann ein Angreifer nicht viel tun, da er keine Bibliothek namens 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 Bibliotheks-Repo es erlaubt, auch extern nach neuen Versionen zu suchen, wird nach einer öffentlich verfügbaren neueren Version gesucht.
Wenn ein Angreifer weiß, dass das Unternehmen die requests-company-Bibliothek Version 1.0.1 verwendet (geringe 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 Fix

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 suchte der Autor nach Tausenden von freigegebenen package.json-Dateien, die die Abhängigkeiten von JavaScript-Projekten enthalten.

Referenzen