L’attacco alla supply chain che ha coinvolto Axios riaccende i riflettori su una delle vulnerabilità più critiche dell’ecosistema open source. Il celebre client HTTP, utilizzato in milioni di progetti JavaScript, è stato compromesso attraverso la pubblicazione su npm di versioni alterate contenenti codice malevolo. Un episodio che evidenzia come anche strumenti consolidati possano diventare vettori di minacce sofisticate.
La dinamica dell’attacco supply chain Axios
Gli aggressori sono riusciti a pubblicare le versioni 1.14.1 e 0.30.4 di Axios sfruttando le credenziali compromesse del maintainer principale. Queste release introducevano una dipendenza fasulla, “plain-crypto-js” versione 4.2.1, progettata esclusivamente per eseguire uno script malevolo in fase di installazione.
Il meccanismo era tanto semplice quanto efficace: durante il processo di installazione npm, lo script “postinstall” attivava un dropper RAT multipiattaforma, capace di colpire sistemi Windows, macOS e Linux. Il malware stabiliva una connessione con un server di comando e controllo per scaricare payload specifici per ciascun sistema operativo, per poi cancellare le proprie tracce e sostituire i file compromessi con versioni apparentemente pulite.
Un dettaglio rilevante è che nessun file del codice sorgente di Axios è stato modificato direttamente, rendendo l’attacco particolarmente difficile da individuare tramite i tradizionali controlli di versione.
Primi segnali e impatto sulle dipendenze
A individuare l’anomalia è stata StepSecurity, che ha rilevato la presenza della dipendenza sospetta nelle nuove release. L’inclusione di “plain-crypto-js” non aveva alcuna giustificazione funzionale, trattandosi di un pacchetto mai utilizzato all’interno del codice Axios.
Secondo le analisi, l’operazione è stata pianificata con estrema precisione: la dipendenza malevola è stata pubblicata ore prima dell’attacco, con payload già pronti per tre diversi sistemi operativi. Le due versioni compromesse di Axios sono state poi rilasciate a distanza di pochi minuti, massimizzando l’impatto.
Considerando che Axios registra oltre 83 milioni di download settimanali, il rischio per la supply chain è stato immediato e diffuso. Gli sviluppatori che utilizzano aggiornamenti automatici potrebbero aver installato inconsapevolmente codice dannoso, esponendo interi ambienti di sviluppo e produzione.
Credenziali violate e gestione degli incidenti
Al centro dell’attacco c’è la compromissione dell’account npm del maintainer, probabilmente attraverso un token di accesso a lunga durata. Gli aggressori hanno modificato l’indirizzo email associato all’account per mantenere il controllo e pubblicare direttamente le versioni infette.
Questo aspetto sottolinea un punto cruciale: la sicurezza della supply chain non dipende solo dal codice, ma anche dalla protezione delle credenziali. Anche pipeline CI/CD consolidate possono essere aggirate se l’accesso agli account è compromesso.
In seguito alla scoperta, le versioni malevole e la dipendenza incriminata sono state rimosse da npm. Gli utenti sono stati invitati a effettuare un downgrade alle versioni sicure (1.14.0 o 0.30.3) e a ruotare immediatamente tutte le credenziali potenzialmente esposte.
Reazione della comunità open source
La risposta della comunità è stata rapida. Sviluppatori e aziende hanno avviato controlli approfonditi sulle proprie dipendenze, verificando la presenza di eventuali artefatti del malware, come file sospetti nei percorsi di sistema.
L’episodio ha riacceso il dibattito sulle politiche di sicurezza nell’open source, in particolare sulla necessità di controlli più rigorosi nelle dipendenze transitive e sui processi di pubblicazione dei pacchetti.
Alcune analisi hanno inoltre evidenziato che lo stesso malware è stato distribuito anche tramite altri pacchetti npm, ampliando ulteriormente la superficie di attacco.
Importanza della sicurezza nella supply chain Axios
Il caso Axios dimostra come progetti altamente diffusi rappresentino bersagli privilegiati. L’attacco si è distinto per la sua discrezione: il comportamento malevolo era interamente confinato in una dipendenza secondaria, attivata automaticamente dal ciclo di vita di npm.
Il malware, una volta eseguito, effettuava operazioni di ricognizione del sistema, raccogliendo informazioni su file, processi e directory, e inviandole a un server remoto con aggiornamenti periodici. In alcuni casi, come su Windows, era prevista anche una forma di persistenza attraverso script eseguiti a ogni accesso.
Come agire ora sulle dipendenze compromesse
Chi utilizza Axios dovrebbe verificare immediatamente le versioni installate nei propri progetti. È fondamentale rimuovere eventuali tracce della dipendenza “plain-crypto-js” e controllare la presenza di file sospetti nei percorsi indicati per ciascun sistema operativo.
In caso di compromissione, è necessario considerare il sistema come esposto e procedere con la rotazione completa delle credenziali. Parallelamente, è consigliabile bloccare le comunicazioni verso i domini associati al comando e controllo dell’attacco.
L’episodio rappresenta un promemoria chiaro: la gestione delle dipendenze non può essere lasciata all’automazione senza controlli. Monitoraggio continuo, audit delle librerie e protezione degli accessi restano strumenti essenziali per difendere la supply chain.
Fonte: Hacker News
