Z

amieszanie w zależnościach pakietów (ang. dependency confusion) jest nowatorką metodą ataku na łańcuch dostaw (ang. supply chain attack). Atak na łańcuch dostaw (zwany także atakiem od trzeciej strony) ma miejsce, gdy ktoś infiltruje Twój system za pośrednictwem zewnętrznego partnera lub dostawcy, który ma dostęp do Twoich systemów i danych. Na przykład Twoja firma korzysta z jego oprogramowania lub usług, które dają mu dostęp do Twojej sieci. Gdy dochodzi do przełamania zabezpieczeń u partnera – atakujący jest w stanie rozprzestrzenić wektor ataku na wszystkich klientów danej firmy. Znaczenie tego ataku dla typowego przedsiębiorstwa w ciągu ostatnich kilku lat znacznie się zmieniło, ponieważ coraz więcej dostawców i usługodawców się integruje i dotyka wzajemnie wrażliwych danych. Ryzyko związane z łańcuchem dostaw nigdy nie było wyższe ze względu na nowe rodzaje ataków, co pokazuje zamieszanie w zależnościach pakietów. Rosnąca świadomość społeczna na temat zagrożeń powoli spycha napastników na nowy kierunek masowego rażenia. Dobrym przykładem jest niedawny atak SolarWinds.

Na czym polega technika związana z zamieszaniem w zależnościach? Otóż wykorzystuje ona fakt, że kawałek oprogramowania tworzonego przez daną firmę / instytucję może zawierać komponenty, które są mieszaniną prywatnych i publicznych źródeł. Zewnętrzne zależności pakietów, które są pobierane z repozytoriów publicznych podczas procesu kompilacji, mogą stanowić okazję do ataku, gdy agresor prześle wyższą wersję modułu prywatnego do publicznego źródła, powodując automatyczne pobranie fałszywej, nowszej wersji pakietu. Cały ten proces odbywa się bez jakichkolwiek działań od strony programisty. Alex Birsan, który przeprowadził skuteczny atak zdalnego wykonania kodu za pomocą tej metody na 35 dużych firmach (Microsoft, Apple, PayPal, Shopify, Netflix, Yelp, Tesla i Uber) tak opisuje ten proces:

Od jednorazowych błędów popełnianych przez programistów na ich własnych maszynach, przez źle skonfigurowane wewnętrzne lub oparte na chmurze serwery budowania i wydawania, aż po wrażliwe systemowo linie rozwoju oprogramowania, jedno było jasne: skłoting wewnętrznych nazw pakietów był niemal pewną metodą dostania się do sieci niektórych z największych firm technologicznych, uzyskania zdalnego wykonania kodu i prawdopodobnie umożliwiającą atakującemu dodanie backdoorów podczas procesu budowy pakietów.

Badacz atak standardowo rozpoczął od fazy rekonesansu. Zebrał nazwy prywatnych pakietów wewnętrznych używanych przez obrane przez siebie firmy za pomocą kodów źródłowych umieszczonych na GitHub, postów na różnych formach internetowych i plikach JavaScript, które zawierały listę zależności. Następnie przesłał sfabrykowane biblioteki o tych samych nazwach do usług hostujących pakiety open source takich jak: npm, PyPI (Python Package Index) i RubyGems. Nie musiał długo czekać. System budowy pakietów firmy Shopify zainstalował pakiet Ruby o nazwie “shopify-cloud” zaledwie kilka godzin po przesłaniu go na publiczne repozytorium RubyGems. Z kolegi pakiet Node, który przesłał do rejestru npm został wykonany na wielu komputerach w sieci Apple, wpływając na projekty związane z firmowym systemem uwierzytelniania Apple ID. Oczywiście Birsan nie wykonywał zdalnie kodu za pomocą sfałszowanych pakietów, tylko uzyskiwał zapis metadanych każdej maszyny, na której zostały one zainstalowane, aby mógł zgłaszać incydent odpowiednim firmom. Co ciekawe robił to za pomocą zapytań DNS. Wiedząc, że większość potencjalnych celów znajduje się głęboko w dobrze chronionych sieciach korporacyjnych, uznał, że najlepszym rozwiązaniem jest eksfiltracja DNS. W ten sposób prawdopodobieństwo zablokowania lub wykrycia ruchu przy wyjściu z sieci było mniejsze.

Obawa, że pakiet z wyższą wersją zostanie ściągnięty przez proces tworzenia aplikacji, niezależnie od tego, gdzie się znajduje nie umknął uwadze firmy Microsoft, który opublikował dokument “3 sposoby ograniczania ryzyka podczas korzystania z prywatnych pakietów danych”. Ostrzega on firmy przed hybrydowymi konfiguracjami menedżerów pakietów, w których używane są zarówno publiczne, jak i prywatne źródła bibliotek. Zawiera także szczegółowe informacje na temat szeregu środków zaradczych, które firmy mogą zastosować, aby uniknąć zamieszania w zależnościach w środowiskach budowy oprogramowania. Wśród niektórych z wymienionych zaleceń są:

• Odwoływanie się do jednego prywatnego źródła, a nie do wielu,
• Ochrona swoich prywatnych pakietów za pomocą dostępnych możliwości w publicznych repozytoriach pakietów,
• Korzystanie z funkcji weryfikacji po stronie klienta, takich jak przypinanie wersji i weryfikacja integralności.

W zeszłym roku William Bengtson dokonał podobnego badania odnoszącego się do ataków na łańcuch dostaw. Tylko jego metoda opierała się wykorzystaniu faktu popełniania literówek (ang. typosquatting) podczas pobierania różnych pakietów dla języka Python. W ciągu nieco ponad dwóch lat jego 1131 przerobionych pakietów pobrano 530.950 razy. Liczba ta nie obejmuje żadnych serwerów lustrzanych ani wewnętrznych rejestrów pakietów, które sklonowały te pakiety prywatnie. Szkodliwe pakiety w PyPI były już wcześniej znane z kradzieży danych uwierzytelniających przechowywanych w lokalnym systemie plików (patrz incydent z ssh-decorate). Gdyby pakiety oparte na literówce zostały napisane w złym zamiarze, oznaczałoby to, że pół miliona maszyn mogło zostać skompromitowanych w ciągu dwóch lat.

Więcej informacji: Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies