Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla ekosystemu open source. Najnowszy incydent związany z frameworkiem Mastra pokazuje, jak duże konsekwencje może mieć przejęcie jednego konta z uprawnieniami publikacyjnymi do rejestru npm.
W wyniku ataku skompromitowano 144 pakiety z przestrzeni nazw @mastra/*. Złośliwa aktywność nie polegała na prostym dopisaniu malware do głównych bibliotek, lecz na dodaniu złośliwej zależności uruchamianej automatycznie podczas instalacji pakietu.
W skrócie
Atakujący wykorzystał przejęte konto dawnego współtwórcy projektu, które nadal zachowało możliwość publikowania pakietów. Do złośliwych wydań dodano bibliotekę easy-day-js, podszywającą się pod legalny moduł do operacji na datach.
- skompromitowano 144 pakiety npm powiązane z Mestrą,
- złośliwy kod uruchamiał się przez mechanizm
postinstall, - loader pobierał kolejne komponenty z infrastruktury atakującego,
- ostateczny ładunek działał jako międzyplatformowy infostealer.
Kontekst / historia
Mastra to framework open source wykorzystywany do budowy aplikacji AI w JavaScript i TypeScript. Jego pakiety mogą trafiać nie tylko na stacje deweloperskie, ale również do środowisk CI/CD, kontenerów budujących oraz infrastruktury chmurowej, gdzie przechowywane są tokeny, sekrety i dane dostępowe.
Według analiz incydent miał charakter zautomatyzowanej kampanii publikacyjnej. W krótkim czasie opublikowano ponad 140 złośliwych wersji pakietów, co wskazuje na dobrze przygotowany i skalowalny mechanizm dystrybucji.
Kluczowym elementem całego scenariusza było pozostawienie aktywnych uprawnień dla byłego maintanera. To klasyczny przykład ryzyka wynikającego z niewłaściwego zarządzania tożsamością i cyklem życia uprawnień w projektach open source.
Dodatkowo pakiet easy-day-js nie od początku wyglądał podejrzanie. Najpierw opublikowano jego czystą wersję, a dopiero później wprowadzono zmiany o charakterze złośliwym, co mogło utrudnić wykrycie przez narzędzia bazujące na reputacji lub prostej analizie behawioralnej.
Analiza techniczna
Techniczna konstrukcja ataku była wieloetapowa. Złośliwa zależność easy-day-js pełniła rolę pierwszego etapu, aktywowanego przez hook postinstall. Oznacza to, że wykonanie następowało już podczas instalacji pakietu przez npm, zanim deweloper zdążył świadomie użyć biblioteki w projekcie.
Pierwszy ładunek działał jako loader. Po uruchomieniu pobierał kolejne komponenty z infrastruktury kontrolowanej przez atakującego, a według analiz wyłączał także walidację certyfikatów TLS, aby zwiększyć skuteczność pobierania dalszego malware.
Następnie uruchamiany był odłączony proces działający w tle. Loader próbował również samousunięcia, aby utrudnić analizę po incydencie i ograniczyć ilość artefaktów pozostawionych na hoście.
Końcowym etapem był międzyplatformowy stealer zdolny do kradzieży danych i utrwalania obecności w systemie. Jego możliwości obejmowały:
- kradzież historii oraz danych przeglądarkowych,
- pozyskiwanie informacji z ponad 160 rozszerzeń portfeli kryptowalutowych,
- mechanizmy persistence na Windows, Linux i macOS,
- komunikację z serwerem C2,
- pobieranie i wykonywanie dodatkowych modułów.
Istotny jest również wątek pochodzenia publikacji. Legalne wydania Mastra były publikowane z użyciem zaufanego procesu CI oraz mechanizmów poświadczania pochodzenia artefaktów, natomiast złośliwe wersje trafiły do npm przy użyciu zwykłego tokenu. To pokazuje, że samo wdrożenie attestations nie wystarcza, jeśli organizacja nie wymusza ich weryfikacji.
Konsekwencje / ryzyko
Skutki incydentu mogą być poważne zarówno dla indywidualnych programistów, jak i dla firm wykorzystujących Mastrę w środowiskach produkcyjnych. Największe ryzyko dotyczy wycieku sekretów, przejęcia kont chmurowych, utraty danych z przeglądarek oraz kompromitacji portfeli kryptowalutowych.
Z perspektywy organizacji szczególnie groźna jest instalacja takich pakietów w pipeline’ach CI/CD. Jeśli złośliwa wersja została uruchomiona na runnerze, atakujący mógł uzyskać dostęp do zmiennych środowiskowych, tokenów publikacyjnych, kluczy API, poświadczeń repozytoryjnych i danych wdrożeniowych.
W praktyce otwiera to drogę do dalszego ruchu bocznego, publikacji kolejnych złośliwych artefaktów oraz długotrwałej kompromitacji procesu dostarczania oprogramowania. Dodatkowym problemem jest persistence, ponieważ samo usunięcie zależności nie musi oznaczać usunięcia drugiego etapu malware z hosta.
Rekomendacje
Zespoły deweloperskie i organizacje powinny potraktować wszystkie systemy, na których instalowano podatne wersje pakietów @mastra/*, jako potencjalnie skompromitowane. Dotyczy to stacji roboczych, runnerów CI, kontenerów buildowych i maszyn tymczasowych.
- zidentyfikować wszystkie hosty, na których zainstalowano dotknięte wersje pakietów,
- wykonać rollback do bezpiecznych wersji bibliotek,
- przeprowadzić pełną rotację poświadczeń obecnych w środowisku podczas instalacji,
- sprawdzić logi, procesy, wpisy persistence i połączenia sieciowe pod kątem artefaktów malware,
- wymusić silniejsze kontrole pochodzenia pakietów i nowych zależności pośrednich.
W praktyce rotacji powinny podlegać między innymi tokeny npm, klucze API, sekrety chmurowe, dane dostępowe do repozytoriów oraz poświadczenia do środowisk stagingowych i produkcyjnych.
Długoterminowo konieczne jest także wdrożenie zasad minimalnych uprawnień, MFA dla kont publikacyjnych oraz regularnego przeglądu listy maintainerów. Ten incydent pokazuje, że historyczny, pozornie nieistotny dostęp może stać się punktem wejścia do masowego skażenia ekosystemu pakietów.
Podsumowanie
Kompromitacja 144 pakietów npm z przestrzeni @mastra/* to kolejny przykład dojrzałego ataku na software supply chain. Połączono tu przejęcie tożsamości, złośliwą zależność, wykonanie przez postinstall oraz wieloetapowe malware z funkcjami kradzieży danych i persistence.
Najważniejsza lekcja jest jednoznaczna: bezpieczeństwo publikacji pakietów nie może opierać się wyłącznie na zaufaniu do maintainerów i reputacji projektu. Niezbędne są rygorystyczne kontrole uprawnień, weryfikowalne pochodzenie artefaktów i stały monitoring zmian w zależnościach, zwłaszcza w środowiskach AI oraz CI/CD.