Axios bajo fuego: així es va gestar l'atac a la cadena de suministro en npm

Inici » Pitó » Axios bajo fuego: així es va gestar l'atac a la cadena de suministro en npm

Durant unes hores tenses, una de les biblioteques JavaScript més utilitzades del planeta, Axios, es va convertir en un vehicle de distribució inesperat per a programari maliciós. Un objectiu Atac a la cadena de subministrament a l'ecosistema NPM va convertir una actualització rutinària de dependències en una possible porta del darrere per a atacants a centenars de milers de màquines de desenvolupador i sistemes de compilació.

Investigadors de diverses empreses de seguretat i del Grup d'Intel·ligència d'Amenaces de Google van desxifrar com un actor maliciós va colar un troià d'accés remot (RAT) en versions específiques d'Axios a npm, similars a cuc de la cadena de subministrament npm.

Què és Axios i per què importa tant el compromís

En essència, Axios és un client HTTP basat en promeses per a Node.js i navegadorsEs troba entre bastidors en innombrables projectes, gestionant tasques quotidianes com ara "recuperar els meus missatges del servidor" o "enviar aquest formulari a l'API" sense que els desenvolupadors hagin d'escriure codi de xarxa de baix nivell a mà.

Com que s'executa tant al navegador com als servidors Node.js, Axios s'ha convertit en una dependència fonamental en piles de JavaScript modernesPotser no l'has instal·lat mai explícitament, però encara hi confies indirectament quan:

• Utilitzeu aplicacions web creades amb frameworks com React, Vue o Angular que encapsulin les seves crides a l'API amb Axios.
• Executar aplicacions d'escriptori o mòbils basades en tecnologies com Electron, React Native i entorns d'execució similars basats en web.
• Interactua amb eines SaaS més petites, quadres de comandament d'administració o serveis autoallotjats els desenvolupadors dels quals han triat Axios per a sol·licituds HTTP.

En aquest sentit, Axios és una mica com fontaneria a casa teva: poques vegades hi penses, però transporta l'"aigua" de dades entre la teva aplicació i el món exterior. Només ho notes realment quan hi ha una filtració, exactament el que va crear aquest atac, però a escala d'ecosistema de programari.

Com es va desenvolupar l'atac Axios npm

L'incident se centra en dos llançaments de npm: axios@1.14.1 i axios@0.30.4Utilitzant les credencials compromeses d'un dels principals mantenidors del projecte, els atacants van aconseguir publicar compilacions malicioses directament a npm tot deixant intacte el codi font públic de GitHub, un patró també descrit a Anàlisi de Shai-Hulud.

En lloc d'alterar visiblement el codi d'Axios, l'atacant va afegir una nova dependència aparentment no relacionada: plain-crypto-js@4.2.1Aquest paquet va ser dissenyat específicament per a l'operació i no s'ha importat enlloc dels fitxers font d'Axios, un senyal d'alerta per a qualsevol que estigui examinant la diferència, però és fàcil de passar per alt en fluxos de treball automatitzats que simplement confien en el registre.

Juntes, les dues versions d'axios contaminades tenien una enorme petjada potencial, que arribava fins a al voltant de 100 milions de descàrregues setmanals a npmEs calcula que Axios és present en prop del 80% dels entorns de núvol i les pipelines de CI/CD, de manera que fins i tot una breu finestra d'exposició representava un risc sistèmic greu.

Crucialment, les versions afectades mai van aparèixer a la etiquetes oficials de GitHub per al projecte Axios. Aquest detall suggereix fermament que es van ometre els processos normals de llançament: l'atacant va aprofitar un testimoni npm robat per enviar paquets directament al registre, fora de banda de l'historial de codi font públic.

La mecànica de la dependència maliciosa i la RAT

El cor del compromís rau en el que va passar en el moment de la instal·lació. Qualsevol flux de treball que s'hagi executat npm install i va entrar axios@1.14.1, axios@0.30.4 or plain-crypto-js@4.2.1 amb els scripts habilitats ha activat una rutina de postinstal·lació oculta.

Dins de la dependència maliciosa, un script de postinstal·lació (node ​​setup.js) executat automàticament. Aquest script descarregava un dropper ofuscat, que després obtenia una càrrega útil RAT específica de la plataforma adaptada a macOS, Windows o LinuxEl RAT va concedir a l'atacant accés remot interactiu a la màquina compromesa.

Un cop actiu, aquest troià d'accés remot podria enumerar el sistema, recopilar secrets i executar ordres arbitràries. Penseu... claus API al núvol, tokens de desplegament de CI, tokens d'autenticació npm, claus SSH, tokens d'accés al repositori i altres variables d'entorn sensibles s'injecta habitualment en agents de compilació o ordinadors portàtils de desenvolupadors.

A partir d'aquí, els atacants podrien pivotar: comprovar el codi font, manipular futures versions, afegir més portes del darrere o passar lateralment a la infraestructura de producció. Per als desenvolupadors que treballen en projectes relacionats amb les criptomonedes (moneders, borses, frontends DeFi), aquest tipus d'accés podria traduir-se directament en robatori de criptomonedes o frau financer més ampli.

Tàctiques furtives: per què el compromís va ser difícil de detectar

Els autors del programari maliciós van fer tot el possible per mantenir la seva petjada tan petita i efímera com fos possible. Segons els investigadors, el comptador va netejar les seves pistes immediatament després de l'execució.

Això vol dir que si examinessis node_modules/plain-crypto-js/package.json després infecció, veuríeu un manifest completament inofensiu: cap script de postinstal·lació, cap setup.js, sense indicadors evidents de joc brut. Eines estàndard com ara npm audit o una comprovació manual superficial del directori no revelaria què ja havia passat.

A la pràctica, aquest comportament va fer que els investigadors depenguessin de factors externs indicadors de compromís (COI), telemetria de xarxa i artefactes de l'amfitrió en lloc de simples escanejos estàtics del contingut del paquet npm. Quan l'atac es va fer públic, les versions malicioses ja s'havien extret de npm, cosa que complicava encara més la reconstrucció del flux d'execució exacte.

Indicadors clau de compromís per a l'incident d'Axios

Tot i que el programari maliciós va intentar encobrir les seves petjades, els equips de seguretat han compartit IOC concrets que poden ajudar a determinar si un entorn s'ha vist afectat. Entre els més importants hi ha els següents:

Per costat de la xarxa, busca comunicació amb:

• Domini: sfrclakcom
• Adreça IP: 142.11.206.73

Ambdós indicadors han estat bloquejats pels principals proveïdors de seguretat, però continuen sent marcadors útils en registres històrics i cerques SIEM.

Per sistema de fitxers, els investigadors van destacar artefactes associats amb la RAT:

• macOS: /Library/Caches/com.apple.act.mond
• Linux: /tmp/ld.py
• Windows: fitxers sota %PROGRAMDATA%\wt i scripts temporals com ara %TEMP%\6202033.vbs or .ps1 que poden existir només breument durant l'execució

Pel que fa als paquets npm, el compilacions compromeses i les seves sumes de verificació conegudes són:

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

Empreses de seguretat com Huntress van observar com a mínim 135 sistemes que contacten amb el servidor de comandament i control de l'atacant durant la finestra d'exposició relativament curta, i investigadors de Google van advertir que, com a resultat, "centenars de milers" de secrets podrien haver estat desviats.

Qui hi havia darrere de l'atac? Atribució i enllaç amb Corea del Nord

El Grup d'Intel·ligència d'Amenaces de Google ha vinculat públicament el compromís d'Axios a un presumpte actor d'amenaces nord-coreà rastrejat com a UNC1069. John Hultquist, analista en cap de la unitat d'amenaces de Google, va assenyalar que els operadors nord-coreans tenen un llarg historial de atacs a la cadena de subministrament destinats a robar criptomonedes i altres actius.

Segons Google i altres proveïdors de seguretat, l'incident d'Axios sembla formar part d'una campanya més àmplia de grups nord-coreans, incloent-hi organitzacions com Lazarus, que se centren en extorsió, robatori financer i exfiltració de dades dirigint-se a sectors com les criptomonedes, les tecnologies financeres i les infraestructures al núvol.

Tot i que l'impacte total encara no està clar, la combinació d'un paquet molt popular, l'accés a entorns de desenvolupador i la naturalesa de les dades robades fa que els analistes esperin atacs de continuació en forma de més compromisos a la cadena de subministrament, ransomware i robatori directe de criptomonedes.

Com es va abusar del compte del mantenidor i del flux de treball de npm

Un dels aspectes més inquietants per a la comunitat de codi obert és com els atacants van aconseguir publicar versions malicioses d'Axios sense tocar la base de codi pública. La clau era un compte de mantenidor compromès a npm, es creu que pertany a un mantenidor principal d'Axios conegut com a jasonsaayman.

Segons sembla, els atacants van canviar l'adreça de correu electrònic associada a aquest compte npm a una adreça sota el seu control. Amb aquest pas, podrien bloquejar el mantenidor legítim i publicar noves versions de paquets com si fossin actualitzacions genuïnes, tot mentre el repositori oficial de GitHub es mantenia net.

L'operació també va posar de manifest un problema estructural de la NPM: el suport a testimonis d'autenticació antics, i la necessitat de eines de gestió de la cadena de subministrament i polítiques de tokens més estrictes.

En aquest cas, els investigadors de seguretat van assenyalar que npm encara per defecte al token antic per a la publicació, i cap control revocava automàticament aquest testimoni un cop es configuraven mètodes de publicació més moderns. Aquesta coexistència creava una porta lateral vulnerable que UNC1069 podia explotar.

Finestra d'exposició i detecció precoç

El compromís d'Axios no va ser una tasca llarga i lenta. Les investigacions suggereixen que les versions malicioses eren disponible a npm durant aproximadament tres hores entre la nit de diumenge i la matinada de dilluns o dimarts, depenent de la zona horària.

StepSecurity i altres empreses van assenyalar que l'atacant havia sembrat l'ecosistema amb un versió neta de la dependència maliciosa unes 18 hores abans adjuntant la variant armada a Axios. Sembla que aquest moviment ha estat dissenyat per crear un historial benigne per al paquet i evitar que s'activin els detectors automatitzats d'anomalies quan la dependència apareixia de sobte.

Un cop que les versions infectades d'Axios es van publicar, el troià va realitzar un reconeixement exhaustiu a cada sistema on s'executava: escanejar directoris, llistar processos en execució, enumerar discs i després enviar aquesta informació de tornada al servidor de l'atacant. Tot això va passar entre bastidors durant el que, per als desenvolupadors, semblava una instal·lació de dependències rutinària.

Gràcies a la resposta coordinada del responsable del manteniment, npm i diversos proveïdors de seguretat, les versions malicioses es van eliminar en qüestió d'hores. Tot i això, tal com van subratllar diversos investigadors i el propi equip de Google, una finestra d'exposició curta no és el mateix que un risc baix quan l'objectiu és una biblioteca amb desenes de milions de descàrregues setmanals.

Impacte en desenvolupadors, projectes criptogràfics i usuaris finals

Des d'un punt de vista pràctic, les víctimes més directes de l'incident d'Axios són desenvolupadors i entorns de construcció que va instal·lar les versions malicioses. Qualsevol persona que hagi executat una instal·lació o compilació que hagi instal·lat axios@1.14.1, axios@0.30.4 o plain-crypto-js@4.2.1 amb els scripts habilitats ha de suposar que el sistema podria estar completament compromès.

Per a projectes en l'espai de les criptomonedes (moneders, intercanvis centralitzats i descentralitzats, quadres de comandament DeFi, bots de trading i frontends Web3), hi ha un risc particularment alt. Molts d'aquests sistemes dependre d'Axios per comunicar-se amb passarelles de blockchain, API i serveis de backendi sovint gestionen secrets sensibles com ara claus privades, credencials d'API i dades d'usuari.

Si una estació de treball de desenvolupador o un agent de CI en un projecte d'aquest tipus hagués estat infectat, els atacants podrien haver obtingut no només els secrets emmagatzemats localment, sinó també accés a repositoris i pipelines de desplegamentAmb això, podrien injectar codi maliciós en versions futures, comprometre els usuaris finals indirectament o redirigir fons.

En canvi, els usuaris que simplement executen aplicacions acabades al navegador estan en una millor posició: el RAT es va lliurar durant passos d'instal·lació i construcció, no durant l'execució al navegador. Per tant, visitar un lloc que utilitza Axios per a crides del costat del client no desencadena, per si sol, l'atac. El risc es concentra en aquells que van instal·lar els paquets npm afectats.

Mesures immediates que haurien de prendre els desenvolupadors

Els equips de seguretat i els responsables del manteniment han estat clars: si hi ha alguna possibilitat que els vostres sistemes hagin recuperat les versions compromeses d'Axios o plain-crypto-js, tracteu aquests hosts com a totalment desconfiable fins que s'investiguiAixò significa més que simplement augmentar el número de versió.

Les accions concretes recomanades pels investigadors i proveïdors inclouen:

• Audita les teves dependències i fitxers de bloqueig: Cercar axios@1.14.1, axios@0.30.4 i plain-crypto-js@4.2.1 in package-lock.json, pnpm-lock.yaml, yarn.lock i registres de CI; vegeu com arreglar-los de manera segura.
• Actualitza a versions segures verificades: Passa a versions netes d'Axios (per exemple, les etiquetes immediatament posteriors amb pegats recomanades pels mantenidors) i assegura't que els fitxers de bloqueig es regenerin.
• Rota les credencials de manera agressiva: Assumeix que qualsevol secret present a les màquines o canalitzacions afectades (claus d'API al núvol, tokens npm, claus SSH, claus de desplegament, variables .env) pot haver estat robat i rota'ls.
• Reconstruir sistemes compromesos: Sempre que sigui possible, torneu a implementar els agents de compilació, els executors de CI i les estacions de treball de desenvolupador des d'imatges de confiança en lloc d'intentar netejar-les al seu lloc.
• Infraestructura del bloc C2: Afegeix sfrclak.com i 142.11.206.73 a tallafocs, llistes de bloqueig DNS i regles EDR.
• Caça d'artefactes: Comproveu les rutes del sistema de fitxers i els fitxers temporals associats amb el RAT als amfitrions macOS, Windows i Linux.

Diverses empreses de seguretat han assessorat les organitzacions que van instal·lar les versions contaminades a presumir un compromís per defecteEn altres paraules, procediu sota la suposició que els atacants hi tenien accés i treballeu sistemàticament a través dels passos de resposta a incidents en lloc d'esperar que el programari maliciós no fes res.

Lliçons més àmplies per a la seguretat de la cadena de subministrament de programari

Més enllà del triatge immediat, l'incident d'Axios ha reavivat els debats sobre com l'ecosistema en general gestiona la confiança, la identitat i la distribució en codi obert. Il·lustra com un compte únic de mantenidor de la biblioteca pot convertir-se en un element clau per a la postura de seguretat d'innombrables organitzacions.

Diversos temes han sorgit de les anàlisis post mortem i de proveïdors:

• Els tokens antics són un passiu: Els tokens npm antics poden persistir silenciosament juntament amb els fluxos de treball més nous basats en OIDC. Els projectes necessiten polítiques explícites per revocar-los un cop s'hagin implementat mètodes més segurs.
• Les actualitzacions automatitzades funcionen en ambdós sentits: Els augments automàtics de dependències acceleren el desenvolupament, però també signifiquen que una versió maliciosa es pot propagar pels ecosistemes abans que ningú se n'adoni.
• L'escaneig de dependències és necessari però no suficient: Comprovacions estàtiques i npm audit són útils, però lluiten contra comportament efímer com ara els scripts de postinstal·lació que s'autoeliminen.
• La seguretat del mantenidor és una infraestructura crítica: Un MFA fort, les claus de seguretat del maquinari, la gestió acurada dels tokens d'accés i la revisió regular de qui pot publicar són ara tan importants com escriure un bon codi.

Per als fundadors, els CTO i els líders d'enginyeria, el compromís d'Axios és un recordatori que el risc de la cadena de subministrament és una qüestió estratègica, no només un aspecte tècnic. Afecta la rapidesa amb què podeu enviar, com dissenyeu els vostres pipelines de CI/CD i com equilibreu la comoditat del codi obert amb la necessitat de verificar el que executeu en producció.

En conjunt, el compromís d'Axios sobre npm mostra com un atac de curta durada però ben planificat pot convertir un element bàsic de confiança de l'ecosistema JavaScript en un conducte furtiu per a programari maliciós d'accés remot. Amb els atacants dirigits tant als mantenidors i canals de distribució com als usuaris finals, mantenir les cadenes de subministrament de programari sanes ara depèn de controls més estrictes sobre els fluxos de treball de publicació, una supervisió agressiva de les anomalies i una voluntat de tractar les dependències amb el mateix escepticisme que abans es reservava només per al trànsit de xarxa extern.

Article relacionat:

Guia detallada sobre auditories de seguretat NPM i atacs a la cadena de subministrament