- Ce s-a întâmplat în cazul atacului asupra Axios npm
- Cum o singură linie din fișierul package.json a devenit vectorul de atac
- De ce revizuirea tradițională a codului nu a depistat atacul asupra Axios
- De ce raza de acțiune a exploziei acoperă tot ceea ce se află în raza de acțiune a pachetului
- Ce măsuri de securitate ar fi putut schimba rezultatul
- Aflați mai multe despreSupply Chain Software
- Întrebări frecvente
Deturnarea pachetelor NPM este un atac asupra lanțului de aprovizionare software care transformă încrederea acordată unui pachet într-o cale de atac. Atacatorii nu au nevoie să modifice codul din depozit dacă pot controla contul care publică pachetul.
Tocmai acest lucru face ca pachetele npm de încredere să constituie o suprafață de atac atât de vulnerabilă. Atunci când contul unui administrator este compromis, fiecare proiect care instalează pachetul afectat poate fi expus la riscuri printr-o simplă actualizare de rutină a dependențelor. Incidentul Axios din martie 2026 a demonstrat cum un singur cont npm compromis a putut pune în pericol peste 100 de milioane de descărcări săptămânale, fără ca codul sursă al Axios să sufere modificări vizibile.
Înțelegerea modului în care funcționează deturnarea pachetelor npm ajută echipele de securitate să implementeze măsuri de control care vizează calea reală a atacului, nu doar fișierele sursă pe care majoritatea echipelor le verifică.
Ce s-a întâmplat în cazul atacului asupra Axios npm
Atacul asupra pachetului Axios de pe npm a constat în preluarea controlului asupra contului unui administrator, transformând un pachet de încredere într-un mecanism de distribuire a programelor malware. Atacatorul a compromis contul npm al administratorului principal al pachetului Axios, a schimbat adresa de e-mail înregistrată cu una controlată de el și l-a blocat pe administratorul legitim.
Operațiunea a fost planificată și deliberată. Cu aproximativ 18 ore înainte de activarea codului dăunător, a fost publicat un pachet momeală, care a generat un istoric de publicare fără a trezi suspiciuni imediate. Apoi, în aproximativ 39 de minute, atacatorul a distribuit două versiuni dăunătoare: axios 1.14.1 pentru ramura de versiuni moderne și axios 0.30.4 pentru ramura de versiuni vechi.
Ambele linii de lansare au fost vizate simultan pentru a maximiza vizibilitatea. Această decizie a sporit probabilitatea ca atât mediile actuale, cât și cele vechi să descarce un pachet compromis prin intermediul procedurii standard de actualizare.
Cum o singură linie din fișierul package.json a devenit vectorul de atac
O singură modificare a unei dependențe în fișierul package.json poate constitui întreaga cale de atac într-un atac asupra lanțului de aprovizionare npm. În cazul incidentului Axios, nu a fost necesară modificarea niciunui fișier sursă Axios, deoarece comportamentul rău intenționat a fost introdus printr-o nouă dependență.
Această dependență se executa prin intermediul unui hook npm de tip „postinstall”. De îndată ce o stație de lucru a unui dezvoltator, un pipeline CI/CD sau un sistem de compilare executa comanda „npm install”, pachetul rău intenționat putea contacta un server controlat de atacator, putea prelua o sarcină utilă specifică sistemului de operare și putea începe execuția.
Pachetele malware au fost create pentru macOS, Windows și Linux. Atacul a fost conceput pentru a funcționa pe mai multe platforme. După executare, programul de instalare și-a șters urmele și a înlocuit fișierul package.json original cu o versiune falsificată, îngreunând considerabil analiza criminalistică ulterioară.
De ce revizuirea tradițională a codului nu a depistat atacul asupra Axios
Revizuirea tradițională a codului este concepută pentru a verifica modificările aduse codului sursă din cadrul unui depozit, însă această vulnerabilitate nu se afla în codul sursă al Axios. Atacul asupra Axios nu s-a bazat pe modificări vizibile în depozit, deoarece logica rău intenționată se afla într-o dependență separată, și nu în codul sursă al Axios.
Această diferență contează. Un evaluator care ar analiza actualizarea pachetului ar observa doar o nouă linie de dependență în fișierul package.json. Comportamentul rău intenționat propriu-zis a apărut abia după ce dependența a fost rezolvată și instalată.
De aceea, atacurile prin intermediul pachetelor de încredere sunt greu de depistat doar prin verificarea diferențelor. Calea de atac se află în afara fișierelor sursă pe care majoritatea echipelor le verifică, chiar dacă pachetul pare suficient de legitim pentru a trece prin fluxurile de lucru obișnuite de dezvoltare.
De ce raza de acțiune a exploziei acoperă tot ceea ce se află în raza de acțiune a pachetului
Raza de acțiune a unui pachet npm compromis nu este pachetul în sine. Raza de acțiune cuprinde tot ceea ce intră în contact cu pachetul respectiv.
Pentru majoritatea organizațiilor, aceasta include fluxuri CI/CD cu permisiuni ridicate, puncte de acces pentru dezvoltatori cu chei SSH și tokenuri cloud, servere de compilare cu acces de scriere la depozitele de artefacte, precum și instrumente de implementare conectate la sistemele de producție. Un pachet rău intenționat nu trebuie neapărat să rămână în arborele de dependențe pentru a provoca daune. Este suficient un singur punct de execuție de încredere.
De aceea, incidentul Axios are o importanță care depășește sfera gestionării pachetelor JavaScript. O compromitere care are loc după instalare poate transforma o instalare obișnuită într-un furt de date de autentificare, o mișcare laterală sau un acces la infrastructura din aval.
Punctele slabe structurale scoase la iveală de atacul asupra Axios
Incidentul Axios a scos la iveală deficiențe structurale care sunt comune în mediile moderne de dezvoltare software. Nu este vorba de cazuri izolate. Acestea reprezintă ipoteze obișnuite în multe organizații.
Încrederea în identitatea administratorilor de pachete
Încrederea în pachetele npm este adesea legată de contul administratorului care publică pachetul. Dacă acel cont este furat sau victima unui atac de phishing, atacatorul preia aceeași autoritate de publicare ca și administratorul legitim.
Versiuni flotante ale dependențelor
Versiunile cu actualizare automată sau cu instalare flexibilă sporesc riscul de expunere la versiuni compromise. O versiune compromisă recent publicată poate pătrunde automat într-un mediu, fără a fi necesară o etapă de aprobare deliberată.
Scripturi post-instalare nesupravegheate
Scripturile npm postinstall pot executa cod arbitrar cu permisiunile procesului de instalare. Multe organizații nu verifică și nu restricționează scripturile din ciclul de viață înainte ca acestea să fie rulate.
Fluxuri CI/CD cu vizibilitate limitată asupra execuției
Fluxurile CI/CD au adesea acces extins la sistemele interne, la infrastructura de compilare și la mediile cloud. Aceste fluxuri sunt adesea considerate de încredere în mod implicit și sunt rareori monitorizate pentru a detecta comportamente rău intenționate ale pachetelor în momentul instalării.
Puncte de acces ale dezvoltatorilor care nu sunt acoperite integral de măsurile de securitate
Dispozitivele utilizate de dezvoltatori stochează resurse de mare valoare, inclusiv chei SSH, date de autentificare pentru serviciile cloud și tokenuri de întreprindere. Dispozitivele utilizate de dezvoltatori sunt, de asemenea, ținte frecvente ale atacurilor, deoarece pot beneficia de o vizibilitate redusă și de mai puține controale la nivel de execuție decât sistemele de producție.
Magazine de acreditări fără declanșatoare de rotație rapidă
Un atac asupra lanțului de aprovizionare cu software se transformă adesea într-un incident de expunere a datelor de autentificare. Multe echipe nu dispun încă de procese fiabile care să identifice datele confidențiale potențial expuse și să le schimbe imediat.
Ce măsuri de securitate ar fi putut schimba rezultatul
Trei categorii de măsuri de securitate ar fi redus semnificativ impactul atacului asupra Axios. Fiecare măsură vizează un punct diferit din lanțul de atac: executarea pachetelor, expunerea datelor de autentificare și vizibilitatea dependențelor.
1. Scanarea malware-ului la nivel de pachet înainte de instalare
Scanarea malware-ului la nivel de pachet ajută la blocarea dependențelor dăunătoare înainte ca acestea să fie executate. Acest lucru este important în cazul atacurilor npm, deoarece hook-urile post-instalare se execută în timpul instalării, ceea ce lasă foarte puțin timp pentru o verificare manuală odată ce pachetul a fost descărcat.
Scanarea pachetelor, a dependențelor și a scripturilor de ciclu de viață înainte de instalare permite identificarea programelor malware cunoscute, a comportamentelor suspecte, a vulnerabilităților și a datelor confidențiale încorporate în cod, înainte ca pachetul să ajungă la un terminal al dezvoltatorului sau într-un mediu CI/CD.
MetaDefender Software Supply Chain este soluția OPSWATde securitate a lanțului de aprovizionare software pentru validarea componentelor software, a furnizorilor și a canalelor de compilare. Aceasta utilizează detectarea amenințărilor cu motoare multiple, inclusiv scanarea multiplă Metascan pe peste 30 de motoare antivirus, pentru a inspecta pachetele în căutarea de malware, vulnerabilități și secrete hardcodate înainte ca acestea să intre în ciclul de viață al dezvoltării.
2. Gestionarea proactivă a secretelor cu ajutorul declanșatoarelor de rotație
Gestionarea proactivă a secretelor reduce impactul unui atac reușit. Atunci când se identifică un pachet suspect, echipele au nevoie de o strategie de răspuns care să trateze datele de autentificare locale, cheile SSH, token-urile și secretele din pipeline ca fiind potențial expuse și să le înlocuiască rapid.
Detectarea secretelor hardcodate servește aceluiași scop. Un pachet rău intenționat poate fura secrete din memorie sau de pe disc, dar secretele expuse care sunt deja prezente în cod sau în dependențe reprezintă un alt nivel de risc care poate fi prevenit.
3. Supply Chain și monitorizarea dependențelor
Vizibilitatea lanțului de aprovizionare ajută echipele să identifice modificările neașteptate ale pachetelor înainte ca acestea să genereze incidente în etapele ulterioare. Echipele de securitate trebuie să știe ce pachete sunt instalate, ce versiuni sunt fixate, ce noi dependențe au apărut și unde rulează aceste componente.
În lipsa vizibilității și monitorizării dependențelor, primul semn al unei compromiteri poate fi utilizarea abuzivă a datelor de autentificare sau a infrastructurii, la mult timp după ce evenimentul inițial de instalare a avut loc.
Aflați mai multe despreSupply Chain Software
Securitatea lanțului Software depinde de verificarea pachetelor înainte de execuție, de monitorizarea noilor dependențe și de reducerea expunerii datelor de autentificare în urma compromiterii unui pachet.
Urmăriți seminarul web la cerere:Supply Chain Software — Punctele slabe exploatate de atacatori
Întrebări frecvente
Ce este un atac asupra lanțului de aprovizionare npm?
Un atac asupra lanțului de aprovizionare npm constă în introducerea de cod rău intenționat prin intermediul ecosistemului npm în cadrul activităților obișnuite de dezvoltare software. De obicei, atacatorii reușesc acest lucru prin compromiterea contului unui administrator, publicarea unui pachet înșelător sau introducerea de comportamente dăunătoare în dependențele pe care dezvoltatorii și sistemele CI/CD le instalează automat.
Cum au reușit atacatorii să compromită pachetul npm Axios?
Atacatorii au compromis contul npm al administratorului principal al Axios și au folosit drepturile de publicare pentru a lansa versiuni rău intenționate atât în ramura de versiuni 1.x, cât și în cea 0.x. De asemenea, atacatorii au schimbat adresa de e-mail a contului cu una controlată de ei, ceea ce le-a permis să păstreze controlul asupra pachetului.
Ce a făcut programul malware folosit în atacul asupra Axios?
Malware-ul folosit în atacul asupra Axios a utilizat un hook post-instalare care se executa în timpul comenzii „npm install”. Hook-ul a stabilit legătura cu un server controlat de atacator, a descărcat un troian de acces la distanță pentru macOS, Windows sau Linux, l-a lansat și apoi a încercat să șteargă urmele înlocuind metadatele pachetului cu conținut falsificat.
De ce revizuirea codului nu a depistat atacul asupra lanțului de aprovizionare al Axios?
Revizuirea codului nu a detectat atacul Axios deoarece logica rău intenționată nu a fost introdusă în codul sursă al Axios. Singura modificare vizibilă la nivel de depozit a fost o intrare de dependență în fișierul package.json, în timp ce malware-ul propriu-zis a fost introdus printr-un pachet extern, care nu intra în sfera obișnuită a revizuirii codului sursă.
Cum pot organizațiile să detecteze pachetele npm rău intenționate înainte de instalare?
Organizațiile pot detecta pachetele npm rău intenționate înainte de instalare, prin scanarea conținutului pachetelor, a arborilor de dependențe și a scripturilor de ciclu de viață înainte de execuție. Măsurile de control eficiente combină scanarea împotriva programelor malware, analiza dependențelor, aplicarea politicilor și integrarea cu procesele CI/CD, astfel încât pachetele suspecte să poată fi blocate înainte de a ajunge în mediile de dezvoltare sau de compilare.
Fixarea versiunilor previne atacurile asupra lanțului de aprovizionare npm?
Fixarea versiunilor reduce expunerea la versiunile rău intenționate recent publicate, deoarece limitează actualizările automate. Fixarea versiunilor nu elimină riscul asociat lanțului de aprovizionare, deoarece o versiune fixată poate fi deja compromisă sau pot exista în continuare alte vulnerabilități legate de încredere. Fixarea versiunilor funcționează cel mai bine atunci când este combinată cu verificarea integrității, inspectarea pachetelor și controalele la rulare.
