Skoordynowany atak na łańcuch dostaw uderzył w kilka szeroko używanych pakietów Rust, wzbudzając obawy wśród deweloperów i projektów, których łańcuchy zależności obejmują komponenty związane z ekosystemem Solana. Badacze bezpieczeństwa z SlowMist, Socket i StepSecurity poinformowali, że złośliwe wydania dotknęły arrayref@0.3.10, internment@0.8.7 i append-only-vec@0.1.9.

Skonpromitowane wydania wprowadziły zależność typu typosquatting, przypominającą legalny pakiet proc-macro1, której skrypt budowania pobierał i uruchamiał zdalny ładunek podczas kompilacji Cargo. W rezultacie deweloperzy oraz systemy ciągłej integracji (CI) mogli zostać narażeni już samym skompilowaniem projektu zależnego od jednej z dotkniętych wersji. Zgodnie z informacjami udostępnionymi przez @WuBlockchain na X, zespół bezpieczeństwa Rust usunął złośliwe wydania i zablokował konto opiekuna powiązane z tymi pakietami.

Złośliwe pakiety dostarczone przez łańcuch zależności

Incydent dotyczy ekosystemu pakietów Rust, w którym deweloperzy często polegają na zewnętrznych crate’ach, aby zapewnić funkcjonalność w aplikacjach i projektach programistycznych. W tym przypadku badacze zidentyfikowali złośliwe wersje trzech crate’ów: arrayref@0.3.10, internment@0.8.7 i append-only-vec@0.1.9.

Złośliwe wydania zawierały zależność zaprojektowaną tak, aby przypominała legalny pakiet proc-macro1. Taka technika, znana jako typosquatting, ma na celu sprawienie, by złośliwy pakiet wyglądał podobnie do legalnej zależności. Jest to powracająca metoda stosowana w repozytoriach open source, w tym npm i Python PyPI, gdzie podobnie wyglądające nazwy były wielokrotnie wykorzystywane do przepuszczania złośliwego kodu przez rutynowe aktualizacje zależności.

Atak stał się szczególnie istotny, ponieważ złośliwa zależność zawierała skrypt budowania zdolny do pobrania i uruchomienia zdalnego ładunku po skompilowaniu dotkniętego pakietu. Oznacza to, że ryzyko bezpieczeństwa nie ograniczało się koniecznie do użytkowników, którzy ręcznie instalowali lub uruchamiali ewidentnie podejrzany program: środowisko deweloperskie lub CI mogło zostać narażone jako część normalnego procesu kompilacji oprogramowania.

Proces budowania stworzył potencjalne ryzyko bezpieczeństwa

Cargo jest menedżerem pakietów i systemem budowania Rust, a deweloperzy rutynowo używają go do pobierania zależności i kompilowania projektów. Opisywany atak wykorzystał ten przepływ pracy. Ponieważ Cargo uruchamia skrypt budowania crate’a automatycznie w ramach kompilacji, taki skrypt działa z uprawnieniami użytkownika lub konta CI wykonującego budowę.

Gdy kompilowano dotkniętą zależność, złośliwy skrypt budowania mógł pobrać i uruchomić zdalny ładunek. Stworzyło to potencjalną drogę dla atakującego do wykonania kodu na komputerze dewelopera lub hoście CI.

Systemy CI są szczególnie ważne we współczesnym tworzeniu oprogramowania, ponieważ automatycznie budują, testują i wdrażają kod. Skonpromitowane środowisko budowania może zatem stwarzać ryzyko wykraczające poza pojedynczą stację roboczą dewelopera, ponieważ maszyny budujące i stacje robocze często przechowują dane uwierzytelniające, takie jak tokeny API, klucze wdrożeniowe i materiały podpisujące. Z tego powodu zespoły bezpieczeństwa zwykle traktują wykonanie kodu w czasie budowania jako podstawę do rotacji wszelkich sekretów obecnych na dotkniętych systemach.

Incydent podkreśla szersze wyzwanie bezpieczeństwa związane z łańcuchami dostaw oprogramowania, w których złośliwy kod może trafić do projektu pośrednio przez zależności, których deweloperzy mogli nie napisać ani nie zweryfikować sami.

Łańcuchy zależności związane z Solana przyciągają uwagę

Crate arrayref jest szeroko używany w całym ekosystemie Rust i pojawia się w łańcuchach zależności obejmujących komponenty związane z Solana. Oprogramowanie walidatorów Solana i duża część narzędzi wokół niego jest napisana w Rust, dlatego ogólnego przeznaczenia crate’y, takie jak arrayref, mogą pojawiać się w drzewach zależności związanych z Solana, mimo że same crate’y nie są specyficzne dla technologii blockchain. Jednak obecność dotkniętego crate’a w łańcuchu zależności nie oznacza, że dalsze projekty związane z Solana zostały skompromitowane.

To rozróżnienie jest ważne, ponieważ oprogramowanie open source często opiera się na wielu warstwach zależności. Podatny lub skompromitowany pakiet może pojawić się gdzieś w drzewie zależności projektu, nie powodując koniecznie skutecznej kompromitacji końcowej aplikacji lub sieci.

Badacze bezpieczeństwa rozróżniają więc narażenie na złośliwą zależność od dowodu, że złośliwy kod został faktycznie wykonany w konkretnym projekcie lub środowisku pochodnym. Opisany incydent potwierdza, że dotknięte wydania zawierały złośliwy kod, ale nie potwierdza, że każdy projekt korzystający z powiązanych zależności został skompromitowany.

Zespół bezpieczeństwa Rust usuwa złośliwe wydania

Zespół bezpieczeństwa Rust zareagował, usuwając złośliwe wydania i blokując konto opiekuna powiązane z tymi pakietami. Zgodnie z przekazanymi informacjami, maszyna opiekuna lub poświadczenia publikacji prawdopodobnie zostały skompromitowane.

Skompromitowane konto publikujące może stanowić poważne ryzyko w ekosystemach open source, ponieważ atakujący mogą rozprowadzać złośliwe oprogramowanie pod tożsamością legalnego opiekuna. Usunięcie dotkniętych wersji ogranicza dalszą dystrybucję w ekosystemie pakietów, a zablokowanie konta uniemożliwia publikowanie kolejnych wydań przy użyciu skompromitowanych poświadczeń. Ostrzeżenia bezpieczeństwa dotyczące skompromitowanych crate’ów Rust są śledzone w utrzymywanej przez społeczność bazie RustSec, jednym z kanałów, które deweloperzy mogą monitorować obok rejestru crates.io.

Incydent pokazuje także znaczenie monitorowania zależności i przeglądania nieoczekiwanych aktualizacji pakietów, zwłaszcza gdy projekty opierają się na dużych i złożonych drzewach zależności.

Szersze implikacje dla deweloperów Rust

Ataki na łańcuch dostaw stały się istotnym problemem bezpieczeństwa w całym procesie tworzenia oprogramowania, ponieważ celują w infrastrukturę i zależności używane do budowy aplikacji, zamiast bezpośrednio atakować końcową aplikację. W tym przypadku złośliwy kod był osadzony w wydaniach pakietów i aktywowany podczas procesu budowania. Taki schemat ma dobrze udokumentowane precedensy, w tym backdoor w XZ Utils ujawniony w marcu 2024, w którym atakujący wykorzystał pozycję opiekuna w podstawowej, otwartoźródłowej bibliotece kompresji, oraz kompromitację pakietu @solana/web3.js w npm w grudniu 2024, która dotknęła bibliotekę JavaScript szeroko używaną przez deweloperów Solana. Oba zdarzenia, podobnie jak to, pokazują, jak zaufanie do konta opiekuna lub tożsamości pakietu może stać się powierzchnią ataku.

Deweloperzy korzystający z projektów Rust mogą ograniczyć ekspozycję na podobne incydenty, monitorując wersje zależności, sprawdzając nieoczekiwane zmiany i używając narzędzi bezpieczeństwa zdolnych do identyfikowania podejrzanych pakietów lub zachowania zależności. W odniesieniu do tego incydentu oznacza to przeszukiwanie plików blokady, takich jak Cargo.lock, pod kątem trzech dotkniętych wersji, sprawdzanie logów CI i budowania pod kątem nieoczekiwanej aktywności sieciowej wychodzącej oraz rotację poświadczeń na każdej maszynie, na której kompilowano dotknięte wydania. Organizacje polegające na automatycznych środowiskach CI powinny również uwzględnić bezpieczeństwo swojej infrastruktury budowania, ponieważ złośliwe zależności mogą potencjalnie wykonać kod przed wdrożeniem aplikacji.

Reakcja ekosystemu Rust pokazuje znaczenie skoordynowanego monitorowania bezpieczeństwa i szybkiego usuwania skompromitowanych pakietów. Choć dotknięte crate’y mają powiązania z łańcuchami zależności obejmującymi komponenty związane z Solana, dostępne informacje nie potwierdzają, że samo Solana lub konkretne projekty pochodne zostały skompromitowane. Incydent przypomina raczej, że szeroko używane zależności open source mogą stać się potencjalnym wektorem ataku, gdy poświadczenia publikacji lub środowiska opiekunów zostaną skompromitowane.

Źródło: Hokanews