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

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

Timp de câteva ore tensionate, una dintre cele mai utilizate biblioteci JavaScript de pe planetă, Axios, a devenit un vehicul de distribuție neașteptat pentru programe malware. Un atac direcționat atac asupra lanțului de aprovizionare asupra ecosistemului NPM a transformat o actualizare de rutină a dependenței într-o potențială ușă de acces pentru atacatori pe sute de mii de mașini de dezvoltator și sisteme de compilare.

Anchetatorii de la mai multe firme de securitate și de la Grupul de Informații despre Amenințări al Google au descoperit cum un actor rău intenționat a strecurat... troian de acces la distanță (RAT) în versiuni specifice de Axios pe npm, similar cu viermele lanțului de aprovizionare npm.

Ce este Axios și de ce contează atât de mult compromisul

În esență, Axios este un client HTTP bazat pe promisiuni pentru Node.js și browsereSe află în culise în nenumărate proiecte, gestionând sarcini zilnice precum „preluarea mesajelor mele de pe server” sau „trimiterea acestui formular către API”, fără ca dezvoltatorii să fie nevoiți să scrie manual cod de rețea de nivel scăzut.

Deoarece rulează atât în ​​browser, cât și pe serverele Node.js, Axios a devenit o dependență fundamentală în stivele JavaScript modernePoate că nu l-ai instalat niciodată explicit, dar totuși te bazezi pe el indirect atunci când:

• Folosește aplicații web construite cu framework-uri precum React, Vue sau Angular care își încadrează apelurile API cu Axios.
• Rulați aplicații desktop sau mobile construite pe tehnologii precum Electron, React Native și runtime-uri web similare.
• Interacționați cu instrumente SaaS mai mici, tablouri de bord de administrare sau servicii auto-găzduite ai căror dezvoltatori au ales Axios pentru cereri HTTP.

În acest sens, Axios este cam ca instalații sanitare în casa taRareori te gândești la asta, dar transportă „apa” de date între aplicația ta și lumea exterioară. O observi cu adevărat doar atunci când există o scurgere de date – exact ceea ce a creat acest atac, dar la scara ecosistemului software.

Cum s-a desfășurat atacul Axios npm

Incidentul se concentrează pe două versiuni npm: axios@1.14.1 și axios@0.30.4Folosind acreditările compromise ale unuia dintre principalii administratori ai proiectului, atacatorii au reușit să publice construcții rău intenționate direct către npm lăsând codul sursă public GitHub neatins, un model descris și în Analiza Shai-Hulud.

În loc să modifice vizibil codul Axios, atacatorul a adăugat o nouă dependență, aparent fără legătură: plain-crypto-js@4.2.1Acest pachet a fost conceput special pentru operațiune și nu a fost importat nicăieri în fișierele sursă Axios, un semnal de alarmă pentru oricine examinează diferența - dar ușor de trecut cu vederea în fluxurile de lucru automatizate care au încredere pur și simplu în registru.

Împreună, cele două versiuni axios alterate aveau o amprentă potențială enormă, ajungând până la aproximativ 100 de milioane de descărcări săptămânale pe npmSe estimează că Axios este prezent în aproape 80% din mediile cloud și din conductele CI/CD, așa că chiar și o scurtă perioadă de expunere a reprezentat un risc sistemic serios.

Important este că versiunile afectate nu au apărut niciodată în etichete oficiale GitHub pentru proiectul Axios. Acest detaliu sugerează cu tărie că procesele normale de lansare au fost ocolite: atacatorul a folosit un token npm furat pentru a trimite pachete direct în registru, în afara benzii din istoricul surselor publice.

Mecanica dependenței malițioase și a RAT-ului

Esența compromisului constă în ceea ce s-a întâmplat în momentul instalării. Orice flux de lucru care a rulat npm install și a tras înăuntru axios@1.14.1, axios@0.30.4 or plain-crypto-js@4.2.1 cu scripturile activate a declanșat o rutină ascunsă de postinstalare.

În interiorul dependenței rău intenționate, o script postinstalare (nodul setup.js) executat automat. Scriptul respectiv a descărcat un dropper ofuscat, care apoi a preluat o utilă RAT specifică platformei, adaptată pentru macOS, Windows sau LinuxRAT-ul i-a acordat atacatorului acces interactiv de la distanță la mașina compromisă.

Odată activ, acest troian de acces la distanță ar putea enumera sistemul, colecta secrete și executa comenzi arbitrare. Gândiți-vă chei API cloud, token-uri de implementare CI, token-uri de autentificare npm, chei SSH, token-uri de acces la depozit și alte variabile de mediu sensibile injectate frecvent în agenți de compilare sau laptopuri pentru dezvoltatori.

De acolo, atacatorii ar putea să se adapteze: să verifice codul sursă, să modifice versiunile viitoare, să adauge mai multe backdoor-uri sau să se mute lateral în infrastructura de producție. Pentru dezvoltatorii care lucrează la proiecte legate de criptomonede - portofele, exchange-uri, frontend-uri DeFi - acest tip de acces s-ar putea traduce direct în... furtul de criptomonede sau frauda financiară mai largă.

Tactici ascunse: de ce compromisul a fost greu de observat

Autorii malware-ului au depus eforturi considerabile pentru a-și menține amprenta cât mai mică și efemeră posibil. Potrivit cercetătorilor, dropper-ul și-a curățat urmele imediat după execuție.

Asta înseamnă că dacă ai examinat node_modules/plain-crypto-js/package.json după infecție, ați vedea un manifest complet inofensiv: fără script postinstalare, fără setup.js, fără indicii evidente de acte incorecte. Unelte standard precum npm audit sau o verificare manuală superficială a directorului nu ar dezvălui ce se întâmplase deja.

În practică, acest comportament i-a făcut pe investigatori să se bazeze pe informații externe indicatori de compromis (COI), telemetria rețelei și artefactele gazdei, în loc de simple scanări statice ale conținutului pachetului npm. Până în momentul în care atacul a devenit public, versiunile rău intenționate fuseseră deja extrase din npm, ceea ce a complicat și mai mult reconstrucția fluxului exact de execuție.

Indicatori cheie ai compromiterii incidentului Axios

Chiar dacă malware-ul a încercat să-și ascundă urmele, echipele de securitate au distribuit IOC-uri concrete care pot ajuta la determinarea dacă un mediu a fost afectat. Printre cele mai importante se numără următoarele:

Pe partea de rețea, căutați comunicarea cu:

• Domeniu: sfrclakcom
• Adresa IP: 142.11.206.73

Ambii indicatori au fost blocați de furnizorii principali de securitate, dar rămân markeri utili în jurnalele istorice și căutările SIEM.

Pe Sistemul de fișiere, anchetatorii au evidențiat artefacte asociate cu RAT:

• MacOS: /Library/Caches/com.apple.act.mond
• Linux: /tmp/ld.py
• Windows: fișiere sub %PROGRAMDATA%\wt și scripturi temporare, cum ar fi %TEMP%\6202033.vbs or .ps1 care pot exista doar pentru scurt timp în timpul execuției

În ceea ce privește pachetele npm, versiuni compromise și sumele de control cunoscute ale acestora sunt:

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

Firme de securitate precum Huntress au observat cel puțin 135 de sisteme contactează serverul de comandă și control al atacatorului în timpul ferestrei de expunere relativ scurte, iar cercetătorii de la Google au avertizat că „sute de mii” de secrete ar fi putut fi în cele din urmă sifonate ca urmare.

Cine a fost în spatele atacului? Atribuire și legătura cu Coreea de Nord

Grupul de informații despre amenințări al Google a făcut public legătura între compromisul Axios și... presupus actor de amenințare nord-coreean urmărit ca UNC1069. John Hultquist, analist șef la unitatea de amenințări a Google, a remarcat că operatorii nord-coreeni au un istoric îndelungat de atacuri în lanțul de aprovizionare care vizează furtul criptomonedelor și alte active.

Potrivit Google și alți furnizori de servicii de securitate, incidentul Axios pare să facă parte dintr-o campanie mai amplă a unor grupuri nord-coreene, inclusiv organizații precum Lazarus, care se concentrează pe... extorcare, furt financiar și exfiltrare de date vizând sectoare precum criptomonede, fintech și infrastructura cloud.

Deși impactul complet este încă neclar, combinația dintre un pachet extrem de popular, accesul la mediile dezvoltatorilor și natura datelor furate îi face pe analiști să se aștepte... atacuri ulterioare sub forma unor compromisuri suplimentare ale lanțului de aprovizionare, a unor programe de tip ransomware și a unui furt direct de criptomonede.

Cum au fost abuzate contul de întreținător și fluxul de lucru npm

Unul dintre cele mai tulburătoare aspecte pentru comunitatea open-source este modul în care atacatorii au reușit să publice versiuni Axios malițioase fără a atinge baza de cod publică. Cheia a fost... cont de întreținător compromis pe npm, despre care se crede că aparține unui administrator principal Axios, cunoscut sub numele de jasonsaayman.

Se pare că atacatorii au schimbat adresa de e-mail asociată contului npm respectiv cu o adresă aflată sub controlul lor. Cu acest pas, ar putea... blochează întreținătorul legitim și să lanseze noile versiuni de pachete ca și cum ar fi actualizări autentice, toate acestea în timp ce depozitul oficial GitHub a rămas curat.

Operațiunea a scos la iveală și o problemă structurală în cadrul NPM: sprijinul pentru token-uri de autentificare vechi, și nevoia de instrumente de gestionare a lanțului de aprovizionare și politici mai stricte privind tokenurile.

În acest caz, cercetătorii în domeniul securității au subliniat că npm încă implicit la tokenul vechi pentru publicare și niciun control nu a revocat automat acel token odată ce au fost configurate metode de publicare mai moderne. Această coexistență a creat o ușă laterală vulnerabilă pe care UNC1069 a putut-o exploata.

Fereastra de expunere și detectarea timpurie

Compromisul Axios nu a fost o acțiune lentă și de lungă durată. Investigațiile sugerează că versiunile rău intenționate au fost... disponibil pe npm timp de aproximativ trei ore între duminică noaptea târziu și primele ore ale zilei de luni sau marți, în funcție de fusul orar.

StepSecurity și alte firme au remarcat că atacatorul a însămânțat ecosistemul cu un versiune curată a dependenței rău intenționate cu aproximativ 18 ore înainte atașarea variantei armate la Axios. Această mișcare pare să fi fost concepută pentru a construi un istoric benign pentru pachet și pentru a evita declanșarea detectorilor automati de anomalii atunci când dependența apărea brusc.

Odată ce versiunile Axios infectate au fost lansate, troianul a efectuat o recunoaștere extinsă a fiecărui sistem pe care a rulat: scanarea directoarelor, listarea proceselor care rulează, enumerarea discurilor și apoi trimiterea acestor informații înapoi către serverul atacatorului. Toate acestea s-au întâmplat în culise, în timpul a ceea ce, pentru dezvoltatori, părea o instalare de rutină a dependenței.

Datorită răspunsului coordonat din partea responsabilului, a npm și a mai multor furnizori de securitate, versiunile rău intenționate au fost eliminate în câteva ore. Totuși, așa cum au subliniat mai mulți cercetători și propria echipă Google, O fereastră scurtă de expunere nu este același lucru cu un risc scăzut când ținta este o bibliotecă cu zeci de milioane de descărcări săptămânale.

Impactul asupra dezvoltatorilor, proiectelor cripto și utilizatorilor finali

Din punct de vedere practic, victimele cele mai directe ale incidentului Axios sunt dezvoltatori și medii de construire care a instalat versiunile rău intenționate. Oricine a rulat o instalare sau o compilare care a preluat axios@1.14.1, axios@0.30.4 sau plain-crypto-js@4.2.1 cu scripturile activate trebuie să presupună că sistemul ar putea fi complet compromis.

Pentru proiectele din domeniul criptomonedelor - portofele, exchange-uri centralizate și descentralizate, tablouri de bord DeFi, boți de tranzacționare și frontend-uri Web3 - mizele sunt deosebit de mari. Multe dintre aceste sisteme se bazează pe Axios pentru comunicarea cu gateway-urile blockchain, API-urile și serviciile backendși gestionează adesea secrete sensibile, cum ar fi chei private, acreditări API și date despre utilizatori.

Dacă o stație de lucru de dezvoltator sau un agent CI dintr-un astfel de proiect ar fi fost infectat, atacatorii ar fi putut obține nu numai secretele stocate local, ci și acces la repozitorii și conducte de implementareAstfel, ar putea injecta cod rău intenționat în versiunile viitoare, compromite indirect utilizatorii finali sau redirecționa fonduri.

Prin contrast, utilizatorii care pur și simplu rulează aplicații finalizate în browserul lor sunt într-o poziție mai bună: RAT a fost livrat în timpul pași de instalare și construire, nu în timpul execuției în browser. Așadar, vizitarea unui site care utilizează Axios pentru apeluri pe partea de client nu declanșează, în sine, atacul. Riscul se concentrează asupra celor care au instalat pachetele npm afectate.

Pași imediati pe care dezvoltatorii ar trebui să îi ia

Echipele de securitate și cei care se ocupă de mentenanță au fost clari: dacă există vreo șansă ca sistemele dumneavoastră să fi introdus versiunile compromise de Axios sau plain-crypto-js, tratați acele gazde ca... complet neîncrezător până la investigareAsta înseamnă mai mult decât simpla modificare a numărului de versiune.

Acțiunile concrete recomandate de cercetători și furnizori includ:

• Verificați dependențele și fișierele de blocare: Caută 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 jurnalele CI; consultați cum să le repari în siguranță.
• Actualizați la versiuni sigure verificate: Treceți la versiuni Axios curate (de exemplu, etichetele imediat următoare, cu patch-uri recomandate de administratori) și asigurați-vă că fișierele de blocare sunt regenerate.
• Rotiți acreditările în mod agresiv: Presupuneți că orice secret prezent pe mașinile sau conductele afectate — chei API cloud, token-uri npm, chei SSH, chei de implementare, variabile .env — ar fi putut fi furat și rotiți-l.
• Reconstruiți sistemele compromise: Pe cât posibil, redistribuiți agenții de compilare, rulanții CI și stațiile de lucru pentru dezvoltatori din imagini de încredere, în loc să încercați să le curățați la locul lor.
• Infrastructura Blocului C2: Adăuga sfrclak.com și 142.11.206.73 la firewall-uri, liste de blocare DNS și reguli EDR.
• Vânătoare de artefacte: Verificați căile sistemului de fișiere și fișierele temporare asociate cu RAT pe gazdele macOS, Windows și Linux.

Mai multe companii de securitate au sfătuit organizațiile care au instalat versiunile contaminate să presupune compromisul implicitCu alte cuvinte, se pornește de la premisa că atacatorii au avut acces și se lucrează sistematic prin etapele de răspuns la incidente, în loc să se spere că malware-ul nu a făcut nimic.

Lecții mai ample pentru securitatea lanțului de aprovizionare cu software

Dincolo de triajul imediat, incidentul Axios a reaprins dezbaterile despre modul în care ecosistemul mai larg gestionează încrederea, identitatea și distribuția în open source. Acesta ilustrează cum o cont unic de administrator al bibliotecii poate deveni un element central pentru postura de securitate a nenumărate organizații.

Din analizele post-mortem și ale furnizorilor au rezultat mai multe teme:

• Jetoanele vechi reprezintă o datorie: Vechile token-uri npm pot persista discret alături de fluxurile de lucru mai noi bazate pe OIDC. Proiectele au nevoie de politici explicite pentru a le revoca odată ce sunt implementate metode mai sigure.
• Actualizările automate funcționează în ambele sensuri: Creșterile automate ale dependenței accelerează dezvoltarea, dar înseamnă și că o versiune rău intenționată se poate propaga prin ecosisteme înainte ca cineva să observe.
• Scanarea dependențelor este necesară, dar nu suficientă: Verificări statice și npm audit sunt utile, totuși se luptă împotriva comportament efemer cum ar fi scripturile postinstalare care se șterg automat.
• Securitatea mentenanței este o infrastructură critică: Un MFA puternic, cheile de securitate hardware, gestionarea atentă a token-urilor de acces și revizuirea regulată a persoanelor care pot publica sunt acum la fel de importante ca scrierea unui cod bun.

Pentru fondatori, directori tehnologici și lideri în inginerie, compromisul Axios este o reamintire că Riscul lanțului de aprovizionare este o problemă strategică, nu doar unul tehnic. Afectează cât de repede puteți livra, modul în care vă proiectați canalele de CI/CD și modul în care echilibrați confortul open source cu necesitatea de a verifica ceea ce rulați în producție.

Luate împreună, compromiterea Axios pe npm arată cum un atac de scurtă durată, dar bine planificat, poate transforma o componentă de încredere a ecosistemului JavaScript într-un canal ascuns pentru malware cu acces la distanță. Având în vedere că atacatorii vizează atât administratorii și canalele de distribuție, cât și utilizatorii finali, menținerea sănătății lanțurilor de aprovizionare cu software depinde acum de controale mai stricte asupra fluxurilor de lucru de publicare, monitorizarea agresivă a anomaliilor și disponibilitatea de a trata dependențele cu același scepticism rezervat odinioară doar traficului de rețea extern.

Articol asociat:

Ghid detaliat pentru auditarea securității NPM și atacurile asupra lanțului de aprovizionare