Altri problemi di sicurezza per NPM.js
Non molto tempo fa avevamo segnalato dei problemi di sicurezza emersi durante uno scan dei package presenti sul registry NPM.js, il luogo dove vengono caricate tutte le dipendenze javascript utilizzate da software scritti per girare sotto Node.js, o da numerosi framework ben diffusi sull’Internet come Angular, React.js o Vue.js. Tuttavia, tali problemi scaturivano da mancanze culturali, nell’ambito security, degli autori dei package NPM, come l’utilizzo di password non sicure, oppure da vulnerabilità intrinseche nella scrittura di un dato, specifico software.
Questa volta invece i problemi nascono da motivazioni diverse, ma l’effetto è comunque devastante.
GitHub, che detiene il controllo di NPM.js, ha pubblicato 2 bug di sicurezza nel registry che sono stati corretti tra Ottobre e Novembre di quest’anno. Il primo problema è di origine procedurale: difatti, durante la replica del registry su replicate.npmjs.com, venivano per errore creati dei record che esponevano i nomi dei package privati. Tali package sono sostanzialmente utilizzati dagli account paganti (organizzazioni e simili) per avere nel Cloud delle dipendenze accessibili solo avendo a disposizione delle credenziali con accesso specifico. L’averne a disposizione il nome, in sé e per sé, non sarebbe stato un grandissimo problema, se non fosse stato presente il secondo bug di sicurezza pubblicato da GitHub. Tale bug, infatti, permetteva di pubblicare, senza autorizzazione, pacchetti sul registry utilizzando delle validazioni pubblicate per altri pacchetti. Va da sé che il risultato di una combinazione di problematiche come questa avrebbe permesso ad un eventuale attaccante di compromettere intere organizzazioni.
L’impatto di una tale vulnerabilità richiederebbe, normalmente, uno scan di sicurezza globale, sull’intero registry e un report completo, anche per rassicurare i propri clienti paganti sulla solidità del proprio ecosistema e della propria infrastruttura. Invece, a valle della pubblicazione (e quindi, si spera, anche delle mitigation necessarie), GitHub si è limitato a commentare asserendo di avere un certo grado di sicurezza relativamente al fatto che la vulnerabilità non sia stata sfruttata da Settembre 2020.
E’ doveroso riportare anche il fatto che, contemporaneamente rispetto alla problematica sopra riportata, siano stati segnalati degli hijack dei moduli ua-parser.js, coa e rc, nei quali, all’interno del codice delle librerie, sono stati introdotti degli snippet con codici di cryptominer e svariati trojan.
Per mitigare i recenti avvenimenti, GitHub si è premurato di avvisare che entro il primo quarto del 2022 porrà come obbligatoria la two-factor authentication ai maintainer di NPM.js, ma, come si dice, la frittata ormai è fatta.
Sostenitore di lunga data dell’Open Source, Sysadmin ma anche programmatore, mi appassiona qualsiasi cosa nell’IT che possa permettere un’espressione di creatività. Nostalgico della filosofia dei tempi andati, ma incuriosito dalle potenzialità dei paradigmi moderni.
Fonte: https://www.miamammausalinux.org/2021/11/altri-problemi-di-sicurezza-per-npm-js/
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
