npm v12 blocca gli install script, ma indexed-btree sposta il malware al runtime

🛡️ Executive Summary

• Checkmarx scopre indexed-btree, pacchetto npm che imita sorted-btree e attiva il payload soltanto quando l’applicazione utilizza determinate funzioni.
• La tecnica evita preinstall e postinstall, neutralizzando il vantaggio delle nuove difese install-time introdotte di default con npm v12.
• Il malware usa Slack, Telegram e uno smart contract Ethereum come infrastruttura resiliente per telemetria, esfiltrazione e comando e controllo.

Le nuove difese di npm v12 hanno chiuso diversi percorsi di esecuzione automatica durante npm install, ma gli attaccanti stanno già spostando il codice malevolo dentro il normale runtime delle applicazioni. Checkmarx Zero ha individuato una campagna basata sul pacchetto indexed-btree, clone malevolo della libreria legittima sorted-btree, nel quale il payload non utilizza preinstall, install o postinstall: viene invece eseguito quando il software richiama i metodi della libreria. La differenza è sostanziale. Bloccare gli install script riduce una classe importante di attacchi supply chain, ma non impedisce a una dipendenza apparentemente normale di diventare malevola dopo essere stata importata ed eseguita dall’applicazione.

indexed-btree nasconde l’attacco dentro il normale utilizzo della libreria

La ricerca tecnica originale di Checkmarx Zero descrive indexed-btree come un pacchetto costruito per imitare sorted-btree, libreria JavaScript utilizzata per strutture dati ordinate. Invece di dichiarare un lifecycle script facilmente individuabile nel package.json, il codice malevolo è inserito direttamente nelle implementazioni dei prototipi e viene raggiunto soltanto quando l’applicazione utilizza determinate funzioni.

L’installazione può quindi completarsi senza eseguire alcun payload evidente, lasciando che scanner concentrati sui comportamenti di npm install considerino la dipendenza molto meno sospetta. Al momento della ricerca il pacchetto risultava pubblicato su npm e aveva accumulato milioni di download secondo la telemetria analizzata da Checkmarx. Il modello rappresenta l’evoluzione logica di campagne già viste nell’ecosistema JavaScript: Shai-Hulud aveva trasformato npm e GitHub Actions in un meccanismo di propagazione automatica, mentre PhantomRaven ha mostrato come pacchetti apparentemente innocui possano nascondere il vero payload dietro dipendenze recuperate dinamicamente. indexed-btree cambia ancora posizione al punto d’innesco: non più installazione, ma normale utilizzo del codice.

Leggi anche: ChainDrop compromette oltre 1.300 pacchetti npm e miliardi di download mensili

npm v12 chiude gli install script ma non può impedire a una libreria di essere malevola

Il contesto rende la campagna particolarmente significativa perché npm v12 ha cambiato proprio il modello di fiducia dell’installazione. GitHub ha reso allowScripts disabilitato di default: preinstall, install, postinstall e build implicite tramite node-gyp non vengono più eseguiti automaticamente senza approvazione. Anche dipendenze Git e URL remoti sono ora negate di default attraverso --allow-git e --allow-remote, riducendo i percorsi che in passato consentivano codice automatico durante la risoluzione delle dipendenze. GitHub ha affiancato queste modifiche a scansione malware in fase di pubblicazione, cooldown di tre giorni per alcuni update Dependabot e ampliamento degli alert sulle dipendenze malevole. Sono misure concrete nate dopo campagne capaci di sfruttare una singola credenziale di maintainer per contaminare pacchetti scaricati miliardi di volte. Ma indexed-btree evidenzia il limite strutturale del modello: un package manager può impedire l’esecuzione durante l’installazione, non può impedire l’esecuzione del codice che lo sviluppatore ha deliberatamente importato nel proprio programma. Quando il payload è inserito nella stessa funzione che l’applicazione deve chiamare per utilizzare la libreria, l’esecuzione non appare più come un comportamento anomalo dell’installer ma come normale codice applicativo.

Ethereum diventa un livello C2 difficile da rimuovere

La catena osservata da Checkmarx non si limita all’attivazione ritardata. Una volta eseguito, il malware raccoglie informazioni sul sistema e utilizza Slack e Telegram come canali operativi, mentre uno smart contract Ethereum viene impiegato come componente dell’infrastruttura di comando e controllo. L’uso di una blockchain introduce resilienza perché l’attaccante può pubblicare dati o riferimenti senza dipendere esclusivamente da un dominio tradizionale facilmente sequestrabile o inseribile nelle blocklist. È una tecnica già vista nella campagna ChainVeil, dove il gruppo SuccessKey distribuiva un RAT attraverso npm utilizzando Tron, Aptos e Binance Smart Chain come C2 multilivello. Nel caso indexed-btree, Checkmarx indica inoltre che gli indirizzi associati alla campagna hanno ricevuto complessivamente circa 109 ETH, dato che non dimostra da solo l’origine o la finalità di ogni transazione ma documenta un’infrastruttura finanziariamente attiva. Il passaggio dalla blockchain come mezzo di pagamento alla blockchain come componente operativo del malware complica le attività di difesa: chiudere un webhook o un account Telegram non elimina necessariamente il canale attraverso il quale il malware può recuperare nuove informazioni.

La sicurezza npm deve spostarsi dall’installazione all’intero ciclo di esecuzione

La conseguenza operativa è che --ignore-scripts, allowScripts e le nuove policy di npm v12 restano utili, ma non possono essere considerate una barriera sufficiente contro i pacchetti malevoli. Le organizzazioni devono controllare provenienza, similarità con librerie note, comportamento del codice importato, accessi di rete e modifiche anomale durante il runtime, oltre a mantenere inventari accurati delle dipendenze. La scansione statica del package.json non individua necessariamente un payload nascosto nei metodi della libreria, mentre una pipeline che considera “sicuro” tutto ciò che supera la fase di installazione rischia di perdere proprio la nuova classe di attacchi. GitHub ha già spostato una parte della difesa verso la scansione dei pacchetti prima della pubblicazione e l’ingestione di malware advisory OpenSSF, ma la campagna dimostra che l’ecosistema deve assumere un principio più severo: una dipendenza non è affidabile soltanto perché non esegue script durante l’installazione. Il problema era già evidente quando le difese introdotte dopo Shai-Hulud potevano essere aggirate attraverso dipendenze Git; indexed-btree compie il passo successivo, eliminando la necessità stessa di aggirare l’installazione.

Continua con:

Shai-Hulud cerca 469 tipi di credenziali AI, cloud e CI/CD nei sistemi degli sviluppatori

TeamPCP colpito in Australia: due accusati per la supply chain globale npm

Il prossimo confine non è più npm install, ma ciò che succede dopo

La strategia difensiva dell’ecosistema npm ha correttamente ridotto l’automatismo con cui una dipendenza può eseguire codice appena scaricata. La campagna indexed-btree dimostra però quanto rapidamente l’avversario possa adattarsi: se l’installazione diventa più controllata, il payload viene spostato nella funzione che il programma chiamerà qualche secondo, ora o giorno più tardi. Questo rende meno utile la distinzione tradizionale tra package “installato senza problemi” e package “sicuro”. La supply chain moderna deve essere osservata anche durante l’esecuzione, verificando cosa fanno realmente le dipendenze quando entrano nel processo, quali endpoint raggiungono e quali dati leggono. npm v12 alza la barriera contro una classe importante di compromissioni, ma non può risolvere il problema fondamentale dell’open source: alla fine, importare una libreria significa ancora eseguire codice scritto da qualcun altro sul proprio sistema.