Axios bajo fuego: así se gestó el ataque a la cadena de suministro en npm

Home » Python » Axios bajo fuego: así se gestó el ataque a la cadena de suministro en npm

I noen anstrengte timer, et av de mest brukte JavaScript-bibliotekene på planeten, Axios, ble et uventet leveringsmiddel for skadelig programvare. En målrettet Angrep på forsyningskjeden på npm-økosystemet gjorde en rutinemessig avhengighetsoppdatering til en potensiell bakdør for angripere på hundretusenvis av utviklermaskiner og byggesystemer.

Etterforskere fra flere sikkerhetsfirmaer og Googles Threat Intelligence Group har samlet hvordan en ondsinnet aktør har sluppet unna en fjerntilgang trojaner (RAT) inn i spesifikke Axios-utgivelser på npm, likt den npm forsyningskjedeorm.

Hva Axios er og hvorfor kompromisset er så viktig

I kjernen er Axios en løftebasert HTTP-klient for Node.js og nettlesereDen sitter bak kulissene i utallige prosjekter, og håndterer hverdagsoppgaver som «hente meldingene mine fra serveren» eller «sende dette skjemaet til API-et» uten at utviklere trenger å skrive lavnivånettverkskode for hånd.

Fordi den kjører både i nettleseren og på Node.js-servere, har Axios blitt en grunnleggende avhengighet i moderne JavaScript-stablerDu har kanskje aldri installert det eksplisitt, men du er fortsatt avhengig av det indirekte når du:

• Bruk webapplikasjoner bygget med rammeverk som React, Vue eller Angular som pakker API-kallene sine inn i Axios.
• Kjør skrivebords- eller mobilapper bygget på teknologier som Electron, React Native og lignende nettbaserte kjøretider.
• Samhandle med mindre SaaS-verktøy, administrasjonsdashbord eller selvhostede tjenester der utviklerne valgte Axios for HTTP-forespørsler.

I så måte er Axios litt som rørleggerarbeid i huset dittDu tenker sjelden på det, men det fører data-"vannet" mellom appen din og omverdenen. Du merker det egentlig bare når det er en lekkasje – akkurat det dette angrepet skapte, men på programvareøkosystemnivå.

Hvordan Axios npm-angrepet utspilte seg

Hendelsen dreier seg om to npm-utgivelser: axios@1.14.1 og axios@0.30.4Ved å bruke kompromitterte legitimasjonsopplysninger for en av prosjektets hovedvedlikeholdere, klarte angriperne å publisere ondsinnede bygg direkte til npm mens den offentlige GitHub-kildekoden ikke påvirkes, et mønster som også er beskrevet i Shai-Hulud-analyse.

I stedet for å synlig endre Axios' kode, la angriperen til en ny, tilsynelatende urelatert avhengighet: vanlig-krypto-js@4.2.1Denne pakken ble laget spesielt for driften og ble ikke importert noe sted i Axios' kildefiler, et rødt flagg for alle som gransker diff-en – men lett å overse i automatiserte arbeidsflyter som ganske enkelt stoler på registeret.

Sammen hadde de to forfalne axios-versjonene et enormt potensielt fotavtrykk, som strakte seg opp til rundt 100 millioner ukentlige nedlastinger på npmAxios er anslått å være tilstede i nesten 80 % av skymiljøer og CI/CD-pipelines, så selv et kort eksponeringsvindu representerte en alvorlig systemisk risiko.

Avgjørende er det at de berørte versjonene aldri dukket opp i offisielle GitHub-tagger for Axios-prosjektet. Denne detaljen tyder sterkt på at normale utgivelsesprosesser ble omgått: angriperen utnyttet et stjålet npm-token til å sende pakker direkte til registeret, utenfor båndet fra den offentlige kildehistorikken.

Mekanikken bak den ondsinnede avhengigheten og RAT

Kjernen i kompromisset ligger i hva som skjedde under installasjonen. Enhver arbeidsflyt som kjørte npm install og trakk inn axios@1.14.1, axios@0.30.4 or vanlig-krypto-js@4.2.1 med aktiverte skript utløste en skjult etterinstallasjonsrutine.

Inne i den ondsinnede avhengigheten, en postinstall-skript (node ​​setup.js) utført automatisk. Skriptet lastet ned en obfuskert dropper, som deretter hentet en plattformspesifikk RAT-nyttelast skreddersydd til macOS, Windows eller LinuxRAT-en ga angriperen interaktiv fjerntilgang til den kompromitterte maskinen.

Når den er aktiv, kan denne trojaneren for fjerntilgang liste opp systemet, samle hemmeligheter og kjøre vilkårlige kommandoer. Cloud API-nøkler, CI-distribusjonstokener, npm-autentiseringstokener, SSH-nøkler, tilgangstokener for repositorier og andre sensitive miljøvariabler vanligvis injisert i byggeagenter eller bærbare datamaskiner for utviklere.

Derfra kunne angripere snu: sjekke kildekode, tukle med fremtidige utgivelser, legge til flere bakdører eller bevege seg sidelengs inn i produksjonsinfrastrukturen. For utviklere som jobber med kryptorelaterte prosjekter – lommebøker, børser, DeFi-grensesnitt – kan denne typen tilgang oversettes direkte til kryptovalutatyveri eller bredere økonomisk svindel.

Sniktaktikk: hvorfor kompromisset var vanskelig å få øye på

Skadevareutviklerne gjorde en stor innsats for å holde fotavtrykket sitt så lite og flyktig som mulig. Ifølge forskere, dropperen ryddet opp sporene sine umiddelbart etter henrettelse.

Det betyr at hvis du undersøkte node_modules/plain-crypto-js/package.json etter infeksjon, ville du se et helt uskyldig manifest: intet etterinstallasjonsskript, nei setup.js, ingen åpenbare indikatorer på uaktsomhet. Standardverktøy som npm audit eller en overfladisk manuell katalogsjekk ville ikke avsløre hva som allerede hadde skjedd.

I praksis gjorde denne oppførselen at etterforskerne var avhengige av eksterne indikatorer på kompromiss (IOC-er), nettverkstelemetri og vertsartefakter i stedet for enkle statiske skanninger av npm-pakkeinnholdet. Da angrepet ble offentliggjort, var de skadelige versjonene allerede hentet fra npm, noe som ytterligere kompliserte rekonstruksjonen av den nøyaktige utførelsesflyten.

Viktige indikatorer på kompromiss for Axios-hendelsen

Selv om skadevaren prøvde å dekke over sporene sine, har sikkerhetsteam delt konkrete IOC-er som kan bidra til å avgjøre om et miljø ble påvirket. Blant de viktigste er følgende:

På nettverkssiden, se etter kommunikasjon med:

• Domain: sfrclakcom
• IP adresse: 142.11.206.73

Begge indikatorene har blitt blokkert av vanlige sikkerhetsleverandører, men de er fortsatt nyttige markører i historiske logger og SIEM-søk.

På filsystem, fremhevet etterforskerne gjenstander knyttet til RAT:

• MacOS: /Library/Caches/com.apple.act.mond
• Linux: /tmp/ld.py
• Windows: filer under %PROGRAMDATA%\wt og midlertidige skript som %TEMP%\6202033.vbs or .ps1 som kanskje bare eksisterer kortvarig under utførelsen

Når det gjelder npm-pakker, kompromitterte bygg og deres kjente sjekksummer er:

• axios@1.14.1, SHA-256: 2553649f2322049666871cea80a5d0d6adc700ca
• axios@0.30.4, SHA-256: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
• vanlig-krypto-js@4.2.1, SHA-256: 07d889e2dadce6f3910dcbc253317d28ca61c766

Sikkerhetsfirmaer som Huntress observerte minst 135 systemer kontakter angriperens kommando- og kontrollserver i løpet av det relativt korte eksponeringsvinduet, og forskere fra Google advarte om at «hundretusenvis» av hemmeligheter til slutt kan ha blitt tappet bort som et resultat.

Hvem sto bak angrepet? Tilskrivelse og koblingen til Nord-Korea

Googles trusselintelligensgruppe har offentlig koblet Axios-kompromisset til en mistenkt nordkoreansk trusselaktør sporet som UNC1069. John Hultquist, sjefanalytiker i Googles trusselenhet, bemerket at nordkoreanske operatører har en lang merittliste med Angrep i forsyningskjeden som tar sikte på å stjele kryptovaluta og andre eiendeler.

Ifølge Google og andre sikkerhetsleverandører ser Axios-hendelsen ut til å være en del av en bredere kampanje fra nordkoreanske grupper, inkludert organisasjoner som Lazarus, som fokuserer på utpressing, økonomisk tyveri og datainnsamling rettet mot sektorer som krypto, fintech og skyinfrastruktur.

Selv om den fulle virkningen fortsatt er uklar, fører kombinasjonen av en enormt populær pakke, tilgang til utviklermiljøer og arten av de stjålne dataene til at analytikere forventer oppfølgingsangrep i form av ytterligere brudd på forsyningskjeden, ransomware og direkte kryptotyveri.

Hvordan vedlikeholderkontoen og npm-arbeidsflyten ble misbrukt

Et av de mest urovekkende aspektene for åpen kildekode-miljøet er hvordan angriperne klarte å publisere ondsinnede Axios-versjoner uten å berøre den offentlige kodebasen. Nøkkelen var en kompromittert vedlikeholderkonto på npm, antatt å tilhøre en primær Axios-vedlikeholder kjent som jasonsaayman.

Angriperne skal ha endret e-postadressen knyttet til den npm-kontoen til en adresse de kontrollerte. Med det trinnet kunne de låse ute den legitime vedlikeholderen og publisere nye pakkeversjoner som om de var ekte oppdateringer, alt mens det offisielle GitHub-depotet forble rent.

Operasjonen kastet også lys over et strukturelt problem i npm: støtte til eldre autentiseringstokener, og behovet for verktøy for forsyningskjedestyring og strengere tokenregler.

I dette tilfellet påpekte sikkerhetsforskere at npm fortsatt standardisert til den eldre tokenen for publisering, og ingen kontroll tilbakekalte automatisk den tokenen når mer moderne publiseringsmetoder ble konfigurert. Denne sameksistensen skapte en sårbar sidedør som UNC1069 kunne utnytte.

Eksponeringsvindu og tidlig deteksjon

Axios-kompromisset var ikke en lang og langsom prosess. Undersøkelser tyder på at de skadelige versjonene var tilgjengelig på npm i omtrent tre timer mellom sen søndag kveld og de tidlige timene på mandag eller tirsdag, avhengig av tidssone.

StepSecurity og andre firmaer bemerket at angriperen hadde sådd økosystemet med en ren versjon av den ondsinnede avhengigheten omtrent 18 timer før å knytte den våpenbaserte varianten til Axios. Dette trekket ser ut til å ha blitt utformet for å bygge en godartet historie for pakken og unngå å utløse automatiserte anomalidetektorer da avhengigheten plutselig dukket opp.

Så snart de infiserte Axios-utgivelsene ble lansert, utførte trojaneren omfattende rekognosering på hvert system der den kjørte: skanne kataloger, liste opp kjørende prosesser, liste opp disker og deretter sende den informasjonen tilbake til angriperens server. Alt dette skjedde bak kulissene under det som for utviklerne så ut som en rutinemessig avhengighetsinstallasjon.

Takket være koordinert respons fra vedlikeholderen, npm og flere sikkerhetsleverandører, ble de skadelige versjonene fjernet innen få timer. Likevel, som flere forskere og Googles eget team understreket, Et kort eksponeringsvindu er ikke det samme som lav risiko når målet er et bibliotek med titalls millioner ukentlige nedlastinger.

Innvirkning på utviklere, kryptoprosjekter og sluttbrukere

Fra et praktisk synspunkt er de mest direkte ofrene for Axios-hendelsen utviklere og byggemiljøer som installerte de skadelige versjonene. Alle som kjørte en installasjon eller et bygg som hentet inn axios@1.14.1, axios@0.30.4 eller plain-crypto-js@4.2.1 med skript aktivert, må anta at systemet kan være fullstendig kompromittert.

For prosjekter innen kryptovaluta – lommebøker, sentraliserte og desentraliserte børser, DeFi-dashboards, handelsroboter og Web3-grensesnitt – er innsatsen spesielt høy. Mange av disse systemene stole på Axios for å kommunisere med blokkjedegatewayer, API-er og backend-tjenester, og de administrerer ofte sensitive hemmeligheter som private nøkler, API-legitimasjon og brukerdata.

Hvis en utviklerarbeidsstasjon eller CI-agent i et slikt prosjekt ble infisert, kunne angripere ikke bare ha fått tak i hemmelighetene som er lagret lokalt, men også tilgang til repositorier og distribusjonsrørledningerMed det kan de injisere skadelig kode i fremtidige utgivelser, kompromittere sluttbrukere indirekte eller omdirigere midler.

Til sammenligning er brukere som bare kjører ferdige applikasjoner i nettleseren sin i en bedre posisjon: RAT-en ble levert i løpet av installasjons- og byggetrinn, ikke under kjøretid i nettleseren. Så det å besøke et nettsted som bruker Axios for klientsidekall utløser ikke i seg selv angrepet. Risikoen konsentrerer seg om de som installerte de berørte npm-pakkene.

Umiddelbare skritt som utviklere bør ta

Sikkerhetsteam og vedlikeholdere har vært tydelige: hvis det er noen sjanse for at systemene deres hentet inn de kompromitterte Axios- eller ren-crypto-js-utgivelsene, behandle disse vertene som fullstendig upålitelig inntil etterforsketDet betyr mer enn bare å oppdatere et versjonsnummer.

Konkrete tiltak anbefalt av forskere og leverandører inkluderer:

• Revider avhengighetene og låsefilene dine: Søk etter axios@1.14.1, axios@0.30.4 og plain-crypto-js@4.2.1 in package-lock.json, pnpm-lock.yaml, yarn.lock og CI-logger; se hvordan fikse dem trygt.
• Oppgrader til bekreftede, sikre versjoner: Gå til rene Axios-utgivelser (for eksempel de umiddelbart påfølgende oppdaterte taggene anbefalt av vedlikeholderne) og sørg for at låsefilene dine genereres på nytt.
• Roter legitimasjon aggressivt: Anta at eventuelle hemmeligheter som finnes på berørte maskiner eller pipelines – sky-API-nøkler, npm-tokener, SSH-nøkler, distribusjonsnøkler, .env-variabler – kan ha blitt stjålet, og roter dem.
• Gjenoppbygg kompromitterte systemer: Der det er mulig, distribuer byggeagenter, CI-løpere og utviklerarbeidsstasjoner fra klarerte avbildninger i stedet for å prøve å rydde dem opp på stedet.
• Infrastruktur i blokk C2: Legg til sfrclak.com og 142.11.206.73 til brannmurer, DNS-blokkeringslister og EDR-regler.
• Jakt på gjenstander: Se etter filsystembanene og midlertidige filer som er knyttet til RAT på macOS-, Windows- og Linux-verter.

Flere sikkerhetsselskaper har rådet organisasjoner som installerte de forfalskede versjonene til å anta kompromiss som standardMed andre ord, forutsett at angriperne hadde tilgang, og jobb systematisk gjennom hendelsesresponstrinnene i stedet for å håpe at skadevaren ikke gjorde noe.

Bredere lærdommer for sikkerhet i programvareforsyningskjeden

Utover den umiddelbare prioriteringen har Axios-hendelsen gjenopplivet debatter om hvordan det bredere økosystemet håndterer tillit, identitet og distribusjon i åpen kildekode. Den illustrerer hvordan en enkelt bibliotekvedlikeholderkonto kan bli en hjørnestein for sikkerhetsstillingen til utallige organisasjoner.

Flere temaer har dukket opp fra obduksjoner og leverandøranalyser:

• Eldre tokens er en belastning: Gamle npm-tokens kan stille fortsette sammen med nyere OIDC-baserte arbeidsflyter. Prosjekter trenger eksplisitte retningslinjer for å tilbakekalle dem når tryggere metoder er på plass.
• Automatiske oppdateringer går begge veier: Automatiske avhengighetsforandringer fremskynder utviklingen, men betyr også at en ondsinnet utgivelse kan spre seg gjennom økosystemer før noen legger merke til det.
• Avhengighetsskanning er nødvendig, men ikke tilstrekkelig: Statiske kontroller og npm audit er nyttige, men de kjemper mot flyktig oppførsel som selvslettende skript etter installasjon.
• Vedlikeholdersikkerhet er kritisk infrastruktur: Sterk MFA, maskinvaresikkerhetsnøkler, nøye håndtering av tilgangstokener og regelmessig gjennomgang av hvem som kan publisere er nå like viktig som å skrive god kode.

For grunnleggere, teknologidirektører og ingeniørledere er Axios-kompromisset en påminnelse om at Risiko i forsyningskjeden er et strategisk problem, ikke bare en teknisk en. Det påvirker hvor raskt du kan sende, hvordan du designer CI/CD-pipelinene dine, og hvordan du balanserer bekvemmeligheten med åpen kildekode med behovet for å verifisere det du kjører i produksjon.

Samlet sett viser kompromisset med Axios på npm hvordan et kortvarig, men godt planlagt angrep kan gjøre en pålitelig byggestein i JavaScript-økosystemet om til en skjult kanal for skadelig programvare for ekstern tilgang. Med angripere som retter seg mot vedlikeholdere og distribusjonskanaler like mye som sluttbrukere, avhenger det nå av strengere kontroller rundt publiseringsarbeidsflyter, aggressiv overvåking av avvik og en vilje til å behandle avhengigheter med samme skepsis som en gang bare var forbeholdt ekstern nettverkstrafikk.