Google łączy atak supply chain na Axios w npm z północnokoreańskim klastrem UNC1069 - Security Bez Tabu

Google łączy atak supply chain na Axios w npm z północnokoreańskim klastrem UNC1069

Cybersecurity news

Wprowadzenie do problemu / definicja

Ataki supply chain na ekosystemy open source pozostają jednym z najpoważniejszych zagrożeń dla współczesnych procesów wytwarzania oprogramowania. Najnowszy incydent związany z pakietem Axios w rejestrze npm pokazuje, że kompromitacja pojedynczego konta maintenera może otworzyć drogę do masowej dystrybucji złośliwego kodu w środowiskach deweloperskich, CI/CD i produkcyjnych.

Według ustaleń Google Threat Intelligence Group operacja została powiązana z północnokoreańskim klastrem UNC1069. To istotna atrybucja, ponieważ wskazuje nie tylko na techniczną dojrzałość sprawców, ale również na możliwe motywacje finansowe i wcześniejsze doświadczenie w atakach na łańcuch dostaw.

W skrócie

  • Złośliwe wersje pakietu Axios zostały opublikowane po przejęciu konta maintenera w npm.
  • Atakujący dodali zależność „plain-crypto-js”, która uruchamiała złośliwy kod przez mechanizm postinstall.
  • Łańcuch infekcji prowadził do pobrania wieloplatformowego backdoora dla Windows, macOS i Linux.
  • Google przypisało kampanię klastrowi UNC1069, wiązanemu z operacjami wymierzonymi m.in. w sektor kryptowalut.

Kontekst / historia

Axios należy do najczęściej używanych bibliotek JavaScript do realizacji żądań HTTP, dlatego jego kompromitacja ma wyjątkowo szeroki potencjalny zasięg. W analizowanym przypadku opublikowano dwie trojanizowane wersje pakietu: 1.14.1 oraz 0.30.4. Uderzenie objęło więcej niż jedną linię wydawniczą, co sugeruje świadomie zaplanowaną operację nastawioną na maksymalizację liczby ofiar.

Google wskazuje, że UNC1069 działa co najmniej od 2018 roku i ma doświadczenie w kompromitacjach łańcucha dostaw. Dodatkowe korelacje techniczne z wcześniejszymi kampaniami dostrzegli także badacze Elastic Security Labs, którzy zwrócili uwagę na podobieństwa funkcjonalne pomiędzy nowymi próbkami a wcześniej obserwowanym zestawem narzędzi tej grupy.

Analiza techniczna

Operatorzy nie wprowadzili jawnych zmian do głównego kodu Axios. Zamiast tego dodali złośliwą zależność „plain-crypto-js”, która pełniła rolę dyskretnego nośnika malware. Kluczowym elementem był wpis postinstall w pliku package.json, dzięki któremu złośliwy kod uruchamiał się automatycznie już podczas instalacji pakietu przez npm.

„plain-crypto-js” zawierał zaciemniony dropper JavaScript określany jako SILKBELL. Jego zadaniem było pobranie kolejnego etapu infekcji zależnie od wykrytego systemu operacyjnego. Na Windows wykorzystywany był ładunek oparty o PowerShell, na macOS binarium Mach-O napisane w C++, a na Linuksie backdoor w Pythonie. Taka architektura wskazuje na dobrze przygotowaną kampanię z zapleczem umożliwiającym atakowanie różnych środowisk developerskich.

Złośliwy komponent stosował także mechanizmy utrudniające analizę po incydencie. Po wykonaniu dropper usuwał własne ślady i podmieniał plik package.json w pakiecie „plain-crypto-js” na pozornie nieszkodliwą wersję bez wpisu postinstall. To znacząco obniża szansę wykrycia podczas pobieżnej kontroli artefaktów po instalacji.

Końcowy implant został sklasyfikowany jako WAVESHAPER.V2 i oceniony jako rozwinięcie wcześniejszego backdoora WAVESHAPER. Malware komunikuje się z serwerem C2 z użyciem formatu JSON, cyklicznie beaconuje i obsługuje polecenia pozwalające m.in. na wykonywanie komend systemowych, przeglądanie katalogów, kończenie działania oraz uruchamianie dodatkowych binariów. Zachowano przy tym charakterystyczne cechy wcześniejszej wersji, w tym podobny model komunikacji i wykorzystanie tych samych lokalizacji tymczasowych dla dalszych payloadów.

W analizie próbek dla macOS zauważono również ślady deweloperskie powiązywane z wcześniejszymi narzędziami przypisywanymi północnokoreańskim operatorom. Same takie artefakty nie są jeszcze pełnym dowodem atrybucyjnym, jednak w połączeniu z telemetrią, podobieństwami kodu i profilem operacyjnym wzmacniają ocenę wskazującą na UNC1069.

Konsekwencje / ryzyko

Skala ryzyka jest znacząca, ponieważ Axios jest szeroko obecny w aplikacjach webowych, narzędziach developerskich oraz pipeline’ach budowania oprogramowania. Najbardziej narażone są organizacje, które automatycznie pobierają najnowsze wersje zależności lub nie stosują ścisłego pinowania wersji w plikach lockfile.

W praktyce kompromitacja jednego popularnego pakietu może doprowadzić do infekcji stacji roboczych deweloperów, runnerów CI, serwerów buildowych, a pośrednio również środowisk produkcyjnych. Jeżeli zainfekowane systemy miały dostęp do tokenów, kluczy SSH, poświadczeń chmurowych, danych podpisujących lub sekretów aplikacyjnych, należy traktować je jako potencjalnie ujawnione.

Atak ma również znaczenie strategiczne. Pokazuje, że dojrzały przeciwnik nie musi atakować ofiary bezpośrednio, jeśli może przejąć zaufany element ekosystemu zależności. Taki model działania skaluje się lepiej niż klasyczne kampanie phishingowe i utrudnia obronę opartą wyłącznie na ochronie punktów końcowych czy perymetru sieciowego.

Rekomendacje

W pierwszej kolejności organizacje powinny przeprowadzić audyt zależności pod kątem obecności wskazanych złośliwych wersji Axios oraz pakietu „plain-crypto-js”. W środowiskach npm należy zweryfikować zarówno zależności bezpośrednie, jak i tranzytywne, a następnie wymusić instalację bezpiecznych wersji przez aktualizację lockfile i pinowanie wersji.

Konieczne jest także sprawdzenie hostów deweloperskich i systemów CI/CD pod kątem oznak wykonania złośliwego kodu. Szczególnie warto analizować procesy potomne uruchamiane podczas instalacji pakietów, aktywność w katalogach tymczasowych, nietypowe połączenia wychodzące oraz ślady użycia PowerShell, skryptów powłoki i komponentów uruchamianych bezpośrednio po pobraniu zależności.

Jeśli potwierdzono ekspozycję, zalecana jest izolacja systemów, usunięcie złośliwych komponentów oraz pełna rotacja poświadczeń. Dotyczy to zwłaszcza tokenów npm, kluczy API, dostępu do repozytoriów kodu, kont chmurowych i infrastruktury podpisywania artefaktów.

  • Wymuszenie MFA dla maintainerów i kont uprzywilejowanych.
  • Pinowanie wersji zależności oraz ograniczenie automatycznych aktualizacji.
  • Skanowanie SBOM i zależności tranzytywnych.
  • Kontrola wykonywania skryptów postinstall i innych lifecycle scripts.
  • Segmentacja środowisk developerskich oraz buildowych.
  • Monitorowanie anomalii w pipeline’ach i ruchu wychodzącym.
  • Przygotowanie procedur szybkiego unieważniania sekretów po incydencie.

Długofalowo wiele organizacji powinno rozważyć politykę ograniczającą uruchamianie skryptów instalacyjnych z pakietów zewnętrznych wszędzie tam, gdzie nie jest to biznesowo konieczne. W ekosystemie npm mechanizmy lifecycle scripts pozostają jednym z najczęściej nadużywanych wektorów dostarczenia złośliwego kodu.

Podsumowanie

Kompromitacja Axios w npm to kolejny dowód na to, że ataki supply chain stały się jednym z najskuteczniejszych sposobów infiltracji środowisk programistycznych. Szczególnie niebezpieczne okazało się połączenie przejęcia konta maintenera, użycia pomocniczej zależności, automatycznego wykonania przez postinstall oraz wdrożenia wieloplatformowego backdoora.

Powiązanie kampanii z UNC1069 wzmacnia ocenę, że za incydentem stoi przeciwnik o wysokiej dojrzałości operacyjnej i doświadczeniu w działaniach finansowo motywowanych. Dla zespołów bezpieczeństwa najważniejszy wniosek jest jasny: skuteczna obrona wymaga nie tylko skanowania podatności, ale także ciągłej kontroli integralności zależności, widoczności procesów buildowych i gotowości do szybkiej rotacji poświadczeń po wykryciu kompromitacji.

Źródła