Dependency Confusion

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Czy pracujesz w firmie zajmującej się cyberbezpieczeństwem? Chcesz zobaczyć swoją firmę reklamowaną na HackTricks? lub chcesz uzyskać dostęp do najnowszej wersji PEASS lub pobrać HackTricks w formacie PDF? Sprawdź PLANY SUBSKRYPCYJNE!
Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
Zdobądź oficjalne gadżety PEASS & HackTricks
Dołącz do 💬 grupy Discord lub grupy telegramowej albo śledź mnie na Twitterze 🐦@carlospolopm.
Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do repozytorium hacktricks i repozytorium hacktricks-cloud.

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

Podstawowe informacje

W skrócie, podatność na dependency confusion występuje, gdy projekt używa biblioteki z błędnie napisaną nazwą, nieistniejącą lub z nieokreśloną wersją, a repozytorium użytej zależności pozwala na pobieranie zaktualizowanych wersji z publicznych repozytoriów.

Błędnie napisana: Importuj reqests zamiast requests
Nieistniejąca: Importuj company-logging, wewnętrzną bibliotekę, która już nie istnieje
Nieokreślona wersja: Importuj wewnętrzną istniejącą bibliotekę company-requests, ale sprawdź repozytorium publiczne repozytoria, aby zobaczyć, czy są nowsze wersje.

Wykorzystanie

{% hint style="warning" %} W każdym przypadku atakujący musi tylko opublikować złośliwy pakiet o nazwie używanej przez firmę ofiary. {% endhint %}

Błędnie napisana & Nieistniejąca

Jeśli twoja firma próbuje importować bibliotekę, która nie jest wewnętrzna, bardzo prawdopodobne jest, że repozytorium bibliotek będzie próbować jej znaleźć w publicznych repozytoriach. Jeśli atakujący ją stworzył, twój kod i uruchomione maszyny są bardzo prawdopodobnie zagrożone.

Nieokreślona wersja

Bardzo często deweloperzy nie określają żadnej wersji używanej biblioteki, lub określają tylko główną wersję. W takim przypadku interpreter spróbuje pobrać najnowszą wersję, spełniającą te wymagania.
Jeśli biblioteka jest znaną zewnętrzną biblioteką (jak python requests), atakujący nie może zrobić wiele, ponieważ nie będzie mógł stworzyć biblioteki o nazwie requests (chyba że jest jej oryginalnym autorem).
Jednakże, jeśli biblioteka jest wewnętrzna, jak requests-company w tym przykładzie, jeśli repozytorium biblioteki pozwala na sprawdzanie nowych wersji również zewnętrznie, będzie szukać nowszej publicznie dostępnej wersji.
Więc jeśli atakujący wie, że firma używa biblioteki requests-company wersja 1.0.1 (zezwala na aktualizacje mniejsze). Może opublikować bibliotekę requests-company wersja 1.0.2 i firma będzie używać tej biblioteki zamiast wewnętrznej.

Naprawa w AWS

Ta podatność została znaleziona w AWS CodeArtifact (przeczytaj szczegóły w tym wpisie na blogu).
AWS naprawiło to, pozwalając określić, czy biblioteka jest wewnętrzna czy zewnętrzna, aby uniknąć pobierania wewnętrznych zależności z zewnętrznych repozytoriów.

Znajdowanie podatnych bibliotek

W oryginalnym poście o dependency confusion autor szukał tysięcy odsłoniętych plików package.json zawierających zależności projektów JavaScript.

Odnośniki