- Zlonamerne izdaje sistema Axios na npm so dodale skrito odvisnost, ki je med namestitvijo namestila trojanca za oddaljeni dostop za več platform.
- Napadalci so zlorabili ogrožen vzdrževalni račun in starejše žetone npm za objavo axios@1.14.1, axios@0.30.4 in plain-crypto-js@4.2.1.
- RAT bi lahko izkopal skrivnosti, dostopal do repozitorijev in oblačnih okolij, z IOC-ji, vključno s sfrclak.com, 142.11.206.73 in specifičnimi artefakti datotečnega sistema.
- Varnostne ekipe pozivajo razvijalce, naj pregledajo datoteke zaklepanja, rotirajo poverilnice, okrepijo delovne procese v dobavni verigi in prizadete stroje obravnavajo kot popolnoma ogrožene.

Nekaj napetih ur je ena najbolj razširjenih knjižnic JavaScript na planetu, Axios, je postal nepričakovano sredstvo za dostavo zlonamerne programske opreme. Ciljno usmerjena Napad dobavne verige na ekosistem NPM rutinsko posodabljanje odvisnosti spremenilo v potencialna zadnja vrata za napadalce na več sto tisoč razvijalskih računalnikih in sistemih za gradnjo.
Preiskovalci več varnostnih podjetij in Googlove skupine za obveščanje o grožnjah so ugotovili, kako je zlonamerni akter izmuznil trojanec za oddaljeni dostop (RAT) v določene izdaje Axiosa na npm, podobno kot črv dobavne verige npm.
Kaj je Axios in zakaj je kompromis tako pomemben
V svojem bistvu je Axios HTTP odjemalec, ki temelji na obljubah, za Node.js in brskalnikeDeluje v ozadju neštetih projektov in obravnava vsakodnevna opravila, kot sta »pridobivanje sporočil s strežnika« ali »pošiljanje tega obrazca v API«, ne da bi morali razvijalci ročno pisati nizkonivojsko omrežno kodo.
Ker deluje tako v brskalniku kot na strežnikih Node.js, je Axios postal temeljna odvisnost v sodobnih skladih JavaScriptaMorda ga nikoli niste izrecno namestili, vendar se nanj še vedno posredno zanašate, ko:
- Uporabljajte spletne aplikacije, zgrajene z ogrodji, kot so React, Vue ali Angular, ki svoje klice API-ja ovijejo z Axios.
- Zaženite namizne ali mobilne aplikacije, zgrajene na tehnologijah, kot so Electron, React Native in podobnih spletnih izvajalnih okoljih.
- Interakcija z manjšimi orodji SaaS, skrbniškimi nadzornimi ploščami ali samostojno gostovanimi storitvami, katerih razvijalci so za zahteve HTTP izbrali Axios.
V tem smislu je Axios nekoliko podoben vodovodne instalacije v vaši hišiRedko pomislite na to, ampak prenaša podatkovno »vodo« med vašo aplikacijo in zunanjim svetom. Zares opazite to šele, ko pride do uhajanja – natanko to, kar je povzročil ta napad, vendar na ravni programskega ekosistema.
Kako se je razpletel napad na Axios npm
Incident se osredotoča na dve izdaji npm: axios@1.14.1 in axios@0.30.4Napadalcem je uspelo objaviti z uporabo ogroženih poverilnic enega glavnih vzdrževalcev projekta. zlonamerne gradnje neposredno v npm medtem ko javna izvorna koda GitHuba ostane nedotaknjena, vzorec, opisan tudi v Analiza Shai-Huluda.
Namesto vidnega spreminjanja Axiosove kode je napadalec dodal novo, na videz nepovezano odvisnost: plain-crypto-js@4.2.1Ta paket je bil izdelan posebej za operacijo in ni bil uvožen nikamor v izvorne datoteke programa Axios, rdeča zastavica za vsakogar, ki natančno preučuje razliko – vendar jo je v avtomatiziranih delovnih procesih, ki preprosto zaupajo registru, enostavno spregledati.
Skupaj sta imeli obe okuženi različici sistema Axios ogromen potencialni odtis, ki je dosegel do približno 100 milijonov tedenskih prenosov na npmOcenjuje se, da je Axios prisoten v skoraj 80 % oblačnih okolij in cevovodov CI/CD, zato je že kratkotrajno okno izpostavljenosti predstavljalo resno sistemsko tveganje.
Ključno je, da se prizadete različice nikoli niso pojavile v uradne oznake GitHuba za projekt Axios. Ta podrobnost močno nakazuje, da so bili običajni postopki izdaje zaobiti: napadalec je izkoristil ukraden žeton npm, da je pakete poslal neposredno v register, izven zgodovine javnega vira.
Mehanika zlonamerne odvisnosti in RAT
Bistvo kompromisa je v tem, kaj se je zgodilo med namestitvijo. Vsak delovni tok, ki se je izvajal npm install in potegnil noter axios@1.14.1, axios@0.30.4 or plain-crypto-js@4.2.1 z omogočenimi skripti je sprožil skrito rutino po namestitvi.
Znotraj zlonamerne odvisnosti, a skript po namestitvi (node setup.js) Izveden samodejno. Ta skripta je prenesla zakriti skript, ki je nato pridobil platformo-specifični RAT koristni tovor, prilagojen macOS, Windows ali LinuxRAT je napadalcu omogočil interaktivni oddaljeni dostop do ogroženega računalnika.
Ko je ta trojanski konj za oddaljeni dostop aktiven, lahko prešteje sistem, zbira skrivnosti in izvaja poljubne ukaze. Pomislite ključi API-ja v oblaku, žetoni za uvajanje CI, žetoni za avtorizacijo npm, ključi SSH, žetoni za dostop do repozitorija in druge občutljive spremenljivke okolja pogosto vbrizgan v gradbene agente ali prenosnike razvijalcev.
Od tam naprej bi se lahko napadalci usmerili: preverjali izvorno kodo, spreminjali prihodnje izdaje, dodajali več zadnjih vrat ali se premikali bočno v produkcijsko infrastrukturo. Za razvijalce, ki delajo na projektih, povezanih s kriptovalutami – denarnicah, borzah, DeFi frontendih – bi se ta vrsta dostopa lahko neposredno prenesla v kraja kriptovalut ali širša finančna goljufija.
Prikrite taktike: zakaj je bilo kompromis težko opaziti
Avtorji zlonamerne programske opreme so se zelo potrudili, da bi njihov vpliv čim bolj zmanjšali in ohranili kratkotrajnost. Po mnenju raziskovalcev je programska oprema za odstranjevanje virusov očistil svoje sledi takoj po izvedbi.
To pomeni, da če ste pregledali node_modules/plain-crypto-js/package.json po okužbe, bi videli popolnoma neškodljiv manifest: nobenega skripta po namestitvi, nobenega setup.js, brez očitnih znakov nepoštene igre. Standardna orodja, kot so npm audit ali pa bežen ročni pregled imenika ne bi razkril, kaj se je že zgodilo.
V praksi so se zaradi tega vedenja preiskovalci zanašali na zunanje kazalniki kompromisa (IOC), omrežno telemetrijo in artefakte gostitelja namesto preprostih statičnih pregledov vsebine paketa npm. Ko je bil napad javen, so bile zlonamerne različice že odstranjene iz npm, kar je še dodatno otežilo rekonstrukcijo natančnega poteka izvajanja.
Ključni kazalniki kompromitacije za incident Axios
Čeprav je zlonamerna programska oprema poskušala prikriti svoje sledi, so varnostne ekipe delile konkretne IOC-je, ki lahko pomagajo ugotoviti, ali je bilo okolje prizadeto. Med najpomembnejšimi so naslednji:
o omrežna stran, poiščite komunikacijo z:
- Domena: sfrclakcom
- IP naslov: 142.11.206.73
Oba kazalnika so blokirali glavni ponudniki varnostnih rešitev, vendar ostajata uporabna označevalca v zgodovinskih dnevnikih in iskanjih SIEM.
o datotečni sistem, so raziskovalci izpostavili artefakte, povezane z RAT:
- MacOS:
/Library/Caches/com.apple.act.mond - Linux:
/tmp/ld.py - Windows: datoteke pod
%PROGRAMDATA%\wtin začasne skripte, kot so%TEMP%\6202033.vbsor.ps1ki lahko med izvajanjem obstajajo le kratek čas
Kar zadeva npm pakete, ogrožene gradnje in njihove znane kontrolne vsote je:
- axios@1.14.1, SHA-256:
2553649f2322049666871cea80a5d0d6adc700ca - axios@0.30.4, SHA-256:
d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71 - plain-crypto-js@4.2.1, SHA-256:
07d889e2dadce6f3910dcbc253317d28ca61c766
Varnostna podjetja, kot je Huntress, so opazila vsaj 135 sistemov, ki vzpostavljajo stik z napadalčevim strežnikom za upravljanje in nadzor med relativno kratkim obdobjem izpostavljenosti, raziskovalci iz Googla pa so opozorili, da je bilo zaradi tega morda na koncu odkritih »sto tisoč« skrivnosti.
Kdo je stal za napadom? Pripisovanje in povezava s Severno Korejo
Googlova skupina za obveščanje o grožnjah je javno povezala ogrožanje sistema Axios z domnevni severnokorejski akter grožnje sleden kot UNC1069. John Hultquist, glavni analitik v Googlovi enoti za grožnje, je opozoril, da imajo severnokorejski operaterji dolgoletne izkušnje napadi v dobavni verigi, katerih cilj je krajo kriptovalut in drugo premoženje.
Po mnenju Googla in drugih ponudnikov varnostnih rešitev se zdi, da je incident z Axiosom del širše kampanje severnokorejskih skupin, vključno s podjetji, kot je Lazarus, ki se osredotočajo na izsiljevanje, finančna krajo in odtujitev podatkov ciljajoč na sektorje, kot so kriptovalute, fintech in infrastruktura v oblaku.
Čeprav celoten vpliv še ni jasen, kombinacija izjemno priljubljenega paketa, dostopa do razvijalskih okolij in narave ukradenih podatkov analitike navaja k pričakovanju nadaljnji napadi v obliki nadaljnjih vdorov v dobavno verigo, izsiljevalske programske opreme in neposredne kraje kriptovalut.
Kako sta bila zlorabljena vzdrževalni račun in potek dela npm
Eden najbolj zaskrbljujočih vidikov za skupnost odprte kode je, kako je napadalcem uspelo objaviti zlonamerne različice Axiosa, ne da bi se dotaknili javne kodne baze. Ključ je bil ogrožen vzdrževalni račun na npm, za katerega se domneva, da pripada glavnemu vzdrževalcu sistema Axios, znanemu kot jasonsaayman.
Napadalci naj bi spremenili e-poštni naslov, povezan s tem npm računom, v naslov, ki ga nadzorujejo. S tem korakom bi lahko zaklenite legitimnega vzdrževalca in objavljati nove različice paketov, kot da bi šlo za pristne posodobitve, medtem ko je uradni repozitorij GitHub ostal čist.
Operacija je osvetlila tudi strukturno težavo v npm: podporo za starejši žetoni za preverjanje pristnosti, in potrebo po orodja za upravljanje dobavne verige in strožje politike žetonov.
V tem primeru so varnostni raziskovalci poudarili, da npm še vedno privzeto uporabljen starejši žeton za objavljanje in noben nadzor ni samodejno preklical tega žetona, ko so bile konfigurirane nove sodobne metode objavljanja. Ta sobivanje je ustvarilo ranljiva stranska vrata, ki bi jih UNC1069 lahko izkoristil.
Okno izpostavljenosti in zgodnje odkrivanje
Kompromis Axiosa ni bil dolgotrajen in počasen. Preiskave kažejo, da so bile zlonamerne različice na voljo na npm približno tri ure med pozno nedeljo zvečer in zgodnjimi jutranjimi urami ponedeljka ali torka, odvisno od časovnega pasu.
StepSecurity in druga podjetja so opozorila, da je napadalec v ekosistem vnesel čista različica zlonamerne odvisnosti približno 18 ur prej pritrditev oborožene različice na Axios. Zdi se, da je bila ta poteza zasnovana tako, da bi ustvarila neškodljivo zgodovino paketa in preprečila sprožitev avtomatskih detektorjev anomalij, ko se je odvisnost nenadoma pojavila.
Ko so bile okužene različice Axiosa objavljene, je trojanski konj opravil obsežno izvidovanje na vsakem sistemu, kjer se je izvajal: skeniranje imenikov, seznam delujočih procesov, naštevanje diskov in nato pošiljanje teh informacij nazaj na napadalčev strežnik. Vse to se je dogajalo v ozadju med tem, kar je razvijalcem izgledalo kot rutinska namestitev odvisnosti.
Zahvaljujoč usklajenemu odzivu vzdrževalca, npm in več ponudnikov varnostnih rešitev so bile zlonamerne različice odstranjene v nekaj urah. Vendar pa je, kot je poudarilo več raziskovalcev in Googlova lastna ekipa, Kratko obdobje izpostavljenosti ni isto kot nizko tveganje ko je cilj knjižnica z več deset milijoni tedenskih prenosov.
Vpliv na razvijalce, kripto projekte in končne uporabnike
S praktičnega vidika so najbolj neposredne žrtve incidenta Axios razvijalci in gradbena okolja ki je namestil zlonamerne različice. Vsakdo, ki je zagnal namestitev ali gradnjo, ki je namestila axios@1.14.1, axios@0.30.4 ali plain-crypto-js@4.2.1 z omogočenimi skripti, mora domnevati, da je sistem lahko popolnoma ogrožen.
Za projekte na področju kriptovalut – denarnice, centralizirane in decentralizirane borze, nadzorne plošče DeFi, trgovalne bote in vmesnike Web3 – so vložki še posebej visoki. Mnogi od teh sistemov zanašajo se na Axios za komunikacijo z verižnimi prehodi, API-ji in zalednimi storitvamiin pogosto upravljajo občutljive skrivnosti, kot so zasebni ključi, poverilnice API-ja in uporabniški podatki.
Če bi bila delovna postaja razvijalca ali agent CI v takšnem projektu okužena, bi napadalci lahko pridobili ne le lokalno shranjene skrivnosti, temveč tudi dostop do repozitorijev in cevovodov za uvajanjeS tem bi lahko v prihodnje izdaje vbrizgali zlonamerno kodo, posredno ogrozili končne uporabnike ali preusmerili sredstva.
Nasprotno pa so uporabniki, ki preprosto zaženejo dokončane aplikacije v svojem brskalniku, v boljšem položaju: RAT je bil dostavljen med koraki namestitve in gradnje, ne med izvajanjem v brskalniku. Torej obisk spletnega mesta, ki uporablja Axios za klice na strani odjemalca, sam po sebi ne sproži napada. Tveganje je osredotočeno na tiste, ki so namestili prizadete npm pakete.
Takojšnji ukrepi, ki jih morajo razvijalci sprejeti
Varnostne ekipe in vzdrževalci so bili jasni: če obstaja kakršna koli možnost, da so vaši sistemi prenesli ogrožene izdaje Axios ali plain-crypto-js, obravnavajte te gostitelje kot popolnoma nezanesljivo, dokler se ne preiščeTo pomeni več kot le povečanje številke različice.
Konkretni ukrepi, ki jih priporočajo raziskovalci in prodajalci, vključujejo:
- Preverite svoje odvisnosti in zaklepne datoteke: Išči
axios@1.14.1,axios@0.30.4inplain-crypto-js@4.2.1inpackage-lock.json,pnpm-lock.yaml,yarn.lockin dnevnike CI; glejte kako jih varno popraviti. - Nadgradite na preverjene varne različice: Premaknite se na čiste izdaje Axiosa (na primer takoj zatemnjene oznake, ki jih priporočajo vzdrževalci) in zagotovite, da so vaše datoteke zaklepanja obnovljene.
- Agresivno menjajte poverilnice: Predpostavimo, da so bile morebitne skrivnosti na prizadetih računalnikih ali cevovodih – ključi API-ja v oblaku, žetoni npm, ključi SSH, ključi za uvajanje, spremenljivke .env – ukradene, in jih zamenjamo.
- Obnova ogroženih sistemov: Kjer je mogoče, ponovno namestite agente za gradnjo, izvajalce neomejene izbire in delovne postaje razvijalcev iz zaupanja vrednih slik, namesto da jih poskušate očistiti na mestu.
- Infrastruktura bloka C2: Dodaj
sfrclak.comin142.11.206.73na požarne zidove, sezname blokiranih DNS-ov in pravila EDR. - Lov na artefakte: Preverite poti datotečnega sistema in začasne datoteke, povezane z RAT v gostiteljih macOS, Windows in Linux.
Več varnostnih podjetij je organizacijam, ki so namestile okužene različice, svetovalo, naj predpostavljati kompromis po privzetih nastavitvahZ drugimi besedami, nadaljujte s predpostavko, da so imeli napadalci dostop, in sistematično izvajajte korake za odzivanje na incidente, namesto da upate, da zlonamerna programska oprema ni storila ničesar.
Širše lekcije za varnost dobavne verige programske opreme
Poleg neposredne triaže je incident Axios ponovno sprožil razprave o tem, kako širši ekosistem obravnava zaupanje, identiteto in distribucijo odprtokodne programske opreme. Ponazarja, kako ... en sam račun vzdrževalca knjižnice lahko postane osrednja točka za varnostno držo neštetih organizacij.
Iz obdukcij po nakupu in analiz prodajalcev je bilo ugotovljenih več tem:
- Zastareli žetoni so breme: Stari žetoni npm lahko tiho vztrajajo skupaj z novejšimi delovnimi procesi, ki temeljijo na OIDC. Projekti potrebujejo eksplicitne politike za njihov preklic, ko so vzpostavljene varnejše metode.
- Samodejne posodobitve so obojestranske: Samodejno povečanje odvisnosti pospeši razvoj, hkrati pa pomeni, da se lahko zlonamerna izdaja širi po ekosistemih, preden to kdo opazi.
- Skeniranje odvisnosti je potrebno, vendar ne zadostno: Statični pregledi in
npm auditso koristni, vendar se borijo proti minljivo vedenje kot so samobrisanje skriptov po namestitvi. - Varnost vzdrževalca je kritična infrastruktura: Močna večfaktorska autentifikacija (MFA), strojna varnostna ključa, skrbno ravnanje z žetoni za dostop in redno pregledovanje, kdo lahko objavlja, so zdaj prav tako pomembni kot pisanje dobre kode.
Za ustanovitelje, tehnične direktorje in vodje inženiringa je kompromis Axios opomnik, da tveganje v dobavni verigi je strateško vprašanje, ne le tehnična. Vpliva na to, kako hitro lahko odpremite, kako oblikujete svoje cevovode CI/CD in kako uravnovesite udobje odprte kode s potrebo po preverjanju tega, kar izvajate v produkciji.
Skupno gledano, kompromitacija Axiosa na npm kaže, kako lahko kratkotrajen, a dobro načrtovan napad spremeni zaupanja vreden gradnik ekosistema JavaScript v prikrit kanal za zlonamerno programsko opremo za oddaljeni dostop. Ker napadalci ciljajo tako na vzdrževalce in distribucijske kanale kot na končne uporabnike, je ohranjanje zdravih dobavnih verig programske opreme zdaj odvisno od strožjega nadzora nad delovnimi procesi objavljanja, agresivnega spremljanja anomalij in pripravljenosti obravnavati odvisnosti z enakim skepticizmom, ki je bil nekoč rezerviran le za zunanji omrežni promet.