Wprowadzenie do problemu / definicja
Incydent związany z pakietem Axios pokazuje, iż współczesne ataki na łańcuch dostaw systemu coraz częściej zaczynają się nie od luki w kodzie, ale od skutecznej socjotechniki wymierzonej w osoby utrzymujące najważniejsze projekty open source. W tym przypadku napastnicy przejęli konto jednego z maintenerów i opublikowali złośliwe wersje popularnej biblioteki HTTP dla ekosystemu JavaScript.
Mechanizm ataku opierał się na spreparowanym scenariuszu błędu podczas spotkania online oraz fałszywej poprawce podszywającej się pod rozwiązanie problemu technicznego. To kolejny przykład, iż zaufanie do popularnej paczki nie wystarcza, jeżeli skompromitowany zostanie sam proces publikacji.
W skrócie
- Przejęto konto maintenera projektu Axios.
- W rejestrze npm opublikowano złośliwe wersje 1.14.1 oraz 0.30.4.
- Dodany komponent instalował zdalnego trojana na macOS, Windows i Linux.
- Atak był skutkiem ukierunkowanej socjotechniki z użyciem fałszywej poprawki Microsoft Teams.
- Incydent wiązany jest z kampaniami przypisywanymi aktorowi UNC1069.
Kontekst / historia
Axios należy do najczęściej wykorzystywanych klientów HTTP w aplikacjach opartych o JavaScript i TypeScript. Z tego powodu każda kompromitacja procesu wydawniczego tego pakietu ma potencjalnie bardzo szeroki wpływ na środowiska deweloperskie, pipeline’y budowania oraz aplikacje produkcyjne.
Według dostępnych analiz nie doszło tu do klasycznego włamania do repozytorium ani infrastruktury CI/CD. Atak rozpoczął się wcześniej i miał charakter dobrze przygotowanej operacji socjotechnicznej. Napastnicy podszyli się pod legalnie działającą organizację, odtworzyli jej wizerunek i przygotowali wiarygodne środowisko współpracy z profilami użytkowników, komunikacją i pozorowaną aktywnością.
Dopiero po zbudowaniu zaufania ofiara została zaproszona na spotkanie online. W jego trakcie pojawił się spreparowany komunikat o błędzie oraz sugestia zainstalowania rzekomej poprawki rozwiązującej problem techniczny. W praktyce był to wektor dostarczenia malware, który umożliwił przejęcie środowiska pracy maintenera oraz zdobycie poświadczeń potrzebnych do publikacji w npm.
Analiza techniczna
Technicznie był to przykład kompromitacji procesu publikacji bez modyfikowania źródeł projektu. To szczególnie istotne, ponieważ wiele organizacji skupia się na integralności kodu w repozytorium, ignorując ryzyko związane z kontami uprzywilejowanymi, aktywnymi sesjami i stacjami roboczymi osób odpowiedzialnych za wydania.
Złośliwe wersje Axios zawierały dodatkową zależność o nazwie plain-crypto-js. To właśnie ten komponent odpowiadał za dostarczenie i uruchomienie zdalnego trojana, zdolnego do działania na wielu platformach. Z perspektywy obrońców oznacza to, iż choćby legalna i powszechnie zaufana biblioteka może stać się nośnikiem malware, jeżeli przejęty zostanie kanał jej dystrybucji.
Mechanika ataku obejmowała kilka etapów:
- rozpoznanie i wybór celu o wysokiej wartości, czyli maintenera popularnego pakietu,
- zbudowanie wiarygodnej legendy z użyciem fałszywych profili i środowiska komunikacyjnego,
- przeniesienie ofiary do kontrolowanego kanału rozmowy,
- wywołanie presji sytuacyjnej poprzez pozorny błąd w trakcie spotkania,
- nakłonienie do uruchomienia fałszywej poprawki lub polecenia naprawczego,
- uzyskanie dostępu do endpointu i przejęcie poświadczeń lub tokenów sesyjnych,
- publikację złośliwych wersji pakietu w oficjalnym rejestrze npm.
Szczególnie groźny jest aspekt przejęcia uwierzytelnionej sesji. W takim scenariuszu samo wieloskładnikowe uwierzytelnianie może nie wystarczyć, jeżeli napastnik uzyska dostęp do lokalnego środowiska użytkownika, zapisanych tokenów lub aktywnej sesji. Właśnie dlatego nowoczesne kampanie przeciwko deweloperom coraz częściej koncentrują się na kompromitacji endpointu zamiast bezpośredniego łamania zabezpieczeń tożsamości.
Dostępne informacje wskazują również, iż podobne próby mogły dotyczyć innych opiekunów projektów open source. Taki wzorzec sugeruje skalowalny model operacyjny, a nie pojedynczy, przypadkowy incydent.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją była możliwość dostarczenia malware do użytkowników, którzy pobrali i uruchomili zainfekowane wydania Axios w czasie ich dostępności w rejestrze. Każde środowisko, które zainstalowało wersje 1.14.1 lub 0.30.4, należy traktować jako potencjalnie skompromitowane.
Ryzyko obejmuje kilka obszarów:
- przejęcie stacji roboczych deweloperów i systemów budujących aplikacje,
- kradzież sekretów, kluczy API, tokenów dostępowych i danych logowania,
- kompromitację pipeline’ów CI/CD,
- możliwość dalszego ruchu bocznego w infrastrukturze,
- publikowanie kolejnych złośliwych artefaktów z wykorzystaniem zaufanych kanałów,
- naruszenie zaufania do łańcucha dostaw open source.
Dla organizacji korzystających z Axios najważniejsze jest ustalenie nie tylko obecności biblioteki w zależnościach, ale także tego, czy wadliwe wersje zostały faktycznie pobrane, zainstalowane i uruchomione. jeżeli tak, sprawa powinna być traktowana jako potencjalny incydent bezpieczeństwa wymagający pełnej obsługi IR.
Rekomendacje
Z perspektywy zespołów bezpieczeństwa i użytkowników najważniejsze działania operacyjne obejmują:
- natychmiastową identyfikację hostów i pipeline’ów, które pobrały wersje 1.14.1 lub 0.30.4 pakietu Axios,
- weryfikację lockfile, cache menedżerów pakietów i logów budowania,
- izolację systemów, na których zainstalowano podejrzane wydania,
- rotację wszystkich poświadczeń, sekretów, tokenów i kluczy dostępnych z poziomu tych środowisk,
- przegląd historii publikacji, sesji i użycia uprzywilejowanych tokenów,
- dodatkowe skanowanie pod kątem aktywności RAT, nietypowych procesów i połączeń wychodzących.
Dla maintenerów projektów open source oraz zespołów deweloperskich warto wdrożyć również działania prewencyjne:
- separację środowiska codziennej komunikacji od środowiska używanego do publikacji pakietów,
- stosowanie dedykowanych i utwardzonych stacji roboczych do operacji release management,
- ograniczenie uprawnień tokenów publikacyjnych oraz ich regularną rotację,
- wdrożenie krótkotrwałych poświadczeń i dodatkowych zatwierdzeń publikacji,
- monitorowanie zmian w zależnościach i anomalii w metadanych pakietów,
- szkolenia z nowoczesnej socjotechniki wymierzonej w deweloperów i maintenerów,
- stosowanie procedur weryfikacji poza głównym kanałem komunikacji dla zaproszeń, spotkań i żądań instalacji oprogramowania.
W praktyce każda prośba o zainstalowanie rzekomej poprawki do spotkania online, uruchomienie lokalnej aplikacji lub wykonanie polecenia shell podczas rozmowy z niezweryfikowanym podmiotem powinna być traktowana jako sygnał wysokiego ryzyka. Dotyczy to szczególnie osób posiadających dostęp do publikacji pakietów, podpisywania artefaktów i systemów CI/CD.
Podsumowanie
Incydent z Axios potwierdza, iż bezpieczeństwo open source nie kończy się na przeglądzie kodu i ochronie repozytoriów. Atakujący coraz skuteczniej uderzają w ludzi, procesy wydawnicze oraz zaufane konta maintenerów. W tym przypadku fałszywy komunikat błędu i spreparowana poprawka wystarczyły, by przejąć konto publikacyjne i dostarczyć złośliwy kod do oficjalnego rejestru pakietów.
Najważniejsza lekcja z tego zdarzenia jest jasna: ochrona łańcucha dostaw wymaga jednoczesnego zabezpieczenia kodu, tożsamości, endpointów i procesu publikacji. Organizacje korzystające z popularnych pakietów open source powinny rozwijać zdolność szybkiego wykrywania kompromitacji zależności, a maintenerzy muszą zakładać, iż sami są celem zaawansowanych działań socjotechnicznych.
Źródła
- BleepingComputer – Axios npm hack used fake Teams error fix to hijack maintainer account: https://www.bleepingcomputer.com/news/security/axios-npm-hack-used-fake-teams-error-fix-to-hijack-maintainer-account/
- Google Cloud Blog – New DPRK malware family WAVESHAPER used in Contagious Interview campaigns: https://cloud.google.com/blog/topics/threat-intelligence/dprk-waveshaper-contagious-interview/
- GitHub – Axios security post-mortem: https://github.com/axios/axios/security
- Socket – Analysis of the Axios compromise and broader maintainer targeting campaign: https://socket.dev
- GitHub – Documentation of social engineering attempts targeting maintainers: https://github.com
