Nel pacchetto NPM node-netmask, che conta circa 3 milioni di download a settimana e viene utilizzato come dipendenza in oltre 270.000 progetti su GitHub, è stata identificata una vulnerabilità (CVE-2021-28918) che consente di eludere i controlli in cui la maschera di rete è utilizzata per determinare l'inclusione in intervalli di indirizzi o per il filtraggio. Il problema è stato risolto nella versione 2.0.0 di node-netmask.
La vulnerabilità consente di trattare un indirizzo IP esterno come se fosse un indirizzo di una rete interna e viceversa, e con una certa logica di utilizzo del modulo node-netmask in un'applicazione è possibile effettuare attacchi SSRF (Server-side request forgery), RFI (Remote File Inclusion) e LFI (Local File Inclusion) per accedere a risorse nella rete interna e includere nell'esecuzione file esterni o locali. Il problema risiede nel fatto che, secondo la specifica, i valori stringa degli indirizzi che iniziano con zero devono essere interpretati come numeri ottali, ma il modulo 'node-netmask' non tiene conto di questa particolarità e li elabora come numeri decimali.
Ad esempio, un attaccante può richiedere una risorsa locale specificando il valore «0177.0.0.1», che corrisponde a «127.0.0.1», ma il modulo «node-netmask» scarterà lo zero e tratterà «0177.0.0.1» come «177.0.0.1», il che nell'applicazione, durante la valutazione delle regole di accesso, non consentirà di determinare l'equivalenza con «127.0.0.1». Allo stesso modo, un attaccante può specificare l'indirizzo «0127.0.0.1», che dovrebbe essere equivalente a «87.0.0.1», ma nel modulo «node-netmask» verrà trattato come «127.0.0.1». Analogamente, è possibile ingannare il controllo degli accessi agli indirizzi intranet specificando valori simili a «012.0.0.1» (equivalente a «10.0.0.1», ma durante il controllo verrà trattato come «12.0.0.1»).
I ricercatori che hanno identificato il problema lo definiscono catastrofico e menzionano diversi scenari di attacco, ma la maggior parte di essi appare teorica. Ad esempio, si parla della possibilità di attaccare un'applicazione basata su Node.js che stabilisce connessioni esterne per richiedere risorse basate su parametri o dati della richiesta in ingresso, ma l'applicazione specifica non viene menzionata né dettagliata. Anche se si trovassero applicazioni che effettuano il caricamento di risorse basate su input forniti IP addresses, non è del tutto chiaro come si possa sfruttare la vulnerabilità nella pratica senza connettersi a una rete locale o senza avere il controllo degli indirizzi IP "mirror".
I ricercatori ipotizzano solo che i proprietari di 87.0.0.1 (Telecom Italia) e 0177.0.0.1 (Brasil Telecom) abbiano la possibilità di eludere le restrizioni di accesso a 127.0.0.1. Uno scenario più realistico è utilizzare la vulnerabilità per aggirare varie liste di blocco implementate lato applicazione. Il problema potrebbe anche essere applicato per lo scambio delle definizioni degli intervalli intranet nel modulo NPM "private-ip".
Fonte: opennet.ru
