Qualche giorno fa GitHub ha rivelato due incidenti nell'infrastruttura del repository dei pacchetti NPM, di cui dettaglia che il 2 novembre, ricercatori di sicurezza di terze parti come parte del programma Bug Bounty hanno trovato una vulnerabilità nel repository NPM che permette di pubblicare una nuova versione di qualsiasi pacchetto utilizzando anche se non è autorizzato per eseguire tali aggiornamenti.
La vulnerabilità è stata causata da controlli di autorizzazione errati nel codice dei microservizi che elaborano le richieste a NPM. Il servizio di autorizzazione ha eseguito un controllo delle autorizzazioni sui pacchetti in base ai dati passati nella richiesta, ma un altro servizio che stava caricando l'aggiornamento nel repository ha determinato il pacchetto da pubblicare in base al contenuto dei metadati nel pacchetto caricato.
Pertanto, un utente malintenzionato potrebbe richiedere la pubblicazione di un aggiornamento per il suo pacchetto, a cui ha accesso, ma indicare nel pacchetto stesso informazioni su un altro pacchetto, che alla fine verrebbe aggiornato.
Negli ultimi mesi, il team di npm ha investito in infrastrutture e miglioramenti della sicurezza per automatizzare il monitoraggio e l'analisi delle versioni dei pacchetti rilasciate di recente per identificare malware e altro codice dannoso in tempo reale.
Esistono due categorie principali di eventi di pubblicazione di malware che si verificano nell'ecosistema npm: malware che viene pubblicato a causa del dirottamento dell'account e malware che gli aggressori pubblicano tramite i propri account. Sebbene le acquisizioni di account ad alto impatto siano relativamente rare, rispetto al malware diretto inviato dagli aggressori utilizzando i propri account, le acquisizioni di account possono essere di vasta portata quando si prendono di mira i manutentori di pacchetti più diffusi. Sebbene il nostro tempo di rilevamento e risposta alle acquisizioni di pacchetti popolari sia stato di appena 10 minuti negli incidenti recenti, continuiamo a evolvere le nostre capacità di rilevamento di malware e strategie di notifica verso un modello di risposta più proattivo.
Il problema è stato corretto 6 ore dopo la segnalazione della vulnerabilità, ma la vulnerabilità è rimasta più a lungo in NPM rispetto a quanto coperto dai registri di telemetria. GitHub afferma che non ci sono state tracce di attacchi che utilizzano questa vulnerabilità da settembre 2020, ma non vi è alcuna garanzia che il problema non sia stato sfruttato in precedenza.
Il secondo incidente è avvenuto il 26 ottobre. Nel corso del lavoro tecnico con il database del servizio replicant.npmjs.com, è stato rivelato che c'erano dati riservati nel database disponibili per la consultazione esterna, rivelando informazioni sui nomi dei pacchetti interni menzionati nel changelog.
Informazioni su quei nomi può essere utilizzato per eseguire attacchi di dipendenza su progetti interni (A febbraio, un tale attacco ha consentito l'esecuzione del codice sui server di PayPal, Microsoft, Apple, Netflix, Uber e altre 30 società.)
Inoltre, in relazione alla crescente incidenza dei sequestri di archivi di grandi progetti e la promozione di codice dannoso attraverso la compromissione degli account degli sviluppatori, GitHub ha deciso di introdurre l'autenticazione a due fattori obbligatoria. La modifica entrerà in vigore nel primo trimestre del 2022 e si applicherà ai manutentori e agli amministratori dei pacchetti inclusi nell'elenco dei più popolari. Inoltre, riferisce sulla modernizzazione dell'infrastruttura, che introdurrà il monitoraggio e l'analisi automatizzati di nuove versioni di pacchetti per il rilevamento precoce di modifiche dannose.
Ricordiamo che secondo uno studio condotto nel 2020, solo il 9.27% dei gestori di pacchetti utilizza l'autenticazione a due fattori per proteggere l'accesso e nel 13.37% dei casi, durante la registrazione di nuovi account, gli sviluppatori hanno cercato di riutilizzare le password compromesse che appaiono nelle password note .
Durante la verifica della robustezza delle password utilizzate, si è avuto accesso al 12% degli account in NPM (13% dei pacchetti) grazie all'utilizzo di password prevedibili e banali come "123456". Tra i problemi c'erano 4 account utente dei 20 pacchetti più popolari, 13 account i cui pacchetti sono stati scaricati più di 50 milioni di volte al mese, 40 - più di 10 milioni di download al mese e 282 con più di 1 milione di download al mese. Considerando il carico del modulo lungo la catena delle dipendenze, la compromissione di account non attendibili potrebbe interessare fino al 52% di tutti i moduli in NPM in totale.
Infine, se sei interessato a saperne di più puoi controllare i dettagli nel seguente link