Dependency Confusion

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

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

Podstawowe informacje

Podsumowując, podatność na dependency confusion występuje, gdy projekt używa biblioteki o błędnie napisanej nazwie, nieistniejącej lub z nieokreśloną wersją, a repozytorium zależności pozwala na pobieranie zaktualizowanych wersji z publicznych repozytoriów.

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

Wykorzystanie

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

Błędnie napisane i nieistniejące

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

Nieokreślona wersja

Często programiści nie określają żadnej wersji używanej biblioteki lub określają tylko główną wersję. Wtedy interpreter spróbuje pobrać najnowszą wersję, która spełnia te wymagania.
Jeśli biblioteka jest znajomą zewnętrzną biblioteką (jak python requests), atakujący nie może zbyt wiele zrobić, ponieważ nie będzie mógł stworzyć biblioteki o nazwie requests (chyba że jest jej oryginalnym autorem).
Jednak 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 wersji dostępnej publicznie.
Więc jeśli atakujący wie, że firma używa biblioteki requests-company wersja 1.0.1 (zezwala na mniejsze aktualizacje), może opublikować bibliotekę requests-company wersja 1.0.2, a 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, umożliwiając określenie, czy biblioteka jest wewnętrzna czy zewnętrzna, aby uniknąć pobierania wewnętrznych zależności z zewnętrznych repozytoriów.

Wyszukiwanie podatnych bibliotek

W oryginalnym poście o dependency confusion autor wyszukiwał tysiące publicznie dostępnych plików package.json zawierających zależności projektów JavaScript.

Odwołania