gik|iewicz

42 pakiety npm z ekosystemu TanStack zostały skompromitowane w ataku na łańcuch dostaw. Złośliwy kod zinfekował 84 artefakty w 27 minut, kradnąc poświadczenia CI z GitHub Actions. To jeden z najszybciej rozprzestrzeniających się incydentów w historii rejestru npm.

TL;DR: Grupa TeamPCP przeprowadziła atak „Mini Shai-Hulud” na pakiety TanStack, kompromitując 84 artefakty w 27 minut. Atak wykorzystuje zatruwanie pamięci podręcznej GitHub Actions oraz kradzież tokenów OIDC do infekcji potoków CI. Złośliwy kod celuje w poświadczenia chmurowe i zmienne środowiskowe platform wdrożeniowych.

Jak przebiegł atak na 42 pakiety TanStack?

Atak na 42 pakiety TanStack rozpoczął się od skompromitowania infrastruktury CI/CD projektu. Złośliwy kod zdołał zainfekować 84 osobne artefakty npm w zaledwie 27 minut od momentu początkowego wektora ataku. Atakujący wykorzystali mechanizm GitHub Actions cache poisoning, zatruwając pamięć podręczną potoków integracji. Gdy zainfekowany potok uruchomił się, złośliwy ładunek automatycznie rozprzestrzenił się na kolejne pakiety. Złośliwy kod działał z prędkością około trzech zainfekowanych pakietów na minutę.

Kampania nosi nazwę „Mini Shai-Hulud” i jest powiązana z grupą TeamPCP. Metoda działania opiera się na mechanizmach typu worm, które automatycznie replikują się w środowisku CI. Zainfekowane pakiety publikowane są bezpośrednio w rejestrze npm, zastępując legalne wersje. W efekcie deweloperzy pobierający zaktualizowane pakiety z rejestru otrzymywali wersje z dodanym złośliwym kodem.

Czym jest metoda Mini Shai-Hulud?

„Mini Shai-Hulud” to nazwa kampanii ataku przypisana do grupy TeamPCP, wykorzystującej mechanizmy typu robak do automatycznej replikacji złośliwego kodu. Metoda ta celuje w systemy CI/CD, wykorzystując zatruwanie pamięci podręcznej GitHub Actions oraz kradzież tokenów OIDC. Technika pozwala na błyskawiczne rozprzestrzenianie się infekcji na dziesiątki pakietów bez bezpośredniej interakcji atakującego po początkowym wektorze. Model działania przypomina zachowanie piaskowego robaka z uniwersum Diuny, stąd nazwa operacji.

Atakujący wykorzystują skradzione tokeny OIDC do uwierzytelniania w imieniu zainfekowanych potoków. Następnie modyfikują konfigurację budowania, wstrzykując ładunek kradnący poświadczenia. Cały proces jest w pełni zautomatyzowany. Po zatruwaniu pamięci podręcznej, każdy kolejny proces budowania uruchamia złośliwy kod.

Jakie pakiety TanStack zostały skompromitowane?

Zainfekowanych zostało 42 pakiety z ekosystemu TanStack, obejmujące 84 skompromitowane artefakty wykryte przez zespół Socket. Atak objął popularne biblioteki frontendowe używane przez dziesiątki tysięcy projektów komercyjnych. Wśród zainfekowanych pakietów znajdują się kluczowe komponenty do zarządzania stanem aplikacji, routingu oraz obsługi formularzy w aplikacjach webowych.

• TanStack Query – biblioteka do zarządzania stanem serwerowym i asynchronicznym pobieraniem danych
• TanStack Table – narzędzie do budowania zaawansowanych tabel danych z sortowaniem i filtracją
• TanStack Router – system routingu oparty na typach dla aplikacji JavaScript i TypeScript
• TanStack Form – biblioteka do obsługi formularzy z walidacją i zarządzaniem stanem
• TanStack Virtual – komponent do wirtualizacji długich list i renderowania dużych zbiorów danych
• TanStack Store – system zarządzania stanem aplikacji z mechanizmem subskrypcji
• Zainfekowane artefakty obejmujące wersje deweloperskie i produkcyjne poszczególnych pakietów
• Pakiety pomocnicze zawierające narzędzia developerskie i skrypty budowania

Skala kompromitacji jest znaczna. Ekosystem TanStack jest powszechnie stosowany w aplikacjach enterprise. Poniższa tabela przedstawia podział zainfekowanych artefaktów.

Jak działa GitHub Actions cache poisoning?

GitHub Actions cache poisoning to technika polegająca na zatruwaniu pamięci podręcznej używanej przez potoki CI/CD do przyspieszania budowań. Atakujący zyskują możliwość zapisu do pamięci podręcznej współdzielonej przez potok, wstrzykując tam złośliwy kod. Gdy proces budowania uruchamia się ponownie, pobiera zatrute dane z cache, wykonując ładunek atakującego w kontekście potoku z podwyższonymi uprawnieniami.

W przypadku ataku na TanStack, technika ta pozwoliła na ominięcie standardowych zabezpieczeń repozytorium. Złośliwy kod wykonywał się wewnątrz zaufanego środowiska CI, mając dostęp do tokenów uwierzytelniających i zmiennych środowiskowych. Metoda ta jest trudna do wykrycia, ponieważ zainfekowane budowania wyglądają jak standardowe procesy wydawnicze. Podobną technikę zaobserwowano w Narzędzie CLI Bitwarden skompromitowane w trwającej kampanii łańcucha dostaw Checkmarx, gdzie atakujący wykorzystali mechanizmy CI do rozprzestrzeniania złośliwego kodu.

Jakie dane kradnie złośliwy kod z pakietów TanStack?

Złośliwy kod wstrzyknięty do 84 artefaktów TanStack celuje przede wszystkim w poświadczenia CI oraz tokeny chmurowe. Według analizy przeprowadzonej przez zespół Socket, malware wykrada zmienne środowiskowe z potoków GitHub Actions. Kradzież obejmuje poświadczenia dostępowe do platform wdrożeniowych oraz klucze API usług zewnętrznych. Zainfekowane pakiety wysyłają zebrane dane do serwerów kontrolowanych przez grupę TeamPCP.

Atakujący uzyskali w ten sposób dostęp do mechanizmów OIDC, co pozwalało na podszywanie się pod legalne potoki budowania. Malware filtrował zmienne środowiskowe pod kątem słów kluczowych związanych z usługami chmurowymi. Skradzione tokeny mogły zostać wykorzystane do dalszej eskalacji ataku na infrastrukturę deweloperów.

Złośliwy ładunek operuje z prędkością około trzech zainfekowanych pakietów na minutę, co potwierdza raport byteiota. Taka szybkość działania pozwala na masową kradzież poświadczeń zanim zespół bezpieczeństwa zareaguje na incydent. Mechanizm typu worm automatycznie replikuje się w środowisku CI, kradnąc poświadczenia z każdym kolejnym uruchomieniem potoku.

Jak zespół TanStack zareagował na atak?

Zespół TanStack natychmiastowo zablokował publikację nowych wersji zainfekowanych pakietów po wykryciu anomalii przez systemy monitoringu. Projekt opublikował oficjalne komunikaty bezpieczeństwa zalecające deweloperom natychmiastowe obrócenie poświadczeń oraz weryfikację integralności pobranych pakietów. Podjęto również działania mające na celu usunięcie zatrutych wersji z rejestru npm.

Reakcja na incydent obejmowała współpracę z zespołem bezpieczeństwa GitHub w celu zabezpieczenia potoków CI/CD. Zidentyfikowano luki w konfiguracji pamięci podręcznej Actions, które pozwoliły na przeprowadzenie ataku cache poisoning. Następnie wdrożono dodatkowe mechanizmy weryfikacji kroków budowania.

Działania naprawcze obejmowały również pełny audyt konfiguracji potoków oraz rotację wszystkich tokenów dostępowych. Zespół podjął współpracę z badaczami bezpieczeństwa w celu analizy wektora ataku oraz opracowania strategii zapobiegającej podobnym incydentom w przyszłości.

Jakie są skutki ataku dla deweloperów korzystających z TanStack?

Skutki ataku na łańcuch dostaw TanStack dotykają bezpośrednio organizacji, które pobrały zainfekowane wersje pakietów w oknie 27 minut od momentu kompromitacji. Złośliwy kod miał potencjalną możliwość wykradzenia poświadczeń chmurowych, tokenów wdrożeniowych oraz wrażliwych zmiennych środowiskowych z potoków CI. Organizacje muszą założyć, że wszystkie sekrety używane w zainfekowanych potokach zostały skompromitowane.

Atak wymusza przeprowadzenie pełnej inwentaryzacji zależności oraz audytu logów z systemów integracji. Deweloperzy muszą zweryfikować integralność wszystkich pobranych artefaktów z rejestru npm. Podobne konsekwencje zaobserwowano w przypadku wycieku Vercel: atak OAuth ujawnia ryzyko w zmiennych środowiskowych platformy, gdzie również doszło do narażenia poświadczeń.

W rezultacie organizacje korzystające z ekosystemu TanStack muszą natychmiastowo obrócić wszystkie poświadczenia używane w środowiskach CI. Zaleca się również wdrożenie monitorowania logów dostępowych pod kątem nieautoryzowanych wywołań z użyciem skradzionych tokenów.

Jak chronić projekty przed atakami na łańcuch dostaw npm?

Ochrona przed atakami na łańcuch dostaw wymaga wdrożenia wielowarstowych mechanizmów bezpieczeństwa w potokach CI/CD oraz ścisłej kontroli zależności. Należy unikać przechowywania poświadczeń w pamięci podręcznej GitHub Actions, która została wykorzystana jako główny wektor ataku cache poisoning. Zamiast tego należy korzystać z dedykowanych magazynów sekretów z szybką rotacją kluczy dostępu.

Kluczowe praktyki zabezpieczające infrastrukturę CI obejmują wdrożenie weryfikacji integralności pakietów oraz ograniczenie uprawnień tokenów OIDC. Warto skonfigurować alerty na nietypową aktywność w potokach budowania, taką jak nieoczekiwane modyfikacje plików konfiguracyjnych.

• Weryfikacja sum kontrolnych pobieranych pakietów przed ich użyciem w potokach
• Ograniczenie uprawnień tokenów OIDC wyłącznie do niezbędnych operacji wydawniczych
• Regularna rotacja poświadczeń CI oraz kluczy API z krótkim czasem ważności
• Monitorowanie logów GitHub Actions pod kątem anomalii w procesach budowania
• Wdrożenie narzędzi skanujących zależności przed ich instalacją w środowisku produkcyjnym
• Blokowanie nieautoryzowanych zapisów do pamięci podręcznej współdzielonej przez potoki
• Użycie pinningu wersji pakietów w celu uniknięcia automatycznych aktualizacji do zainfekowanych wydań
• Izolacja potoków wdrożeniowych od środowisk testowych i deweloperskich

Więcej strategii obronnych opisano w analizie łagodzenie kompromitacji łańcucha dostaw npm Axios | Blog Bezpieczeństwa Microsoft, gdzie omówiono mechanizmy izolacji potoków CI.

Jakie są rekomendacje dla zespołów po wykryciu zainfekowanych pakietów?

Po wykryciu zainfekowanych pakietów TanStack zespoły deweloperskie muszą natychmiastowo obrócić wszystkie poświadczenia, które mogły zostać narażone w trakcie ataku. Należy zidentyfikować wszystkie potoki CI uruchomione w oknie 27 minut od momentu kompromitacji oraz przeanalizować ich logi pod kątem dostępu do zmiennych środowiskowych. Każdy sekret używany w zainfekowanych potokach należy uznać za skompromitowany.

Zaleca się przywrócenie ostatnich znanych bezpiecznych wersji pakietów TanStack oraz wdrożenie mechanizmów pinningu wersji. Należy przeprowadzić pełny audyt infrastruktury dostępowej, weryfikując logi wdrożeń pod kątem nieautoryzowanych działań. Podobne kroki podjęto po incydencie opisanym w Narzędzie CLI Bitwarden skompromitowane w trwającej kampanii łańcucha dostaw Checkmarx, gdzie rotacja poświadczeń okazała się kluczowa.

Dodatkowo należy ograniczyć uprawnienia potoków CI do minimum niezbędnego do wykonania zadań oraz wdrożyć mechanizmy zatwierdzania wydań. Szybkie działanie jest krytyczne dla ograniczenia obszaru kompromitacji.

Często zadawane pytania

Ile czasu zajęło atakującym skompromitowanie 84 artefaktów TanStack?

Atakujący skompromitowali 84 artefakty w zaledwie 27 minut, co daje tempo około trzech zainfekowanych pakietów na minutę według raportu byteiota. Należy natychmiastowo sprawdzić logi CI za ten okres.

Która grupa odpowiada za atak na pakiety TanStack?

Grupa TeamPCP jest odpowiedzialna za kampanię Mini Shai-Hulud, która skompromitowała 42 pakiety TanStack wykorzystując mechanizmy typu worm. Należy zablokować wszystkie wersje pakietów wydane w oknie ataku.

Jakie dane były celem złośliwego kodu w pakietach TanStack?

Malware wykradał poświadczenia CI, tokeny OIDC oraz zmienne środowiskowe z potoków GitHub Actions, wysyłając je do serwerów kontrolowanych przez atakujących. Należy obrócić wszystkie sekrety używane w zainfekowanych potokach budowania.

Jak technicznie działał wektor ataku cache poisoning na TanStack?

Atakujący zatruli pamięć podręczną GitHub Actions wstrzykując złośliwy kod, który był automatycznie wykonywany podczas kolejnych uruchomień potoków CI. Należy wyłączyć współdzielenie pamięci podręcznej między potokami o różnym poziomie zaufania.

Podsumowanie

Atak na łańcuch dostaw TanStack pokazuje, jak podatne na kompromitację są popularne ekosystemy open source. 42 pakiety zostały zainfekowane w 27 minut, a malware wykradł poświadczenia CI z potoków GitHub Actions. Główne wnioski z incydentu obejmują:

• Szybkość rozprzestrzeniania się infekcji – 84 artefakty w 27 minut wymuszają natychmiastową reakcję zespołów bezpieczeństwa
• Krytyczność ochrony pamięci podręcznej CI – cache poisoning stanowi wektor ataku trudny do wykrycia w standardowych procedurach audytu
• Konieczność rotacji poświadczeń – wszystkie sekrety używane w zainfekowanych potokach należy uznać za skompromitowane
• Ważność weryfikacji integralności zależności – sumy kontrolne pakietów pozwalają wykryć nieautoryzowane modyfikacje
• Istotność ograniczania uprawnień OIDC – minimalizacja uprawnień tokenów ogranicza obszar potencjalnej kompromitacji

Zabezpiecz swoje potoki CI i regularnie audytuj zależności. Subskrybuj newsletter gikiewicz.eu, aby otrzymywać raporty o zagrożeniach łańcucha dostaw bezpośrednio na swoją skrzynkę.