Home Tecnologia Gli hacker hanno inserito un trojan nella libreria di codici dietro la...

Gli hacker hanno inserito un trojan nella libreria di codici dietro la maggior parte di Web. Probabilmente la tua squadra è interessata

3
0

Gli aggressori hanno rubato un token di accesso npm di lunga durata appartenente al principale manutentore di assila libreria shopper HTTP più popolare in JavaScript, e l’ha utilizzata per pubblicare due versioni avvelenate che installano un trojan di accesso remoto multipiattaforma. Le versioni dannose prendono di mira macOS, Home windows e Linux. Erano attivi nel registro npm per circa tre ore prima della rimozione.

Axios ottiene più di 100 milioni di obtain a settimana. Lo riferisce Wiz si trova in circa l’80% degli ambienti cloud e di codice, toccando qualsiasi cosa, dai front-end React alle pipeline CI/CD alle funzioni serverless. Cacciatrice rilevata le prime infezioni 89 secondi dopo che il pacchetto dannoso è diventato operativo e ha confermato almeno 135 sistemi compromessi tra i suoi clienti durante la finestra di esposizione.

Questa è la terza maggiore npm Compromissione della catena di fornitura in sette mesi. Ognuno ha sfruttato le credenziali del manutentore. Questa volta, l’obiettivo aveva adottato tutte le difese raccomandate dalla comunità della sicurezza.

Una credenziale, due filiali, 39 minuti

L’aggressore ha preso il sopravvento npm account di @jasonsaayman, uno dei principali manutentori di axios, ha cambiato l’e-mail dell’account in un indirizzo ProtonMail anonimo e ha pubblicato i pacchetti avvelenati tramite npml’interfaccia della riga di comando di. Ciò ha bypassato completamente la pipeline CI/CD di GitHub Actions del progetto.

L’aggressore non ha mai toccato il codice sorgente di Axios. Invece, entrambi i rami di rilascio hanno ricevuto un’unica nuova dipendenza: plain-crypto-js@4.2.1. Nessuna parte della codebase lo importa. Il pacchetto esiste esclusivamente per eseguire uno script postinstallazione che rilascia un RAT multipiattaforma sul laptop dello sviluppatore.

La messa in scena period precisa. Diciotto ore prima del rilascio di axios, l’aggressore ha pubblicato una versione pulita del file plain-crypto-js sotto un separato npm account per creare la cronologia di pubblicazione ed evitare gli avvisi dello scanner di nuovi pacchetti. Poi è arrivato il 4.2.1 armato. Entrambi i rami di rilascio hanno raggiunto entro 39 minuti. Sono stati precostruiti tre payload specifici della piattaforma. Il malware si cancella automaticamente dopo l’esecuzione e viene sostituito con un bundle.json pulito per ostacolare l’ispezione forense.

StepSecurityche identificava il compromesso a fianco PRESAlo ha definito uno degli attacchi alla catena di fornitura più sofisticati dal punto di vista operativo mai documentati contro una delle prime 10 minacce npm pacchetto.

La difesa che esisteva sulla carta

Axios ha fatto le cose giuste. Versioni legittime 1.x spedite tramite GitHub Actions utilizzando npmIl meccanismo OIDC Trusted Writer di, che lega crittograficamente ogni pubblicazione a un flusso di lavoro CI/CD verificato. Il progetto prevedeva attestati di provenienza SLSA. Secondo ogni misura moderna, lo stack di sicurezza sembrava solido.

Niente di tutto ciò aveva importanza. Huntress ha approfondito il flusso di lavoro di pubblicazione e ho trovato il divario. Il progetto è comunque passato NPM_TOKEN come variabile di ambiente proprio accanto alle credenziali OIDC. Quando entrambi sono presenti, npm per impostazione predefinita è il token. Il token classico di lunga durata period il vero metodo di autenticazione per ogni pubblicazione, indipendentemente da come period configurato OIDC. L’attaccante non ha mai dovuto sconfiggere l’OIDC. Ci hanno fatto il giro. Un token legacy period lì come percorso di autenticazione parallelo e npmla stessa gerarchia lo preferiva silenziosamente.

“Dalla mia esperienza in AWS, è molto comune che i vecchi meccanismi di autenticazione persistano”, ha affermato Merritt Baer, ​​CSO di Enkrypt AI ed ex vice CISO di AWS, in un’intervista esclusiva con VentureBeat. “Vengono implementati i controlli moderni, ma se i token o le chiavi legacy non vengono ritirati, il sistema li favorisce silenziosamente. Proprio come abbiamo visto con SolarWinds, dove gli script legacy ignoravano il monitoraggio più recente.”

Il manutentore pubblicato su GitHub dopo aver scoperto il compromesso: “Sto cercando di ottenere supporto per capire come sia successo. Ho 2FA/MFA praticamente su tutto ciò con cui interagisco.”

Documentato da Endor Labs la differenza forense. Legittimo axios@1.14.0 mostrava la provenienza OIDC, un report di editore affidabile e un collegamento gitHead a un commit specifico. Dannoso axios@1.14.1 non ne aveva nessuno. Qualsiasi strumento di controllo della provenienza avrebbe segnalato immediatamente il divario. Ma la verifica della provenienza è facoltativa. Nessuna porta del registro ha rifiutato il pacchetto.

Tre attacchi, sette mesi, stessa causa

Tre npm compromessi della catena di fornitura in sette mesi. Tutti hanno iniziato con credenziali di manutentore rubate.

IL Verme Shai-Hulud colpito nel settembre 2025. Un unico account di manutenzione phishing ha fornito agli aggressori un punto d’appoggio che si è auto-replicato attraverso più di 500 pacchiraccolta npm token, credenziali cloud e segreti GitHub man mano che si diffondeva. La CISA ha emesso un avviso. GitHub revisionato npm’L’intero modello di autenticazione in risposta.

Poi, nel gennaio 2026, Koi Safety’s Ricerca PackageGate eliminato sei vulnerabilità zero-day su npm, pnpm, vlte Bun che ha sfondato le stesse difese adottate dall’ecosistema dopo Shai-Hulud. L’integrità del lockfile e il blocco degli script hanno fallito entrambi in condizioni specifiche. Tre dei quattro gestori di pacchetti hanno applicato le patch in poche settimane. npm ha chiuso il rapporto.

Ora assios. Un token di lunga durata rubato ha pubblicato un RAT attraverso entrambi i rami di rilascio nonostante OIDC, SLSA e ogni misura di rafforzamento post-Shai-Hulud in atto.

npm ha avviato vere riforme dopo Shai-Hulud. La creazione di nuovi token classici è stata deprecata, sebbene quelli preesistenti siano sopravvissuti fino a una scadenza fissa per la revoca. FIDO 2FA è diventato obbligatorio, i token di accesso granulare sono stati limitati a sette giorni per la pubblicazione e la pubblicazione affidabile tramite OIDC ha fornito ai progetti un’alternativa crittografica alle credenziali archiviate. Nel loro insieme, questi cambiamenti hanno rafforzato tutto a valle dell’account del manutentore. Ciò che non hanno cambiato è stato l’account stesso. La credenziale è rimasta l’unico punto di fallimento.

“Il compromesso delle credenziali è il tema ricorrente npm violazioni”, ha detto Baer. “Questo non è solo un problema di password deboli. È strutturale. Senza credenziali temporanee, MFA forzata o ambienti di compilazione e firma isolati, l’accesso del manutentore rimane l’anello debole”.

Ciò che npm ha spedito rispetto a ciò che questo attacco ha superato

Di cosa hanno bisogno i chief SOC

npm difesa spedita

contro l’attacco di Axios

Il divario

Blocca la pubblicazione dei token rubati

È richiesto FIDO 2FA. Token granulari, scadenza 7 giorni. I token classici sono deprecati

Bypassato. Il token legacy coesisteva insieme a OIDC. npm preferiva il gettone

Nessuna applicazione rimuove i token legacy quando è configurato OIDC

Verificare la provenienza del pacco

Pubblicazione attendibile OIDC tramite azioni GitHub. Attestazioni SLSA

Bypassato. Le versioni dannose non avevano provenienza. Pubblicato tramite CLI

Nessun gate rifiuta i pacchi privi di provenienza da progetti che la possedevano in precedenza

Cattura il malware prima dell’installazione

Scansione automatizzata Socket, Snyk, Aikido

Parziale. Socket contrassegnato in 6 minuti. Le prime infezioni si sono verificate a 89 secondi

Divario tra rilevamento e rimozione. Gli scanner lo rilevano, la rimozione del registro richiede ore

Blocca l’esecuzione postinstallazione

–ignore-script consigliati in CI/CD

Non applicato. npm esegue la postinstallazione per impostazione predefinita. pnpm blocchi per impostazione predefinita; npm no

postinstall rimane il principale vettore di malware in tutti i principali npm attacco dal 2024

Blocca le versioni delle dipendenze

Applicazione del file di blocco tramite npm ci

Efficace solo se il file di lock è stato committato prima della compromissione. Intervalli con cursore risolti automaticamente

Gli intervalli di accento circonflesso sono npm predefinito. La maggior parte dei progetti si risolve automaticamente all’ultimo minore

Cosa fare adesso nella tua azienda

I chief SOC le cui organizzazioni eseguono Node.js dovrebbero considerare questo come un incidente attivo finché non confermeranno che i sistemi sono puliti. La finestra di esposizione di tre ore cadeva durante le ore di picco dello sviluppo nei fusi orari dell’Asia-Pacifico e qualsiasi pipeline CI/CD che eseguiva npm set up durante la notte avrebbe potuto estrarre automaticamente la versione compromessa.

“La prima priorità è la valutazione dell’impatto: quali edifici e quali consumatori a valle hanno ingerito il pacchetto compromesso?” Ha detto Baer. “Poi il contenimento, l’applicazione di patch e, infine, un reporting trasparente alla management. Cosa è successo, cosa è emerso e quali controlli impediranno che si ripeta. Le lezioni di log4j e event-stream mostrano che la velocità e la chiarezza contano tanto quanto la correzione stessa.”

  • Controlla l’esposizione. Cerca file di blocco e registri CI axios@1.14.1, axios@0.30.4O plain-crypto-js. Aggiungi a axios@1.14.0 O axios@0.30.3.

  • Assumi un compromesso se colpito. Ricostruisci le macchine interessate da uno stato sicuramente funzionante. Ruota tutte le credenziali accessibili: token npm, chiavi AWS, chiavi SSH, credenziali cloud, segreti CI/CD, valori .env.

  • Blocca il C2. Aggiungere sfrclak.com e 142.11.206.73 alle blocklist DNS e alle regole del firewall.

  • Verificare la presenza di artefatti RAT. /Library/Caches/com.apple.act.mond su macOS. %PROGRAMDATApercentwt.exe su Home windows. /tmp/ld.py on Linux. Se trovato, eseguire una ricostruzione completa.

  • Rafforzare andando avanti. Applicare npm ci --ignore-scripts in CI/CD. Richiede installazioni solo di lockfile. Rifiuta i pacchetti privi di provenienza da progetti che la possedevano in precedenza. Controlla se i token legacy coesistono con OIDC nei tuoi flussi di lavoro di pubblicazione.

Il divario di credenziali che nessuno ha colmato

Tre attacchi in sette mesi. Ognuno diverso nell’esecuzione, identico nella causa principale. npmIl modello di sicurezza di considera ancora gli account dei singoli manutentori come l’ancora di fiducia definitiva. Tali account rimangono vulnerabili al dirottamento delle credenziali, indipendentemente dal numero di livelli aggiunti a valle.

“L’intelligenza artificiale individua i pacchetti rischiosi, controlla l’autenticazione legacy e accelera la risposta del SOC”, ha affermato Baer. “Ma gli esseri umani continuano a controllare le credenziali dei manutentori. Noi mitighiamo il rischio. Non lo eliminiamo.”

L’attestazione di provenienza obbligatoria, in cui la pubblicazione manuale della CLI è completamente disabilitata, avrebbe rilevato questo attacco prima che raggiungesse il registro. Lo stesso vale per la firma obbligatoria da parte di più parti, in cui nessun singolo manutentore può promuovere un rilascio da solo. Nessuno dei due viene applicato oggi. npm ha segnalato che la disabilitazione dei token per impostazione predefinita quando è abilitata la pubblicazione attendibile è sulla tabella di marcia. Fino alla spedizione, ogni progetto che esegue OIDC insieme a un token legacy avrà gli stessi assi del punto cieco.

Il manutentore di axios ha fatto ciò che la comunità aveva chiesto. Un token legacy che nessuno si period reso conto fosse ancora attivo e minava tutto.

fonte

LEAVE A REPLY

Please enter your comment!
Please enter your name here