Autor: Wojciech Ciemski

Wprowadzenie do problemu / definicja

Ekosystem open source ponownie znalazł się w centrum zaawansowanego ataku na łańcuch dostaw oprogramowania. Tym razem incydent dotyczy narzędzia Trivy oraz powiązanej kampanii złośliwych pakietów npm, w której wykorzystano mechanizmy kradzieży poświadczeń, utrzymywania dostępu oraz dalszej propagacji zagrożenia.

Szczególnie niebezpiecznym elementem tej operacji jest komponent określany jako CanisterWorm. To złośliwe oprogramowanie nie ogranicza się do instalacji backdoora, ale potrafi również wyszukiwać tokeny npm na zainfekowanych hostach i używać ich do publikacji kolejnych złośliwych paczek, co znacząco zwiększa skalę ryzyka dla deweloperów i organizacji korzystających z automatycznych pipeline’ów.

W skrócie

• Atak rozpoczął się od kompromitacji komponentów związanych z Trivy i publikacji złośliwych wydań.
• Następnie przejęto i zatruto dziesiątki pakietów npm, obejmując wiele zakresów nazw używanych przez organizacje i deweloperów.
• Złośliwy kod wykorzystywał hook postinstall, loader oraz backdoora w Pythonie z mechanizmem trwałości opartym o usługę systemd użytkownika.
• Do pobierania aktualnego adresu kolejnego etapu używano kontenera ICP, działającego jako zdecentralizowany resolver.
• Nowszy wariant CanisterWorm zyskał zdolność samorozprzestrzeniania poprzez wyszukiwanie tokenów npm i publikowanie kolejnych złośliwych wersji.

Kontekst / historia

Incydent związany z Trivy wpisuje się w szerszy trend ataków na łańcuch dostaw, których celem są repozytoria kodu, workflow CI/CD oraz mechanizmy publikacji artefaktów. W ostatnich miesiącach badacze wielokrotnie opisywali nadużycia wobec środowisk GitHub Actions i innych systemów automatyzacji, gdzie głównym celem było przejęcie tokenów z uprawnieniami zapisu.

W analizowanej kampanii skutkiem miała być kompromitacja poświadczeń pozwalających na publikację złośliwych wersji oprogramowania oraz dalsze ruchy boczne w ekosystemie deweloperskim. Atak szybko przekształcił się z pojedynczego naruszenia w wieloetapową operację ukierunkowaną na maksymalizację zasięgu i utrzymanie obecności w środowiskach deweloperskich.

Szczególną uwagę zwraca skala zatrucia rejestru npm. Zidentyfikowano wiele przejętych pakietów, w tym paczki powiązane z konkretnymi zakresami nazw organizacyjnych, co pokazuje, że atakujący nie działali przypadkowo, lecz koncentrowali się na zaufanych kanałach dystrybucji i zasobach mających realny wpływ na proces budowania oprogramowania.

Analiza techniczna

Łańcuch infekcji opierał się na mechanizmie postinstall, który uruchamia się automatycznie podczas instalacji zależności. To jeden z najbardziej ryzykownych wektorów w ekosystemie npm, ponieważ wykonanie kodu następuje natychmiast po pobraniu pakietu, często bez świadomości użytkownika i zanim narzędzia bezpieczeństwa zakończą pełną analizę artefaktu.

Po uruchomieniu skryptu instalacyjnego wykonywany był loader odpowiedzialny za wdrożenie backdoora napisanego w Pythonie. Malware nawiązywał komunikację z infrastrukturą sterującą, ale nie korzystał ze statycznie zapisanych adresów serwerów C2. Zamiast tego odpytywał kontener ICP działający w środowisku Internet Computer, aby pobrać aktualny adres kolejnego etapu lub ładunku.

Taka architektura daje operatorom kilka istotnych korzyści. Pozwala dynamicznie zmieniać payload bez konieczności aktualizacji wszystkich implantów, zwiększa odporność infrastruktury na wyłączenie i utrudnia analizę wskaźników kompromitacji. Dodatkowo infrastruktura mogła zwracać neutralny adres w ramach trybu uśpienia, a następnie zostać szybko przełączona na właściwy zasób złośliwy.

Mechanizm trwałości został zrealizowany przez usługę systemd w kontekście użytkownika. Jednostka była maskowana jako narzędzie związane z PostgreSQL, co miało zmniejszyć szansę wykrycia podczas pobieżnej inspekcji systemu. Zastosowanie automatycznego restartu zwiększało odporność infekcji na proste próby usunięcia procesu.

Najpoważniejszą zmianą okazał się wariant samorozprzestrzeniający. W nowej wersji funkcja wyszukiwania tokenów npm została osadzona bezpośrednio w kodzie wykonywanym podczas instalacji. Po wdrożeniu backdoora malware przeszukiwało środowisko deweloperskie lub CI pod kątem poświadczeń, a następnie inicjowało publikację złośliwych wydań do wszystkich pakietów, do których znaleziony token zapewniał dostęp. W praktyce oznacza to przejście od klasycznego przejęcia konta do półautomatycznego robaka atakującego łańcuch dostaw.

Konsekwencje / ryzyko

Skutki takiego ataku mogą być bardzo poważne, ponieważ zagrożenie obejmuje jednocześnie stacje robocze deweloperów, systemy CI/CD, rejestry pakietów i proces publikacji artefaktów. Zainfekowanie jednego elementu może uruchomić efekt domina prowadzący do kompromitacji kolejnych zasobów organizacji.

Największe ryzyko dotyczy środowisk CI/CD, gdzie instalacja zależności często odbywa się z dostępem do tokenów publikacyjnych, sekretów chmurowych, kluczy repozytoryjnych i innych danych uwierzytelniających. Jeśli złośliwy pakiet zostanie wykonany w takim pipeline’ie, organizacja może utracić kontrolę nad własnymi paczkami, workflow i kanałami dystrybucji.

Konsekwencje biznesowe obejmują publikację trojanizowanych wersji oprogramowania, wtórną kompromitację klientów i partnerów, konieczność rotacji dużej liczby poświadczeń oraz audyt integralności repozytoriów i artefaktów. Wykorzystanie zdecentralizowanej infrastruktury do dystrybucji adresów C2 dodatkowo utrudnia szybkie odcięcie komunikacji i wydłuża czas reakcji na incydent.

Rekomendacje

Organizacje powinny potraktować ten incydent jako sygnał ostrzegawczy i przeprowadzić natychmiastowy przegląd bezpieczeństwa łańcucha dostaw oprogramowania. W pierwszej kolejności należy ustalić, czy w środowisku były używane zainfekowane wersje komponentów związanych z Trivy oraz wskazane pakiety npm. Konieczna jest również analiza logów instalacji zależności, historii workflow, aktywności tokenów i ostatnich publikacji pakietów.

• unieważnić i ponownie wygenerować tokeny npm, GitHub oraz inne sekrety dostępne w środowiskach deweloperskich i CI/CD;
• sprawdzić hosty deweloperskie oraz runner’y pod kątem nietypowych usług systemd użytkownika, procesów Pythona i podejrzanych artefaktów;
• wymusić pinowanie akcji GitHub do niezmiennych commit SHA zamiast tagów;
• ograniczyć uprawnienia tokenów zgodnie z zasadą najmniejszych uprawnień;
• odseparować tokeny publikacyjne od zadań, które nie wymagają publikacji artefaktów;
• wdrożyć skanowanie pakietów pod kątem złośliwych hooków instalacyjnych i anomalii behawioralnych;
• stosować allowlisty zależności oraz kontrolę wieku i reputacji nowych wersji pakietów;
• monitorować rejestry pod kątem nieautoryzowanych wydań i nietypowych zmian maintainerskich;
• budować procedury szybkiej kwarantanny paczek i odtwarzania zaufanego stanu z podpisanych artefaktów.

W organizacjach korzystających z npm kluczowe jest również ograniczenie obecności tokenów publikacyjnych w zmiennych środowiskowych i na stacjach roboczych. Token nie powinien być dostępny tam, gdzie wykonywana jest zwykła instalacja zależności, jeśli nie jest to absolutnie konieczne.

Podsumowanie

Atak powiązany z Trivy i CanisterWorm pokazuje, że nowoczesne kampanie supply chain łączą dziś kompromitację kont, zatrucie pakietów, utrzymywanie dostępu na hostach oraz mechanizmy samorozprzestrzeniania. Szczególnie alarmujące jest przejście do modelu, w którym malware samodzielnie wyszukuje tokeny i aktywnie infekuje kolejne pakiety.

Dla zespołów bezpieczeństwa oznacza to konieczność ochrony nie tylko kodu, ale całego procesu budowania, publikacji i dystrybucji oprogramowania. Skuteczna obrona wymaga kontroli integralności, ograniczania uprawnień, szybkiej rotacji sekretów oraz ciągłego monitorowania zachowania zależności instalowanych w środowiskach deweloperskich i CI/CD.

Źródła

• The Hacker News — Trivy Supply Chain Attack Triggers Self-Spreading CanisterWorm Across 47 npm Packages
• StepSecurity — CI/CD Incidents
• Aikido Security — Stop Malicious npm Packages | Aikido Safe Chain