Poważny atak programistów. Popularna biblioteka axios była zainfekowana.

Oprogramowanie na twoim komputerze korzysta z Node’a? I masz w paczkę axiosa jako zależność? Rzuć wszystko i sprawdź z jakiej wersji korzystasz. Ktoś wstrzyknął do tej biblioteki złośliwy kod. Jeśli ją pobrałeś, Twój sprzęt i klucze chmurowe są w rękach przestępców.

Co się stało?

Właśnie odkryto kolejny poważny atak na łańcuch dostaw. Tym razem oberwała popularna biblioteka programistyczna axios powszechnie wykorzystywana do generowania żądań HTTP (pobierana ok. 100 milionów razy tygodniowo!). Tuż po północy atakujący przejęli kontrolę nad kontem npm twórcy biblioteki axios i opublikowali dwie złośliwe wersje, omijając pipeline CI/CD oparty o GitHub Actions i OIDC (Trusted Publisher). Skorzystali po prostu z ręcznej publikacji z pomocą wykradzionego developerowi długoterminowego tokenu dostępu (kto wie, może ów developer, czyli jasonsaayman jest ofiarą ostatniego ataku na LiteLLM?).

Oto zainfekowane paczki:
1.14.1 (31 marca o 00:21 UTC, tag latest)
0.30.4 (31 marca 01:00 UTCtag legacy)

Zachowanie wstrzykniętego złośliwego kodu różni się między systemami:

• Windows: Nadpisuje i chowa się pod fałszywym plikiem Windows Terminal (%PROGRAMDATA%\wt.exe), po czym odpala złośliwego PowerShella. (np. %TEMP%\6202033.ps1, %TEMP%\6202033.vbs)
• macOS: Udaje demona systemowego, zrzucając plik do rzadko sprawdzanego katalogu /Library/Caches/com.apple.act.mond (plus pliki pod $TMPDIR/6202033).
• Linux: Instaluje pythonowego backdoora w /tmp/ld.py.

Malware łączy się z C2 pod adresem sfrclak[.]com:8000 i wysyła dane o Twoim środowisku, nasłuchuje poleceń oraz zaciera za sobą ślady usuwając pliki instalacyjne. Daje też atakującemu możliwość zdalnego wykonania kodu (RCE).

IoC:
IP Serwerów C2: 142.11.206[.]73
Domena kampanii C2 i URL: http://sfrclak[.]com:8000/6202033 oraz sfrclak[.]com (do odrzucenia na poziomie /etc/hosts / iptables)
Złośliwe emaile: ifstap@proton.me oraz nrwise@proton.me
SHA-256 Sumy pakietów w przestrzeni npm:
złośliwy axios w. 1.14.1 – 2553649f232204966871cea80a5d0d6adc700ca
złośliwy axios w. 0.30.4 – d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
złośliwy pakiet plain-crypto-js w. 4.2.1 – 07d889e2dadce6f3910dcbc253317d28ca61c766
Payload ld.py – fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf
pierwszy dropper setup.js – e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09

Szczegóły techniczne ataku

Atak był dość dyskretny, nie zmodyfikowano ani jednej linii kodu źródłowego axiosa (co mocno utrudniało wykrycie problemu m.in. z pomocą bazujących na kodzie skanerów typu diff). Jedynymi modyfikacjami w pliku package.json było dodanie złośliwej zależności plain-crypto-js: “^4.2.1” oraz usunięcie natywnego skryptu “prepare”: “husky”.

Nowa zależność nigdy nie była importowana, jej celem było osadzenie instrukcji wywoływanej przy pobieraniu pakietu w tle: “postinstall”: “node setup.js”. Nieźle to zaplanowano, bo pakiet plain-crypto-js udostępnił na nowym koncie na platformie ProtonMail inny osobnik, podpisujący się jako nrwise (nrwise@proton.me). Pierwsza wersja z pełnym fałszywym i nieaktywnym kodem (4.2.0) została umieszczona w serwisie 30 marca o 05:57 UTC, a zainfekowana (4.2.1) o 23:59 UTC, czyli tuż przed wstrzyknięciem jej do złośliwego axiosa. Aby uśpić czujność ewentualnych badaczy, plain-crypto-js podszywał się pod inną, bezpieczną bibliotekę crypto-js poprzez linkowanie opisu, aż po kopiowanie dziesiątek z oryginalnych plików (m.in. aes.js o rozmiarze 8649 bajtów, blowfish.js, md5.js, sha256.js, itp.).

Jedyne obce i groźne pliki we wstrzykniętym archiwum to zaledwie jedno-linijkowy setup.js (wielkości 4209 bajtów) oraz czysty szablon konfiguracji package.md o rozmiarze 725 bajtów. Tutaj pełna analiza wstrzykniętego trojana.

Mam Axiosa — co robić, jak żyć?

Jeśli zainstalowałeś wersję 1.14.1 lub 0.30.4, musisz założyć najgorsze. Atakujący mogli mieć całkowity dostęp do Twojego systemu. Dlatego natychmiast:

• Sprawdź czy masz zainfekowane paczki. Stepsecurity sugeruje wykonanie tych poleceń:

  npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"
grep -A1 '"axios"' package-lock.json | grep -E "1\.14\.1|0\.30\.4"
ls node_modules/plain-crypto-js 2>/dev/null && echo "POTENTIALLY AFFECTED"
# macOS
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo "COMPROMISED"
# Linux
ls -la /tmp/ld.py 2>/dev/null && echo "COMPROMISED"
# Windows (cmd.exe)
dir "%PROGRAMDATA%\wt.exe" 2>nul && echo COMPROMISED

• Odłącz maszynę od internetu, zbierz ślady pod forensic, a jeśli nie zamierzasz lub nie potrafisz go przeprowadzać, to odtwórz maszynę z czystego backupu lub przeinstaluj.
• Zrotuj klucze SSH, klucze API, tokeny NPM i inne sekrety. Nie zapomnij o plikach .env. Zmień hasła.

Na przyszłość: Jeśli nie musisz, nie pozwalaj paczkom na samowolkę podczas instalacji. Używaj flagi npm ci –ignore-scripts. Warto też zauważyć, że oba wydania pozbawione były commitów (brak pola gitHead), oficjalnych tagów w repozytorium GitHub (wywołanie GitHub API o tag v1.14.1 zwracało błąd 404) oraz SLSA provenance attestations, które w wersji poprzedniej (1.14.0 i 0.30.3) były obecne. Warto się zastanowić, czy nie wykrywać tego typu anomalii przy zaciąganiu nowych wersji paczek. Albo czy nie opóźniać instalacji nowych paczek o kilka dni — jak widać po ostatnich atakach, community dość szybko wykrywa ataki, więc zamrożenie wersji zależności może być dobrym ogranicznikiem ryzyka.

~/.config/uv/uv.toml
exclude-newer = "7 days"
~/.npmrc
min-release-age=7 # days
ignore-scripts=true
~/Library/Preferences/pnpm/rc
minimum-release-age=10080 # minutes
~/.bunfig.toml
[install]
minimumReleaseAge = 604800 # seconds

Jeśli potrzebujecie zadbać o bezpieczeństwo swoich projektów programistycznych od A do Z, to zapraszamy na nasze turbo-praktyczne szkolenie “Bezpieczeństwo Webaplikacji“, w ramach którego podczas praktycznych 2-dniowych warsztatów pokazujemy jakich błędów przy tworzeniu oprogramowania uniknąć i jak im zapobiegać. Średnia ocen tego szkolenia to 9,45/10. Oto najbliższe terminy tego szkolenia:

Podzielcie się tym info z kolegami i koleżankami z zespołów. Kto pierwszy w biurze wpisał w nocy lub nad ranem npm update, ten potrzebuje pomocy. Sprawdźcie też czy jakieś automatyzacje nie budowały/aktualizowały Wam przez noc softu/środowiska w oparciu o axiosa. Wygląda na to, że nocne kodowanie to jednak nie taki zen…