Un attacco alla catena di distribuzione critica ha colpito la libreria JavaScript Axios, ampiamente utilizzata, in seguito alla compromissione dell'account npm del suo principale manutentore. Gli attori della minaccia hanno utilizzato l'account dirottato per pubblicare due versioni dannose, axios@1.14.1 e axios@0.30.4, che introducevano una dipendenza illecita (plain-crypto-js@4.2.1). Questa dipendenza non faceva parte della base di codice legittima di Axios ed esisteva solo per eseguire uno script di post-installazione che distribuiva un Trojan di accesso remoto (RAT) multipiattaforma.

L'attacco è stato altamente coordinato. La dipendenza dannosa è stata preparata in anticipo e successivamente iniettata nei rami di release di Axios attuali e precedenti in un breve lasso di tempo, massimizzando l'impatto. Poiché il codice dannoso risiede in una dipendenza transitiva piuttosto che in Axios stesso, la revisione tradizionale del codice o il rilevamento basato su diff probabilmente non riuscirebbero a identificare la compromissione. Inoltre, il malware è progettato per rimuoversi dopo l'esecuzione e sostituire le prove all'interno della directory del pacchetto, complicando notevolmente l'analisi forense.

Una volta installato, lo script dropper contatta un server di comando e controllo (sfrclak[.]com) e recupera un payload di secondo livello adattato al sistema operativo. Su macOS, distribuisce un binario camuffato da demone della cache di sistema; su Windows, sfrutta PowerShell eseguito tramite un binario camuffato; su Linux, distribuisce una backdoor basata su Python. Questi payload consentono l'esecuzione di comandi remoti, l'esfiltrazione di dati e l'invio di ulteriori payload. Sebbene il malware non sembri stabilire la persistenza per impostazione predefinita, le sue capacità consentono agli aggressori di aumentare rapidamente l'accesso o di implementare meccanismi aggiuntivi.

A causa della natura auto-cancellante del dropper, l'identificazione della compromissione richiede una combinazione di analisi delle dipendenze, ispezione degli artefatti di sistema ed esame dei registri. Le organizzazioni devono esaminare i pacchetti installati e i file di blocco delle versioni di Axios interessate, verificare se la directory plain-crypto-js esiste o esisteva e controllare gli endpoint alla ricerca di indicatori quali /Library/Caches/com.apple.act.mond, %PROGRAMDATA%\wt.exe o /tmp/ld.py. I registri di rete devono essere esaminati anche per verificare la comunicazione con l'infrastruttura di comando e controllo nota. Qualsiasi indicatore confermato deve essere considerato come prova di una compromissione completa del sistema.

Cosa fare

Se nel vostro ambiente è stata installata una delle versioni dannose di Axios, dovete presumere una compromissione e reagire di conseguenza. I sistemi non devono essere ripuliti sul posto, poiché non è possibile determinare in modo affidabile l'intera portata dell'attività dell'aggressore. I computer interessati devono invece essere ricostruiti a partire da una linea di base affidabile e nota per garantire l'eliminazione completa di qualsiasi componente dannoso.

Tutte le credenziali che potrebbero essere state esposte sui sistemi colpiti devono essere ruotate immediatamente. Ciò include i token npm, le credenziali dei provider cloud, le chiavi SSH, le chiavi API, le variabili d'ambiente e tutti i segreti utilizzati nelle pipeline CI/CD. Particolare attenzione deve essere prestata ai sistemi di compilazione e alle pipeline di automazione, poiché spesso hanno accesso a credenziali altamente sensibili e potrebbero aver eseguito il pacchetto dannoso durante le compilazioni di routine.

Come parte del contenimento, le organizzazioni devono bloccare le comunicazioni in uscita verso il dominio di comando e controllo identificato e gli indirizzi IP associati. I team di sicurezza devono inoltre esaminare i registri per individuare connessioni in uscita sospette, esecuzione di processi insoliti o segni di esfiltrazione dei dati durante il periodo in cui i pacchetti dannosi erano disponibili.

Per il ripristino, Axios deve essere declassato a una versione sicura, come la 1.14.0 o la 0.30.3, e la dipendenza dannosa deve essere rimossa, se presente. Le dipendenze devono essere reinstallate utilizzando pratiche più sicure, come la disabilitazione degli script del ciclo di vita, se possibile. Le pipeline CI/CD dovrebbero adottare impostazioni predefinite sicure come npm ci --ignore-scripts per ridurre il rischio che attacchi simili vengano eseguiti automaticamente in futuro.

A più lungo termine, le organizzazioni dovrebbero rafforzare la postura di sicurezza della catena di fornitura del software. Ciò include l'applicazione di un rigoroso pinning delle dipendenze, la verifica delle dipendenze dirette e transitive e l'implementazione di strumenti in grado di rilevare i pacchetti dannosi in tempo reale. È fondamentale ridurre la fiducia implicita nei registri e nei manutentori dei pacchetti, poiché questo incidente dimostra come un singolo account compromesso possa avere effetti a cascata su migliaia di applicazioni a valle.

Questo attacco sottolinea la crescente sofisticazione delle minacce alla catena di approvvigionamento all'interno dell'ecosistema open-source. Sfruttando canali di distribuzione affidabili, gli aggressori possono ottenere un accesso diffuso con il minimo sforzo, rendendo il monitoraggio proattivo, la risposta rapida e la difesa in profondità componenti essenziali della moderna strategia di sicurezza informatica.

Se siete preoccupati per una qualsiasi delle minacce descritte in questo bollettino o avete bisogno di aiuto per determinare le misure da adottare per proteggervi dalle minacce più concrete che la vostra organizzazione deve affrontare, contattate il vostro account manager o, in alternativa, mettetevi in contattoper scoprire come potete proteggere la vostra organizzazione.