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 bypassare le verifiche in cui la maschera di rete viene utilizzata per determinare l'appartenenza a intervalli di indirizzi o per il filtraggio. Il problema è stato risolto nella versione node-netmask 2.0.0.
La vulnerabilità consente di trattare un indirizzo IP esterno come un indirizzo di una rete interna e viceversa, e, con una determinata logica d'uso del modulo node-netmask in un'applicazione, di attuare attacchi SSRF (Server-side request forgery), RFI (Remote File Inclusion) e LFI (Local File Inclusion) per accedere a risorse sulla rete interna e includere nella catena di esecuzione file esterni o locali. Il problema sta nel fatto che, secondo le specifiche, i valori stringa degli indirizzi che iniziano con zero devono essere interpretati come numeri ottali, ma il modulo 'node-netmask' non considera questa particolarità e li gestisce come numeri decimali.
Ad esempio, un attaccante potrebbe 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 permetterà di stabilire l'identità con '127.0.0.1'. Analogamente, un attaccante può specificare l'indirizzo '0127.0.0.1', che dovrebbe essere identico a '87.0.0.1', ma nel modulo 'node-netmask' sarà trattato come '127.0.0.1'. Si può inoltre ingannare il controllo degli accessi agli indirizzi intranet, specificando valori come '012.0.0.1' (equivalente a '10.0.0.1', ma verrà gestito come '12.0.0.1').
I ricercatori che hanno individuato il problema lo definiscono catastrofico e forniscono diversi scenari di attacco, ma la maggior parte di essi appare ipotetica. Ad esempio, si parla della possibilità di attaccare un'applicazione basata su Node.js, che stabilisce connessioni esterne per richiedere risorse in base ai parametri o ai dati della richiesta in ingresso, ma non viene specificato alcun nome di applicazione né si forniscono dettagli. Anche se si trovano applicazioni che caricano risorse in base agli input indirizzi IP, non è affatto chiaro come si possa applicare la vulnerabilità nella pratica senza connettersi a una rete locale o senza ottenere il controllo su indirizzi IP 'speculari'.
I ricercatori ipotizzano solo che i proprietari di 87.0.0.1 (Telecom Italia) e 0177.0.0.1 (Brasil Telecom) possano aggirare le restrizioni di accesso a 127.0.0.1. Uno scenario più realistico è l'uso della vulnerabilità per bypassare vari elenchi di blocco implementati lato applicazione. Il problema può anche essere applicato per lo scambio delle definizioni degli intervalli intranet nel modulo NPM "private-ip".
Fonte: opennet.ru
