Un errore di un solo carattere che ha trasmesso malware
Tutto è iniziato con un errore di battitura. Da qualche parte, nel mezzo dell'enorme corsa alle novità e alle fusioni di PR, qualcuno ha digitato @utils_core invece di @utils-core nella pacchetto.json. Quel singolo carattere non ha generato un errore. Invece, ha silenziosamente inserito un pacchetto sosia dannoso durante il prossimo CI/CD eseguire, sfruttando la fiducia nelle versioni bloccate e nell'automazione. Benvenuti nel mondo del typosquatting nell'open source.
Typosquatting: il vettore di attacco che prospera sull'errore umano
Il typosquatting è esattamente ciò che sembra: malintenzionati che registrano pacchetti con nomi quasi identici a quelli legittimi. In ambienti frenetici, questo funziona perché gli sviluppatori confidano nel fatto che i loro pacchetto.json e Pacchetto-lock.json riflettono ciò che si aspettano. Un carattere in meno? Potrebbe anche essere invisibile in una differenza di PR.
NPM ha una storia di sfruttamento tramite typosquatting. Pacchetti come attraversare invece di cross-env or flusso di eventi Le backdoor hanno già dimostrato quanto possano essere efficaci questi pacchetti simili. Questi pacchetti falsi spesso superano le revisioni semplicemente perché hanno un aspetto corretto e non generano errori di runtime immediati.
Le trappole più comuni includono:
- Trattino vs. sottolineatura: lodash-core vs lodash_core
- Plurali: richiesta vs richieste
- Caratteri sostituiti: espressione invece di esprimere
Dove package-lock.json diventa un punto cieco
Lo sviluppatore corregge l'errore di battitura. O almeno così pensa. Ma ormai, Pacchetto-lock.json ha già bloccato il pacchetto dell'attaccante. Ed è qui che si nasconde il vero rischio.
a differenza di pacchetto.json, che viene modificato manualmente e sottoposto a un controllo più approfondito, Pacchetto-lock.json è generato automaticamente da NPMDi conseguenza, viene spesso trattato come una formalità, saltato o solo sfiorato pull request recensioni. Non è raro che i team lo contrassegnino come "troppo rumoroso" o che si fidino implicitamente di esso senza esaminarlo attentamente.
Gli aggressori lo sanno. Ci fanno affidamento. Una volta che un pacchetto dannoso è referenziato, grazie a un errore di battitura in pacchetto.json, pacchetto-lock.json Registra la versione risolta. Anche se l'errore di battitura viene corretto in seguito, la voce dannosa può persistere a meno che il file di blocco non venga rigenerato esplicitamente.
A peggiorare le cose, il version pinning, che dovrebbe garantire la coerenza, può ritorcersi contro. Gli aggressori possono creare una versione del loro pacchetto falso identica a quella legittima. Se... CI/CD Il sistema si fida ciecamente delle versioni bloccate, non rileverà che sta installando un pacchetto con un numero di versione noto come valido ma proveniente da una fonte diversa e dannosa.
Questa persistenza silenziosa è ciò che rende Pacchetto-lock.json così pericoloso. Garantisce build deterministiche, certo, ma garantisce anche che un pacchetto difettoso rimanga in giro a meno che non venga individuato e ripulito manualmente.
CI/CD: Dove colpisce il malware – package.json
In un tipico CI/CD pipeline, il pacchetto dannoso non deve attendere fino al runtime. Viene risolto e attivato molto prima nel flusso:
Risoluzione delle dipendenze
Migliori pipeline estrae le versioni esatte delle dipendenze da package-lock.json, che ora include il pacchetto typosquatted a causa dell'errore di battitura in pacchetto.json.
Fase di installazione
Durante l'installazione di npm ci, tutte le dipendenze vengono installate, inclusa quella dannosa. Nessun avviso, nessuna richiesta, solo installazione silenziosa.
Esecuzione dello script post-installazione
Il pacchetto lookalike include uno script post-installazione che viene eseguito automaticamente al termine dell'installazione. È qui che avviene la compromissione.
Esempio di pseudocodice:
if (installation_phase_active) {
runHiddenPayload()
}Descrizione dello pseudocodice:
Durante la fase di installazione, se è presente il gancio del ciclo di vita post-installazione, il pacchetto falso attiva la sua logica nascosta, spesso prima ancora che vengano eseguite build o test. Ciò potrebbe comportare l'esecuzione di richieste esterne, l'iniezione di backdoor o altre azioni non autorizzate.
⚠️ Attenzione: questo pseudocodice è solo a scopo dimostrativo e non deve essere utilizzato in ambienti reali.
Non vengono attivati avvisi. Non si verifica alcun errore. L'ambiente è già compromesso, prima che tu... pipeline raggiunge addirittura la fase di test.
Individuare la differenza prima che sia troppo tardi
Un errore comune: presumere pacchetto.json racconta tutta la storia. Non lo fa. Il vero potere risiede nella combinazione di pacchetto.json + pacchetto-lock.json.
Ecco cosa cercare:
- Se la Pacchetto-lock.json includere pacchetti inaspettati?
- Ci sono dipendenze che provengono da registri sconosciuti o hanno ambiti strani?
- I numeri di versione sono troppo specifici o non allineati?
Utilizzare strumenti CLI come:
- controllo npm per segnalare problemi noti
- npm ls per visualizzare l'albero completo delle dipendenze
- diff per confrontare le versioni tra pacchetto.json e Pacchetto-lock.json
Indurisci il tuo Pipeline: Difese che funzionano
Per difendersi dal typosquatting:
- Applicare restrizioni di ambito in pacchetto.json.
- Aggiungi pre-unione hooks per eseguire il lint e convalidare le dipendenze.
- Usa il npm ci per evitare deviazioni involontarie della versione.
- Scansionare regolarmente Pacchetto-lock.json per anomalie.
E soprattutto: tratta le voci non verificate in Pacchetto-lock.json come potenziali rischi. Ogni commit dovrebbe essere considerato un punto di controllo della catena di approvvigionamento.
Rilevamento automatico: come strumenti come Xygeni possono aiutare
Sebbene non siano una soluzione miracolosa, strumenti automatizzati come Xygeni svolgono un ruolo fondamentale nel ridurre il fattore di errore umano, fattore che favorisce il typosquatting. Xygeni si integra direttamente nel flusso di lavoro DevOps, aggiungendo un livello di protezione in tempo reale contro il dirottamento delle dipendenze prima ancora che raggiunga l'esecuzione.
Ecco come Xygeni può aiutarti:
- Rilevamento del nome del pacchetto sospetto:
Utilizza euristiche intelligenti per rilevare modelli di typosquatting in pacchetto.json, cercando piccole variazioni nei nomi di pacchetti noti (come sottolineature aggiunte, trasposizioni o scambi di lettere). - Verifica hash sconosciuta:
Confronta l'hash di ogni dipendenza in Pacchetto-lock.json confrontandolo con un database di artefatti noti e validi provenienti da registri attendibili. Anche se il nome e la versione di un pacchetto sembrano corretti, una mancata corrispondenza dell'hash segnala un problema. - Blocco prima della compilazione:
Intercetta e blocca l'installazione di pacchetti non verificati o sospetti prima che raggiungano le fasi di installazione o post-installazione nel CI/CD pipeline. - Analisi del grafico delle dipendenze:
Esamina costantemente l'intero albero delle dipendenze per individuare tentativi indiretti di typosquatting o dipendenze transitive dannose. - Avvisi e segnalazioni:
Fornisce avvisi dettagliati e fruibili, che mostrano cosa è stato segnalato, perché e da dove proviene nella catena delle dipendenze.
Con la crescente complessità degli ecosistemi di pacchetti, strumenti come Xygeni diventano essenziali. La revisione manuale non è scalabile con la proliferazione delle dipendenze o l'iterazione rapida. Xygeni interviene per automatizzare i controlli critici moderni. pipelinedi cui ha bisogno, colmando il divario tra fiducia e verifica.
Un personaggio. Conseguenze reali.
Questo non era un esotico zero-dayEra un errore di battitura. Un carattere fuori posto in pacchetto.json, silenziosamente rinforzato da Pacchetto-lock.jsone il malware veniva spedito, automaticamente, durante una routine CI/CD eseguire.
Questo è il vero pericolo del typosquatting: non ha bisogno di complessità. Sfrutta velocità, fiducia e automazione. Questo compromesso avrebbe potuto essere evitato con i controlli giusti:
- Scansione automatizzata per rilevare nomi e versioni di pacchetti sospetti prima dell'installazione.
- Controllo dei file di blocco per rilevare voci non riviste o inaspettate in Pacchetto-lock.json.
- Euristica di verifica del nome per segnalare le corrispondenze vicine ai pacchetti attendibili.
Bastava un solo carattere. I controlli giusti l'avrebbero fermato prima che toccasse il tuo pipelineLa fiducia non basta. Nelle moderne DevSecOps, si verifica tutto, altrimenti si rischia tutto.
