TL; DR
Shai-Hulud 3.0 to najnowsza ewolucja złośliwego oprogramowania npm o nazwie Shai-hulud, samonapędzający się robak łańcucha dostaw nadużywanie pakietów npm w celu kradzieży danych uwierzytelniających, automatycznego rozprzestrzeniania się i kompromitacji CI/CD W przeciwieństwie do poprzednich fal, Shai-Hulud 3.0 udoskonala swoją logikę propagacji, atakuje popularne biblioteki front-endowe i przyspiesza infekcję poprzez nadużywanie tokenów konserwatorów.
W rezultacie to złośliwe oprogramowanie typu shai-hulud po raz kolejny dowodzi, że współczesne ataki na łańcuchy dostaw npm nie opierają się już na lukach typu zero-day, ale na automatyzacji, nadużywaniu zaufania i przepływach pracy programistów.
Czym jest Shai-Hulud 3.0?
Shai-Hulud 3.0 to trzecia potwierdzona fala kampanii złośliwego oprogramowania npm o nazwie Shai-hulud, po pierwotnym robaku Shai-Hulud i masowej epidemii Shai-Hulud 2.0.
Jednak ta wersja nie wprowadza radykalnie nowego exploita. Zamiast tego poprawia wydajność, ukrycie i celowanie. Innymi słowy, Shai-Hulud 3.0 optymalizuje model ataku na łańcuch dostaw, zamiast go przeprojektowywać.
Co najważniejsze, złośliwe oprogramowanie nadal działa jako robak, a nie jako jednorazowy złośliwy pakiet.
Dlaczego Shai-Hulud 3.0 ma znaczenie dla bezpieczeństwa npm
Na pierwszy rzut oka Shai-Hulud 3.0 może wyglądać jak „kolejny złośliwy pakiet npm”. Jednak to właśnie to założenie jest przyczyną sukcesu tej kampanii.
Ponieważ ekosystemy npm w dużym stopniu polegają na:
- dorozumiane zaufanie
- instalacje automatyczne
- poświadczenia opiekuna
- CI/CD pipelines
Jeden naruszony token może szybko przerodzić się w epidemię złośliwego oprogramowania w całym łańcuchu dostaw npm.
W rezultacie złośliwe oprogramowanie shai-hulud nie wymaga exploitów. Uzbraja ono standardowe procesy.
Wektor ataku Shai-Hulud 3.0: jak rozprzestrzenia się złośliwe oprogramowanie npm
Początkowa infekcja za pośrednictwem złośliwego pakietu npm
Złośliwe oprogramowanie npm shai-hulud przedostaje się do ekosystemu za pośrednictwem pakietów trojanizowanych publikowanych na legalnych lub zainfekowanych kontach administratorów.
W przypadku fali Shai-Hulud 3.0 badacze zaobserwowali infekcję poprzez popularne zależności, w tym pakiety zorientowane na front-end, takie jak:
@vietmoney/react-big-calendar
Ponieważ pakiety te znajdują się wysoko na grafach zależności, pojedyncza instalacja szybko rozprzestrzenia się na wiele projektów.
Zbieranie poświadczeń i propagacja robaków
Po zainstalowaniu Shai-Hulud 3.0 uruchamia złośliwe skrypty cyklu życia podczas install or postinstall.
Na tym etapie złośliwe oprogramowanie:
- skanuje pliki lokalne i zmienne środowiskowe
- wyodrębnia tokeny npm i dane uwierzytelniające GitHub
- identyfikuje dostępne repozytoria i pakiety
W związku z tym infekcja natychmiast przechodzi z lokalny kompromis do propagacja w całym ekosystemie.
Automatyczne ponowne publikowanie w portfelach konserwatorów
Po zebraniu danych uwierzytelniających, shai-hulud npm malware programowo wylicza wszystkie pakiety będące własnością zagrożonego administratora.
A potem to:
- wstrzykuje złośliwy kod do nowych wersji
- automatycznie ponownie publikuje te wersje
- zamienia każdą ofiarę w nowy punkt dystrybucji
W rezultacie jeden skradziony token może zainfekować dziesiątki lub setki pakietów npm w ciągu kilku godzin.
Shai-Hulud 3.0 kontra poprzednie fale
Co zmieniło się w Shai-Hulud 3.0?
Chociaż podstawowe mechanizmy pozostają znajome, Shai-Hulud 3.0 wprowadza kilka ważnych udoskonaleń.
W szczególności:
- szybsza logika propagacji
- czystsza struktura ładunku
- lepsze łączenie z legalnymi aktualizacjami pakietów
- zmniejszony hałas w porównaniu do Shai-Hulud 2.0
W związku z tym wykrywanie oparte wyłącznie na reputacji lub CVE staje się nieskuteczne.
| WYGLĄD | Shai-Hulud 2.0 | Shai-Hulud 3.0 |
|---|---|---|
| Początkowy wektor infekcji | Złośliwe pakiety npm ze skryptami cyklu życia preinstalacji | Złośliwe pakiety npm nadużywające zaufanych bibliotek o wysokiej widoczności i ścieżek aktualizacji |
| Podstawowy Cel | ekosystem npm i CI/CD pipelines | ekosystem npm skupiający się na maszynach programistycznych i odbiorcach końcowych |
| Mechanizm propagacji | Kradzież danych uwierzytelniających, a następnie automatyczne ponowne publikowanie pakietów | Ponowne wykorzystanie poświadczeń i nadużywanie zaufania zależności w celu szybszego zwiększenia zasięgu |
| Nadużycie środowiska wykonawczego | Instalacja środowiska wykonawczego Bun w locie | Ponowne wykorzystanie istniejącego środowiska wykonawczego Node.js i zaufanych ścieżek wykonywania |
| CI/CD Nadużycie | Ukryte przepływy pracy GitHub Actions i samodzielnie hostowane moduły uruchamiające | Zredukowany CI/CD hałas, większy nacisk na ukryte wykonywanie na poziomie pakietu |
| Zachowanie ładunku | Duże, zaciemnione ładunki JavaScript i skanowanie środowiska | Mniejsze, bardziej ukierunkowane ładunki, skupione na trwałości i rozprzestrzenianiu |
| Targetowanie poświadczeń | Tokeny GitHub, tokeny npm, dane uwierzytelniające w chmurze, sekrety CI | Te same cele poświadczeń, z szybszym ponownym wykorzystaniem i mniejszą widocznością wycieku danych |
| Hałas operacyjny | Bardzo uciążliwe: tworzenie masowych repozytoriów, wstrzykiwanie do przepływu pracy, masowe przesyłanie danych | Niższy poziom hałasu: mniej widocznych artefaktów, trudniej je dostrzec podczas ręcznego przeglądu |
| Promień uderzenia | Duży, ale wykrywalny ze względu na skalę i artefakty | Potencjalnie większy z powodu ukrytego działania i nadużywania zaufanych pakietów |
| Wyzwanie obronne | Zatrzymanie CI/CD nadużycia i wyciek danych uwierzytelniających | Wykrywanie złośliwego zachowania wewnątrz legalnych pakietów |
Dlaczego to wciąż ten sam robak
Pomimo tych zmian, Shai-Hulud 3.0 to nadal ta sama klasa robaków łańcucha dostaw npm.
Polega na:
- ponowne użycie poświadczeń
- automatyczne ponowne publikowanie
- zaufanie zależnościowe
- CI/CD egzekucja
W związku z tym każde środowisko instalujące pakiety npm bez kontroli zachowań pozostaje narażone.
Wskaźniki kompromisu
Zespoły ds. bezpieczeństwa badające złośliwe oprogramowanie shai-hulud powinny zwracać uwagę na następujące sygnały:
- nieoczekiwane zmiany wersji pakietu
- skrypty cyklu życia dodane bez uzasadnienia
- zaciemnione bloby JavaScript
- wychodzące żądania sieciowe podczas instalacji
- npm lub GitHub tokeny dostępne w czasie instalacji
- CI/CD zadania zachowują się nieoczekiwanie po aktualizacjach zależności
Co ważne, żaden z nich nie wymaga istnienia CVE.
Dlaczego tradycyjne narzędzia bezpieczeństwa npm nie sprawdzają się w Shai-Hulud 3.0
Wykrywanie oparte na CVE kończy się niepowodzeniem
Ponieważ Shai-Hulud 3.0 nadużywa legalnych obiegów pracy, skanery skupiające się tylko na znanych lukach nie widzą w nim niczego złego.
Jest:
- brak podatnej funkcji
- brak niebezpiecznego API
- brak uszkodzeń pamięci
Zamiast tego w normalnym JavaScript-ie kryje się złośliwa intencja.
SBOM Widoczność nie wystarczy
Podobnie, SBOMs mogę ci powiedzieć co jesteś zależny, ale nie co robi w czasie instalacji.
W rezultacie przejrzystość bez egzekwowania nie powstrzyma robaka w łańcuchu dostaw.
Jak Xygeni zapobiega atakom na łańcuch dostaw Shai-Hulud 3.0 npm
Właśnie w tym miejscu architektura Xygeni ma znaczenie.
Wczesne ostrzeganie przed złośliwym oprogramowaniem (MEW): Zatrzymaj złośliwe oprogramowanie npm w momencie publikacji
Wczesne ostrzeganie przed złośliwym oprogramowaniem (MEW) firmy Xygeni nieprzerwanie skanuje nowo opublikowane pakiety npm w czasie rzeczywistym.
MEW wykrywa:
- zaciemnione ładunki
- podejrzane skrypty cyklu życia
- zachowanie związane ze zbieraniem danych uwierzytelniających
- nieprawidłowe zapisy w systemie plików
- nieoczekiwana aktywność sieciowa
Co najważniejsze, MEW może automatycznie blokować kompilacje, uniemożliwiając złośliwemu oprogramowaniu npm shai-hulud przedostanie się do systemu. CI/CD.
Guardrails: Wymuś bezpieczne zachowanie zależności
Xygeni Guardrails egzekwować surowe zasady wewnątrz pipelines.
One:
- blokować złośliwe lub podejrzane pakiety npm
- zapobiegaj wykonywaniu ukrytych skryptów instalacyjnych
- zatrzymaj pobieranie środowiska wykonawczego podczas kompilacji
- wymuś integralność pliku blokady
W wyniku tego pipeline zatrzymuje się przed wykonaniem robaka.
CI/CD Bezpieczeństwo: Chroń Pipelines z nadużycia
Ponieważ Shai-Hulud 3.0 często przechodzi w CI/CDMonitory Xygeni pipelines dla:
- nieautoryzowane zmiany w przepływie pracy
- nieprawidłowe wzorce wykonywania
- niewłaściwe użycie uprawnień
- wstrzykiwanie przepływu pracy wyzwalane zależnością
Jeśli pojawi się ryzykowne zachowanie, Xygeni blokuje pipeline natychmiast, odcinając ruch boczny.
Ochrona sekretów: Zmniejsz promień wybuchu
Ponieważ złośliwe oprogramowanie shai-hulud agresywnie kradnie dane uwierzytelniające, Xygeni skupia się również na sekretach.
Xygeni:
- wykrywa ujawnione sekrety w całym SDLC
- automatycznie zmienia poświadczenia wysokiego ryzyka
- egzekwuje bezpieczniejsze praktyki tokenowe
Dlatego nawet jeśli złośliwe oprogramowanie zostanie uruchomione, skradzione poufne informacje szybko tracą wartość.
Dlaczego Shai-Hulud 3.0 potwierdza długoterminowy trend
Ostatecznie Shai-Hulud 3.0 potwierdza szerszą rzeczywistość.
Nowoczesne ataki na łańcuchy dostaw npm:
- rozprzestrzeniać się automatycznie
- poruszaj się szybciej niż recenzja ludzka
- wykorzystywać zaufanie, a nie luki w zabezpieczeniach
- cel pipelines, nie tylko kod
W związku z tym obrona przed złośliwym oprogramowaniem npm shai-hulud wymaga wykrywania i egzekwowania zasad zachowania, a nie tylko skanowania.
Uwagi końcowe: Dlaczego Shai-Hulud 3.0 nadal ma znaczenie
Mimo że Shai-Hulud 3.0 nie wprowadza nowego, rzucającego się w oczy ataku, jest to dojrzały, powtarzalny i skalowalny model ataku.
Innymi słowy, nie będzie to ostatnia fala.
Zespoły, które polegają na reaktywnym zabezpieczeniu, będą nadal ścigać infekcje. Zespoły, które wcześnie zablokują złośliwe zachowanie, całkowicie powstrzymają robaka.
W tym tkwi różnica.
