Atak łańcucha dostaw „Miasma” uderza w pakiety npm Red Hat i infekuje środowiska deweloperskie - Security Bez Tabu

Atak łańcucha dostaw „Miasma” uderza w pakiety npm Red Hat i infekuje środowiska deweloperskie

Cybersecurity news

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najpoważniejszych zagrożeń dla firm rozwijających i utrzymujących aplikacje. W takim scenariuszu napastnik nie musi przełamywać zabezpieczeń infrastruktury ofiary bezpośrednio — wystarczy, że skompromituje zaufany element procesu wytwórczego, taki jak pakiet, biblioteka, repozytorium lub pipeline CI/CD.

Kampania określana jako „Miasma” wpisuje się właśnie w ten model. Złośliwy kod został osadzony w pakietach npm powiązanych z przestrzenią nazw Red Hat i miał za zadanie pozyskiwać poświadczenia, sekrety oraz dane umożliwiające dalszą propagację w środowiskach deweloperskich i automatyzacyjnych.

W skrócie

  • Złośliwe pakiety npm zostały powiązane z przestrzenią nazw @redhat-cloud-services.
  • Malware uruchamiał się na etapie instalacji zależności dzięki mechanizmowi preinstall.
  • Celem ataku była kradzież tokenów, kluczy, sekretów CI/CD oraz danych dostępowych do usług chmurowych.
  • Analizy wskazują na szyfrowaną eksfiltrację, utrwalanie obecności i elementy samopowielania.
  • Prawdopodobnym punktem wejścia mogło być przejęcie konta GitHub pracownika.

Kontekst / historia

Incydent z „Miasma” pojawia się w czasie wzrostu liczby operacji wymierzonych w ekosystem open source, menedżery pakietów i procesy publikacji oprogramowania. Przestępcy coraz częściej wybierają środowiska deweloperskie jako punkt wejścia, ponieważ to właśnie tam znajdują się wysoko uprzywilejowane tokeny, sekrety wdrożeniowe i dostęp do repozytoriów.

Kampania jest opisywana jako zbliżona do wcześniejszych aktywności określanych mianem Mini Shai-Hulud. Podobieństwa dotyczą sposobu wykonywania kodu podczas instalacji pakietu, przechwytywania poświadczeń, modyfikowania workflow oraz używania przejętych zasobów do dalszego skażania łańcucha dostaw.

Szczególnie niepokojące jest to, że zainfekowane komponenty pochodziły z obszaru kojarzonego z zaufanym dostawcą. W praktyce oznacza to, że mogły zostać pobrane automatycznie przez systemy build i deploy bez dokładnej kontroli ich zawartości.

Analiza techniczna

Najważniejszym elementem kampanii był zaciemniony hook preinstall osadzony w pakietach npm. Taki mechanizm uruchamia się jeszcze przed właściwą instalacją zależności, dzięki czemu napastnik może wykonać kod zarówno na stacji roboczej dewelopera, jak i na runnerze CI/CD. To wyjątkowo skuteczna technika, ponieważ wpisuje się w normalny przebieg pracy narzędzi deweloperskich.

Ładunek miał wyszukiwać i zbierać szeroką gamę danych wrażliwych. Wśród celów znalazły się tokeny GitHub Actions, poświadczenia npm, klucze SSH, dane Git, materiały Kubernetes, wpisy Vault oraz sekrety związane z chmurami publicznymi. Taki zakres oznacza ryzyko nie tylko jednorazowej kradzieży danych, ale również przejęcia dostępu do wielu systemów jednocześnie.

Z dostępnych analiz wynika, że malware korzystał z szyfrowanej eksfiltracji oraz kanałów pomocniczych opartych na legalnych usługach, co utrudnia wykrycie na poziomie sieci. Złośliwy kod miał również identyfikować repozytoria, do których przejęte tokeny posiadały uprawnienia zapisu, a następnie wprowadzać zmiany wyglądające jak zwykłe działania developerskie.

Istotna była również logika ukierunkowana na pipeline’y CI/CD. Malware miał analizować pliki workflow i wstrzykiwać do nich modyfikacje pozwalające utrzymać aktywność w kolejnych etapach procesu. Opisy sugerują także próby eskalacji uprawnień, sprawdzanie obecności mechanizmów ochronnych oraz działania mające zwiększyć odporność operacji na detekcję.

Kampania obejmowała także mechanizmy persistence. Złośliwe zmiany mogły trafiać do konfiguracji narzędzi deweloperskich i plików projektowych uruchamianych ponownie przy kolejnych sesjach pracy. To oznacza, że samo usunięcie pakietu lub katalogu zależności nie musi wystarczyć do pełnego oczyszczenia środowiska.

Dodatkowym elementem były rozwinięte kolektory tożsamości chmurowych, między innymi dla środowisk GCP i Azure. Wskazuje to na przesunięcie akcentu z prostego wycieku sekretów w stronę aktywnego przejmowania dostępu do usług chmurowych i zasobów organizacji.

Konsekwencje / ryzyko

Ryzyko związane z „Miasma” należy ocenić jako wysokie, szczególnie dla organizacji korzystających z npm, GitHub Actions oraz rozbudowanych procesów automatyzacji build i release. Skutki mogą obejmować przejęcie poświadczeń, naruszenie integralności repozytoriów, skażenie artefaktów publikacyjnych oraz wtórne rozprzestrzenienie się zagrożenia na klientów i partnerów.

Kompromitacja pojedynczej stacji deweloperskiej może w takim scenariuszu otworzyć drogę do wielu środowisk jednocześnie. Deweloperzy i pipeline’y często dysponują dostępem do rejestrów pakietów, sekretów, repozytoriów i środowisk chmurowych. Atakujący mogą więc nie tylko kraść informacje, ale również modyfikować kod, publikować zainfekowane paczki i utrzymywać trwałą obecność.

Niebezpieczne jest także ukrywanie złośliwej aktywności w zwykłych procesach developerskich. Jeśli kompromitacja przyjmuje formę pozornie legalnych commitów, workflow lub artefaktów, organizacja może wykryć incydent dopiero wtedy, gdy obejmie on już kolejne projekty i zespoły.

Rekomendacje

Organizacje, które mogły zetknąć się z podatnymi wersjami wskazanych pakietów, powinny potraktować sprawę jako pełnoprawny incydent bezpieczeństwa. W pierwszej kolejności należy odizolować hosty, na których instalowano podejrzane pakiety, oraz tymczasowo zatrzymać pipeline’y korzystające z zagrożonych zależności.

Kolejnym krokiem powinna być pełna rotacja wszystkich potencjalnie ujawnionych poświadczeń. Dotyczy to tokenów GitHub, tokenów npm, sekretów CI/CD, kluczy SSH, danych dostępowych do chmury, wpisów Vault oraz wszelkich danych używanych przez mechanizmy automatyzacji. Sama wymiana pakietu na bezpieczną wersję nie usuwa skutków ewentualnego wycieku.

  • unieważnić artefakty powstałe w okresie ekspozycji,
  • przeanalizować historię commitów i workflow pod kątem nieautoryzowanych zmian,
  • sprawdzić, czy po instalacji pakietów nie opublikowano nowych wydań, obrazów lub bibliotek,
  • zweryfikować uprawnienia tokenów mających dostęp zapisu do repozytoriów i rejestrów,
  • przeprowadzić audyt stacji roboczych oraz runnerów pod kątem mechanizmów persistence,
  • skontrolować konfiguracje narzędzi developerskich i zadania uruchamiane automatycznie po otwarciu projektu.

W dłuższej perspektywie warto wdrożyć zasadę minimalnych uprawnień dla tożsamości maszynowych, segmentację środowisk deweloperskich i build, obowiązkową weryfikację zmian w zależnościach, skanowanie hooków install i preinstall, monitorowanie nietypowych operacji GitHub API oraz walidację pochodzenia artefaktów.

Podsumowanie

„Miasma” pokazuje, że współczesne ataki na łańcuch dostaw nie ograniczają się już do prostego osadzenia złośliwego kodu w bibliotece. Coraz częściej obejmują przejmowanie sekretów, tożsamości chmurowych, pipeline’ów CI/CD i mechanizmów publikacji, a następnie wykorzystują zdobyte uprawnienia do dalszej propagacji.

Dla zespołów bezpieczeństwa oznacza to konieczność szerszego spojrzenia na DevSecOps. Ochrona łańcucha dostaw musi obejmować nie tylko analizę kodu i zależności, ale również monitoring zachowania pakietów podczas instalacji, ścisłą kontrolę sekretów, ochronę kont uprzywilejowanych oraz pełną widoczność działań w repozytoriach i automatyzacji.

Źródła