Vulnerabilità nel pacchetto NPM node-netmask utilizzato in 270mila progetti

Il pacchetto NPM node-netmask, che conta circa 3 milioni di download a settimana ed è utilizzato come dipendenza da più di 270mila progetti su GitHub, presenta una vulnerabilità (CVE-2021-28918) che gli consente di aggirare i controlli che utilizzano la netmask per determinare l'occorrenza negli intervalli di indirizzi o per il filtraggio. Il problema è stato risolto nella versione di node-netmask 2.0.0.

La vulnerabilità permette di trattare un indirizzo IP esterno come un indirizzo della rete interna e viceversa, e con una certa logica di utilizzare il modulo node-netmask nell'applicazione per effettuare SSRF (Server-side request forgery), RFI (Remote File Inclusion) e attacchi LFI (Local File Inclusion) per accedere alle risorse della rete interna e includere file esterni o locali nella catena di esecuzione. Il problema è che secondo le specifiche, i valori delle stringhe di indirizzo che iniziano con uno zero dovrebbero essere interpretati come numeri ottali, ma il modulo node-netmask non ne tiene conto e li tratta come numeri decimali.

Ad esempio, un utente malintenzionato 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à il valore null e tratterà 0177.0.0.1″ come " 177.0.0.1", che nell'applicazione in fase di valutazione delle regole di accesso non sarà possibile determinare l'identità con "127.0.0.1". Allo stesso modo, un utente malintenzionato può specificare l’indirizzo “0127.0.0.1”, che dovrebbe essere identico a “87.0.0.1”, ma verrà trattato come “127.0.0.1” nel modulo “node-netmask”. Allo stesso modo, puoi ingannare il controllo dell'accesso agli indirizzi intranet specificando valori come "012.0.0.1" (equivalente a "10.0.0.1", ma verrà elaborato come 12.0.0.1 durante il controllo).

I ricercatori che hanno identificato il problema lo definiscono catastrofico e forniscono diversi scenari di attacco, ma la maggior parte di essi sembrano speculativi. Si parla ad esempio della possibilità di attaccare un'applicazione basata su Node.js che stabilisce connessioni esterne per richiedere una risorsa in base ai parametri o ai dati della richiesta di input, ma l'applicazione non viene nominata o dettagliatamente specificata. Anche se si trovano applicazioni che caricano risorse in base agli indirizzi IP inseriti, non è del tutto chiaro come si possa sfruttare nella pratica la vulnerabilità senza connettersi ad una rete locale o senza ottenere il controllo degli indirizzi IP “mirror”.

I ricercatori presuppongono solo che i proprietari di 87.0.0.1 (Telecom Italia) e 0177.0.0.1 (Brasil Telecom) siano in grado di aggirare la restrizione di accesso a 127.0.0.1. Uno scenario più realistico consiste nello sfruttare la vulnerabilità per aggirare vari elenchi di blocchi lato applicazione. La questione può essere applicata anche alla condivisione della definizione degli intervalli Intranet nel modulo NPM "ip-privato".

Fonte: opennet.ru

Aggiungi un commento