Kompromitacja pakietów @joyfill w npm: złośliwy RAT aktywowany już podczas importu w Node.js

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu
2 W skrócie
3 Kontekst i historia incydentu
4 Analiza techniczna
5 Konsekwencje i ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu

Ekosystem npm od lat pozostaje jednym z głównych celów ataków na łańcuch dostaw oprogramowania. Najnowszy incydent związany z pakietami z przestrzeni nazw @joyfill pokazuje szczególnie groźny scenariusz, w którym złośliwy kod nie czeka na etap instalacji, ale uruchamia się już w chwili importu biblioteki przez środowisko Node.js.

Taki mechanizm znacząco podnosi poziom ryzyka, ponieważ infekcja może zostać aktywowana podczas zwykłego uruchomienia aplikacji, testów, skryptów CLI albo pipeline’ów CI/CD. W praktyce oznacza to, że samo użycie podatnej wersji pakietu mogło doprowadzić do wykonania nieautoryzowanego kodu w środowisku deweloperskim lub produkcyjnym.

W skrócie

Skompromitowano dwie wersje pakietów @joyfill/layouts oraz @joyfill/components.
Złośliwy implant JavaScript aktywował się już podczas importu modułu.
Łańcuch infekcji prowadził do pobrania i uruchomienia zdalnego trojana typu RAT.
Atak wykorzystywał wielowarstwową infrastrukturę opartą o dane publikowane w sieciach blockchain.
Zagrożone były nie tylko stacje robocze programistów, ale również buildy, testy i środowiska CI/CD.

Kontekst i historia incydentu

Problem dotyczył konkretnych wydań: @joyfill/layouts@0.1.2-2773.beta.0 oraz @joyfill/components@4.0.0-rc24-2773-beta.4. To ważne rozróżnienie, ponieważ kampania nie objęła całej rodziny pakietów, lecz precyzyjnie wybrane wersje beta i release candidate.

Incydent wpisuje się w szerszy trend ataków wymierzonych w otwarte repozytoria pakietów i narzędzia używane przez deweloperów. W ostatnich latach napastnicy coraz częściej wykorzystują npm do dystrybucji backdoorów, infostealerów oraz złośliwego oprogramowania nastawionego na kradzież sekretów, tokenów i dostępu do repozytoriów kodu.

Na obecnym etapie nie potwierdzono jednoznacznie pierwotnego wektora kompromitacji. Nie było jasne, czy źródłem problemu było przejęcie konta publikującego, stacji roboczej dewelopera, repozytorium czy procesu CI/CD. Z perspektywy bezpieczeństwa oznacza to konieczność analizy całego procesu wydawniczego, a nie wyłącznie samego rejestru npm.

Analiza techniczna

Najbardziej niebezpiecznym elementem kampanii był sposób aktywacji implantu. W odróżnieniu od typowych złośliwych pakietów npm, które opierają się na skryptach takich jak postinstall, tutaj złośliwy kod uruchamiał się podczas ładowania punktu wejścia CommonJS. Dzięki temu atak mógł zostać uruchomiony bez oczywistych sygnałów ostrzegawczych na etapie instalacji.

Łańcuch infekcji działał wieloetapowo. Jedna z gałęzi prowadziła do odzyskania zaszyfrowanego ładunku JavaScript, który był powiązany z rodziną malware typu RAT dla Node.js. Druga ścieżka uruchamiała odłączony proces Node.js odpowiedzialny za pobranie dodatkowego boot payloadu ze zdalnego hosta, jego odszyfrowanie i wykonanie niezależnie od głównego procesu.

Istotnym elementem kampanii była logika wykorzystująca publiczne sieci blockchain do rozwiązywania wskaźników do kolejnych etapów infekcji. Kod najpierw próbował pobrać dane z transakcji w sieci Tron. W razie niepowodzenia wykorzystywany był alternatywny mechanizm oparty o konto w sieci Aptos, które prowadziło dalej do danych w BNB Smart Chain. Finalnie z tych źródeł wydobywany i odszyfrowywany był właściwy kod JavaScript.

Taki model daje napastnikom kilka przewag operacyjnych. Ogranicza zależność od tradycyjnej infrastruktury C2, pozwala dynamicznie zmieniać dostarczany ładunek bez publikowania nowej wersji pakietu i utrudnia wykrywanie oparte na prostym filtrowaniu domen, adresów IP czy reputacji hostów.

Końcowy ładunek działał jako zdalny trojan dostępu dla Node.js. Oferował funkcje zdalnego sterowania, pobierania kolejnych skryptów, zbierania informacji o hoście, wysyłania komunikatów kontrolnych oraz odczytu zawartości schowka systemowego. Implementacja była wieloplatformowa i obejmowała mechanizmy specyficzne dla systemów Windows, macOS i Linux.

Dodatkowo analizy wskazywały na możliwość dostarczenia komponentu typu infostealer. Zakres potencjalnie pozyskiwanych danych obejmował poświadczenia deweloperskie, tokeny, dane przeglądarek, konfiguracje Git i GitHub CLI, logi narzędzi developerskich, a także informacje przechowywane przez edytory i rozszerzenia używane przez programistów.

Konsekwencje i ryzyko

Skala ryzyka wykracza poza pojedynczą aplikację zależną od podatnych wersji pakietów. Ponieważ aktywacja następowała w momencie importu, zagrożone były lokalne stacje robocze programistów, procesy budowania, testy automatyczne, renderowanie po stronie serwera oraz runnerzy CI/CD.

wykonanie dowolnego kodu w kontekście procesu Node.js,
kradzież sekretów, tokenów i poświadczeń developerskich,
przejęcie dostępu do repozytoriów, narzędzi DevOps i środowisk chmurowych,
eksfiltracja danych projektowych i plików lokalnych,
utrzymanie trwałego dostępu do zainfekowanych stacji roboczych,
wtórne wykorzystanie przejętych danych do dalszych ataków na software supply chain.

Szczególnie narażone są organizacje, które dopuszczają użycie wersji beta lub release candidate bez ścisłej walidacji, przechowują zależności w prywatnych mirrorach albo korzystają z obrazów kontenerów zawierających wcześniej pobrane paczki. W takich przypadkach usunięcie pakietu z publicznego rejestru nie kończy problemu, ponieważ złośliwe artefakty mogą pozostać obecne wewnątrz organizacji.

Rekomendacje

Organizacje, które mogły pobrać wskazane wersje pakietów, powinny potraktować incydent jako potencjalne naruszenie bezpieczeństwa. Nie jest to wyłącznie problem zależności, lecz sytuacja, która mogła umożliwić uruchomienie złośliwego kodu i kradzież danych.

Natychmiast zidentyfikować obecność wersji @joyfill/layouts@0.1.2-2773.beta.0 oraz @joyfill/components@4.0.0-rc24-2773-beta.4 w lockfile’ach, cache’ach, artefaktach wdrożeniowych i obrazach kontenerów.
Usunąć skompromitowane wydania z lokalnych środowisk, prywatnych mirrorów i pipeline’ów CI/CD.
Przypiąć zależności do zweryfikowanych wersji i ograniczyć możliwość pobierania nieautoryzowanych buildów beta oraz RC.
Przeprowadzić rotację wszystkich sekretów dostępnych z poziomu procesu Node.js, w tym tokenów npm, GitHub, kluczy API i poświadczeń chmurowych.
Sprawdzić stacje robocze deweloperów oraz runnerów CI pod kątem nietypowych procesów Node.js, dodatkowych payloadów i zmian w narzędziach developerskich.
Zweryfikować integralność build cache’y, obrazów bazowych oraz mechanizmów SBOM, jeśli są wykorzystywane.
Rozszerzyć monitoring o analizę zachowań zależności open source, a nie tylko skanowanie znanych podatności.
Wzmocnić bezpieczeństwo procesu publikacji pakietów przez MFA, krótkowieczne tokeny i podpisywanie artefaktów.

Podsumowanie

Kompromitacja pakietów @joyfill to kolejny dowód na dojrzewanie ataków na łańcuch dostaw w ekosystemie JavaScript. Najistotniejszą cechą tego incydentu była aktywacja złośliwego kodu już w chwili importu modułu oraz wykorzystanie infrastruktury opartej o blockchain do sterowania kolejnymi etapami infekcji.

Dla zespołów bezpieczeństwa i DevSecOps kluczowy wniosek jest jasny: ochrona zależności open source nie może ograniczać się do listy CVE. Niezbędne są monitoring zachowania pakietów, kontrola procesu publikacji, segmentacja środowisk developerskich oraz szybka reakcja na anomalie w łańcuchu dostaw. W przypadku wykrycia zagrożonych wersji należy zakładać możliwość pełnej kompromitacji procesu i prowadzić działania jak przy pełnym incydencie bezpieczeństwa.