Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania należą dziś do najpoważniejszych zagrożeń dla organizacji rozwijających i utrzymujących aplikacje. Kampania Miasma pokazuje, że kompromitacja zaufanych pakietów npm może posłużyć nie tylko do kradzieży sekretów i poświadczeń, ale również do dalszego rozprzestrzeniania złośliwego kodu w środowiskach deweloperskich oraz pipeline’ach CI/CD.
W opisywanym incydencie złośliwy kod został powiązany z pakietami npm kojarzonymi z Red Hat. Mechanizm infekcji został zaprojektowany tak, aby uruchamiać się już na etapie instalacji zależności, co znacząco zwiększa skuteczność ataku i utrudnia jego szybkie wykrycie.
W skrócie
Miasma to kampania typu supply chain, która wykorzystuje zainfekowane pakiety npm do wykonania kodu podczas instalacji. Malware kradnie poświadczenia, dane dostępowe do chmury i systemów automatyzacji, a następnie może wykorzystywać przejęte tokeny do dalszego rozprzestrzeniania się w repozytoriach oraz procesach publikacji.
- atak uruchamia się poprzez hook preinstall,
- celem są stacje robocze deweloperów i środowiska CI/CD,
- złośliwy kod zbiera sekrety GitHub, npm, SSH, Kubernetes i Vault,
- eksfiltracja danych odbywa się w sposób utrudniający detekcję,
- kampania zawiera cechy samorozprzestrzeniającego się robaka.
Kontekst / historia
Miasma wpisuje się w szerszy trend ataków wymierzonych w ekosystem open source i proces wytwarzania oprogramowania. W ostatnich latach wielokrotnie obserwowano przypadki, w których przejęcie konta maintenera, publikatora pakietu lub elementu pipeline’u skutkowało masową ekspozycją użytkowników końcowych i organizacji korzystających z popularnych zależności.
Według dostępnych analiz kampania wykazuje podobieństwa do wcześniejszych działań określanych jako Mini Shai-Hulud. Oznacza to wykorzystanie znanych już technik obejmujących kradzież sekretów, manipulowanie workflow oraz próby infekowania kolejnych projektów poprzez przejęte uprawnienia. Tego rodzaju operacje są szczególnie niebezpieczne, ponieważ pojedynczy incydent może doprowadzić do kaskadowego skażenia wielu repozytoriów i artefaktów.
Analiza techniczna
Kluczowym elementem kampanii był złośliwy hook preinstall osadzony w pakietach npm. Taki kod wykonuje się automatycznie podczas instalacji zależności, jeszcze zanim użytkownik uruchomi aplikację. To sprawia, że zainfekowany pakiet może oddziaływać zarówno na lokalne stacje robocze, jak i na systemy buildowe oraz runnery CI/CD.
Złośliwy ładunek koncentrował się na pozyskiwaniu szerokiego zestawu danych uwierzytelniających i materiałów wrażliwych. Wśród potencjalnych celów znajdowały się sekrety GitHub Actions, tokeny npm, dane chmurowe, klucze SSH, poświadczenia Git, materiały Kubernetes oraz sekrety przechowywane w HashiCorp Vault.
- sekrety i tokeny wykorzystywane w GitHub Actions,
- tokeny publikacyjne i dostępowe npm,
- poświadczenia do usług chmurowych,
- materiały dostępowe Kubernetes i Vault,
- klucze SSH oraz konfiguracje Git,
- inne wrażliwe pliki obecne na hostach deweloperskich.
Analizy wskazują również na zastosowanie szyfrowanej eksfiltracji danych, co utrudnia wykrywanie incydentu na poziomie ruchu sieciowego. Dodatkowo malware mógł wykorzystywać usługi deweloperskie jako kanał zapasowy do przesyłania danych i wykonywania kolejnych operacji, dzięki czemu aktywność napastnika mogła zlewać się z normalnym ruchem narzędzi programistycznych.
Istotną cechą Miasma była także zdolność do działania jak robak ukierunkowany na software supply chain. Po uzyskaniu dostępu do tokenów z odpowiednimi uprawnieniami złośliwy kod mógł analizować repozytoria, identyfikować workflow i wprowadzać kolejne zmiany umożliwiające dalszą propagację. Badacze wskazywali również na próby utrzymania trwałości, omijania narzędzi ochronnych oraz eskalacji uprawnień w środowiskach automatyzacji.
Konsekwencje / ryzyko
Ryzyko związane z kampanią Miasma należy ocenić jako wysokie. Atak wykorzystuje bowiem zaufane komponenty ekosystemu deweloperskiego, a więc mechanizmy, które w wielu organizacjach działają automatycznie i bez dodatkowej weryfikacji. W praktyce oznacza to możliwość uruchomienia malware bez świadomej akcji użytkownika.
Skutki incydentu mogą obejmować zarówno naruszenie pojedynczych stacji roboczych, jak i pełną kompromitację procesów wytwarzania oprogramowania. Szczególnie groźne jest przejęcie tokenów z prawami zapisu do repozytoriów, rejestrów pakietów lub środowisk chmurowych, ponieważ otwiera to drogę do dalszych zmian w kodzie, workflow i publikowanych artefaktach.
- przejęcie kont organizacyjnych w GitHub i npm,
- publikację kolejnych złośliwych pakietów,
- modyfikację pipeline’ów oraz workflow CI/CD,
- kompromitację buildów i obrazów kontenerowych,
- dostęp do zasobów chmurowych i tożsamości usługowych,
- utrzymanie trwałości na hostach deweloperskich.
Rekomendacje
Organizacje, które mogły zainstalować podejrzane wersje pakietów lub korzystały z repozytoriów powiązanych z incydentem, powinny traktować sytuację jako potencjalne pełne naruszenie środowiska developerskiego i CI/CD. Reakcja powinna obejmować nie tylko usunięcie pakietu, ale również szeroki przegląd zaufania do sekretów, artefaktów i konfiguracji.
- natychmiast odizolować hosty, na których instalowano podejrzane pakiety,
- usunąć złośliwe zależności i zweryfikować cache, lockfile oraz artefakty pośrednie,
- przeprowadzić rotację wszystkich potencjalnie ujawnionych sekretów,
- sprawdzić historię aktywności w GitHub, npm i systemach CI/CD,
- unieważnić buildy, obrazy i release’y powstałe w okresie ekspozycji,
- przeprowadzić audyt mechanizmów trwałości w konfiguracjach narzędzi deweloperskich,
- zweryfikować integralność repozytoriów i zmian poza standardowym code review,
- ograniczyć uprawnienia tokenów automatyzacyjnych zgodnie z zasadą najmniejszych przywilejów,
- zredukować możliwość wykonywania skryptów instalacyjnych w zależnościach,
- rozszerzyć monitoring o telemetrykę z hostów deweloperskich, runnerów i chmury.
Długofalowo warto wdrożyć podpisywanie artefaktów, kontrolę pochodzenia buildów, izolację runnerów oraz automatyczne reguły wykrywające nietypowe użycie tokenów i nieautoryzowane modyfikacje workflow. Coraz wyraźniej widać, że bezpieczeństwo supply chain wymaga równoczesnej ochrony kodu, tożsamości i infrastruktury automatyzacyjnej.
Podsumowanie
Miasma jest przykładem zaawansowanego ataku na łańcuch dostaw, który łączy kompromitację pakietów npm, kradzież sekretów, działania przeciwko CI/CD oraz mechanizmy samorozprzestrzeniania. Kampania pokazuje, że pojedyncza infekcja w ekosystemie deweloperskim może szybko przełożyć się na szersze skażenie repozytoriów, buildów i publikowanych komponentów.
Dla zespołów bezpieczeństwa i DevSecOps to kolejny sygnał, że stacje robocze programistów, tokeny automatyzacyjne i pipeline’y buildowe powinny być traktowane jako krytyczne elementy powierzchni ataku. Sama analiza podatności bibliotek nie wystarcza, jeśli organizacja nie kontroluje procesu publikacji, integralności zmian i zachowań uprzywilejowanych tożsamości.