Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Miasma to nowa odsłona zagrożeń wymierzonych w łańcuch dostaw oprogramowania, zaprojektowana z myślą o środowiskach deweloperskich, repozytoriach kodu oraz procesach CI/CD. Kampania pokazuje, że współczesne ataki supply chain nie muszą opierać się wyłącznie na podmianie paczek w publicznych rejestrach. Coraz częściej punktem wejścia stają się konta programistów, workflow automatyzacji, tokeny federacyjne oraz codzienne narzędzia używane podczas pracy z kodem.
W praktyce oznacza to przesunięcie ciężaru ataku z klasycznej dystrybucji złośliwych pakietów na przejmowanie zaufanej tożsamości i nadużywanie legalnych mechanizmów build oraz publikacji. Tego typu operacje są szczególnie niebezpieczne, ponieważ złośliwa aktywność może wyglądać jak normalny element procesu wytwarzania oprogramowania.
W skrócie
Według opublikowanych analiz Miasma miała doprowadzić do kompromitacji 73 repozytoriów Microsoft utrzymywanych na GitHubie, co skutkowało ich czasowym wyłączeniem. Wśród dotkniętych projektów wymieniano między innymi komponenty związane z Azure Functions oraz rodziną Durable Task w różnych implementacjach językowych.
Kampania jest opisywana jako rozwinięcie wcześniejszego malware Mini Shai-Hulud. Jej celem miało być przejmowanie sekretów deweloperskich, tożsamości chmurowych oraz zasobów dostępnych zarówno z poziomu stacji roboczych programistów, jak i runnerów CI/CD. Szczególnie niepokojące jest wykorzystanie prawidłowych tokenów OIDC, dzięki czemu tworzone artefakty mogły wyglądać na legalne i poprawnie poświadczone.
- skompromitowano dziesiątki repozytoriów powiązanych z Microsoft,
- atak obejmował workflow GitHub Actions i tokeny OIDC,
- złośliwa aktywność wykraczała poza rejestry pakietów i obejmowała kod źródłowy,
- zagrożone były także środowiska lokalne deweloperów oraz zasoby w chmurze.
Kontekst / historia
Incydent wpisuje się w rosnący trend ataków na supply chain, w których napastnik nie musi łamać samego systemu budowania oprogramowania, jeśli wcześniej przejmie zaufane konto użytkownika lub automatyzacji. W opisywanym przypadku kampania miała rozpocząć się od kompromitacji konta pracownika Red Hat na GitHubie. Następnie atakujący wykorzystali nieprzeglądane commity do osadzenia minimalnego workflow, który pobierał tokeny OIDC i uruchamiał kolejne etapy ładunku.
Na wczesnym etapie operacji złośliwy workflow miał doprowadzić do publikacji 32 podejrzanych wersji pakietów w ekosystemie npm. Kolejna faza rozszerzyła działania na repozytoria źródłowe, gdzie malware nie ograniczał się już do zatruwania rejestrów, ale infekował również sam kod oraz ścieżki pracy deweloperów. To istotna zmiana taktyki, ponieważ repozytorium źródłowe stanowi dla wielu organizacji upstream zaufania, od którego zaczyna się cały proces dostarczania aplikacji.
Dodatkowe obawy budzi powiązanie kampanii z wcześniejszym incydentem dotyczącym ekosystemu Durable Task. Zbieżność obszaru ataku może sugerować ponowną kompromitację tych samych zasobów albo niewystarczającą remediację po wcześniejszych zdarzeniach.
Analiza techniczna
Technicznie Miasma wyróżnia się przede wszystkim nadużyciem legalnych mechanizmów federacji tożsamości. Wykorzystanie tokenów OIDC wydawanych w ramach GitHub Actions pozwala uzyskać krótkotrwałe poświadczenia chmurowe bez konieczności przechwytywania klasycznych statycznych sekretów. Jeśli atakujący uruchomi workflow z uprawnieniami zaufanego repozytorium, jego działania mogą wyglądać jak rutynowy proces pipeline’u.
Kolejnym kluczowym elementem jest publikacja artefaktów opatrzonych poprawnymi atestacjami pochodzenia. Z perspektywy narzędzi walidujących provenance pakiet może wydawać się autentyczny, ponieważ został zbudowany przez prawidłowo uwierzytelniony proces. Problem nie wynika więc z fałszywej atestacji, lecz z faktu, że zaufany workflow został uruchomiony przez przejętą tożsamość lub wcześniej zmodyfikowaną automatyzację.
Opis kampanii wskazuje również na wykorzystanie narzędzi programistycznych wspieranych przez AI jako potencjalnego wektora wykonania droppera po sklonowaniu i otwarciu zainfekowanego repozytorium. W takim scenariuszu momentem infekcji nie musi być instalacja biblioteki z rejestru, ale zwykła interakcja dewelopera z projektem. To rozszerza powierzchnię ataku z systemów build na laptopy inżynierów, edytory kodu oraz lokalne środowiska pracy.
Istotna jest także personalizacja ładunku dla każdej infekcji. Jeżeli każda próbka różni się kryptograficznie, skuteczność wykrywania opartego wyłącznie na hashach i prostych IOC znacząco spada. Kampania miała ponadto aktywnie wyszukiwać poświadczenia i tożsamości chmurowe dostępne w środowiskach Azure i GCP, zarówno na stacjach deweloperskich, jak i na runnerach CI/CD.
- nadużycie tokenów OIDC i legalnych mechanizmów federacji,
- publikacja artefaktów wyglądających na poprawnie poświadczone,
- przeniesienie infekcji z rejestrów pakietów do repozytoriów źródłowych,
- rozszerzenie ataku na lokalne środowiska programistyczne,
- kradzież poświadczeń chmurowych i możliwość dalszego ruchu bocznego.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem takiego ataku jest utrata integralności łańcucha dostaw oprogramowania. Jeśli zaufane repozytorium zostaje użyte do dystrybucji złośliwego kodu, zagrożeni są nie tylko maintainerzy projektu, ale również organizacje pobierające kod, budujące własne artefakty i wdrażające je do środowisk produkcyjnych.
Ryzyko operacyjne występuje na kilku poziomach. W warstwie deweloperskiej zagrożone są lokalne sekrety, tokeny GitHub, klucze SSH, zmienne środowiskowe oraz cache narzędzi. W warstwie CI/CD przeciwnik może uzyskać dostęp do runnerów, kluczy podpisujących, kont serwisowych oraz krótkotrwałych poświadczeń federacyjnych. Na poziomie chmury możliwe staje się przejęcie tożsamości uprawnionych do zarządzania zasobami, odczytu danych, publikacji obrazów i modyfikacji konfiguracji wdrożeń.
Incydent podważa także założenie, że poprawne provenance i legalny pipeline automatycznie oznaczają bezpieczeństwo artefaktu. Jeżeli atakujący działa w ramach prawidłowego workflow i przy użyciu ważnych tokenów, tradycyjne kontrole integralności mogą nie wykazać nadużycia. W efekcie organizacje muszą rozszerzyć model zaufania o monitoring tożsamości, kontekstu uruchomienia pipeline’u i anomalii behawioralnych.
Rekomendacje
Organizacje korzystające z GitHub, GitHub Actions, Azure, GCP oraz publicznych repozytoriów kodu powinny traktować podobne kampanie jako pełnoprawny incydent bezpieczeństwa. Priorytetem powinna być szybka identyfikacja zasięgu naruszenia i odcięcie potencjalnych ścieżek dalszej eskalacji.
W pierwszej kolejności warto przeprowadzić rotację wszystkich potencjalnie narażonych poświadczeń, w tym tokenów GitHub, kluczy SSH, sekretów CI/CD, kluczy podpisujących oraz poświadczeń chmurowych. Sama zmiana haseł użytkowników nie wystarczy, jeśli napastnik uzyskał dostęp do workflow, runnerów lub federowanych tożsamości.
Następnie należy przeanalizować historię commitów, definicje workflow GitHub Actions oraz logi audytowe pod kątem oznak nadużyć i nietypowych zmian. Szczególnej uwagi wymagają zmiany w automatyzacji publikacji, nietypowe żądania tokenów OIDC oraz aktywność runnerów poza normalnym harmonogramem pracy.
- rotacja wszystkich sekretów i poświadczeń mogących mieć związek z incydentem,
- przegląd commitów, branchy i zmian w plikach workflow,
- weryfikacja logów audytowych pod kątem nietypowych żądań OIDC,
- monitorowanie procesów uruchamianych przez narzędzia deweloperskie i edytory kodu,
- egzekwowanie zasady najmniejszych uprawnień dla workflow i kont serwisowych,
- separacja runnerów dla projektów o różnym poziomie zaufania,
- obowiązkowy code review dla zmian w pipeline’ach i automatyzacji,
- ograniczenie publikacji pakietów do kontrolowanych ścieżek release,
- wdrożenie procedury repo compromise playbook.
W praktyce potrzebne jest także lepsze telemetryczne pokrycie środowisk deweloperskich, które historycznie bywały monitorowane słabiej niż systemy produkcyjne. Coraz częściej to właśnie laptop programisty lub runner CI/CD staje się punktem styku między kodem źródłowym a infrastrukturą chmurową.
Podsumowanie
Miasma to przykład nowoczesnego robaka supply chain, który łączy kompromitację kont, nadużycie GitHub Actions, wykorzystanie tokenów OIDC, infekowanie repozytoriów oraz kradzież tożsamości chmurowych. Najważniejsza lekcja z tego incydentu jest jednoznaczna: nawet poprawnie podpisany i pozornie legalny artefakt może być złośliwy, jeśli źródłowa tożsamość lub workflow zostały wcześniej przejęte.
Obrona przed podobnymi kampaniami wymaga dziś nie tylko walidacji integralności buildów, ale również ciągłej kontroli tożsamości, uprawnień i zachowania procesów w całym łańcuchu dostarczania oprogramowania. To właśnie w tym obszarze rozstrzyga się obecnie realne bezpieczeństwo nowoczesnych środowisk developerskich.
Źródła
- Security Affairs — https://securityaffairs.com/193367/malware/miasma-worm-compromises-73-microsoft-github-repositories.html
- Cloudsmith report — https://cloudsmith.com/blog/miasma-a-new-supply-chain-worm-targeting-open-source-package-ecosystems
- OpenSourceMalware analysis — https://opensourcemalware.com/recompromise-of-microsoft-durable-task-ecosystem
- GitHub Docs — OpenID Connect — https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
- SLSA — Supply-chain Levels for Software Artifacts — https://slsa.dev/