L'indirizzo 0.0.0.0 può esporre le risorse di rete alle applicazioni remote

Molti utenti conoscono il cosiddetto indirizzo di loopback o localhost 127.0.0.1: è comunemente utilizzato per fare riferimento alla macchina stessa, cioè al computer su cui è in esecuzione il software. Quando un programma utilizza l’indirizzo 127.0.0.1, esso comunica con il sistema sottostante senza coinvolgere la rete. È molto utile per testare servizi di rete o per configurare server locali per lo sviluppo. Esiste però anche lo speciale indirizzo 0.0.0.0 che rappresenta “tutti gli indirizzi IPv4 non specificati” e non corrisponde a un dispositivo specifico.

Della differenza tra gli indirizzi IP 127.0.0.1 e 0.0.0.0 abbiamo già parlato in un altro articolo. Ad ogni modo, quando un server è configurato per ascoltare le richieste di collegamento sull’IP 0.0.0.0, significa che accetta connessioni su tutte le interfacce di rete disponibili sul sistema. In pratica, il server risulta accessibile tramite qualsiasi indirizzo IP assegnato al dispositivo locale.

Il team di Oligo Security ha acceso un faro su un problema battezzato “0.0.0.0 Day“. Il nome ha una certa assonanza con “zero-day” proprio per richiamare l’attenzione sulle modalità con cui l’indirizzo 0.0.0.0 è oggi utilizzato in molteplici ambiti.

Perché è necessario rivedere l’utilizzo dell’indirizzo IP 0.0.0.0 e disabilitarne il supporto nei browser Web

Chrome, Chromium e tutti i browser derivati, Firefox e Safari supportano l’utilizzo dell’IP 0.0.0.0. Apparentemente innocuo, l’indirizzo 0.0.0.0 può diventare uno strumento per accedere, senza averne diritto, ai servizi locali, inclusi quelli utilizzati per lo sviluppo, i sistemi operativi e persino le reti interne.

Come raccontiamo nell’articolo citato in apertura, l’uso di 0.0.0.0 nei file HOSTS per bloccare il collegamento verso determinati nomi di dominio è ampiamente noto. Tuttavia, è proprio questa consuetudine ad aver creato un “punto debole”. I browser, infatti, hanno permesso a siti Web pubblici di inviare richieste a 0.0.0.0, aprendo la strada a potenziali attacchi che possono compromettere la sicurezza dei servizi locali.

I tecnici di Oligo spiegano che pagine Web malevoli possono bypassare le misure di sicurezza dei browser e interagire con servizi in esecuzione sulle reti locali degli utenti, potenzialmente permettendo l’accesso non autorizzato e l’esecuzione di codice remoto su servizi locali da parte di attaccanti esterni.

Un problema reale

La radice del problema risiede nelle implementazioni incoerenti dei meccanismi di sicurezza nei diversi browser, unitamente a una mancanza di standardizzazione nel settore. E non è un’ipotesi campata per aria: campagne attive, come quella nota con il nome di ShadowRay, sottolineano l’urgenza di gestire in maniera ragionata le richieste dirette all’IP 0.0.0.0.

Un cluster Ray locale si riferisce a un’installazione di Ray, framework open source per il calcolo distribuito, che viene eseguita su una singola macchina o su un insieme di macchine in una rete locale. Ray è progettato per facilitare lo sviluppo di applicazioni che richiedono calcoli paralleli o distribuiti, come l’elaborazione di grandi quantità di dati, l’addestramento di modelli di machine learning e l’esecuzione di compiti su larga scala.

ShadowRay sfrutta la configurazione del framework per compromettere le installazioni locali ed eseguire codice arbitrario sui sistemi delle vittime.

Altri esempi di attacchi che sfruttano le modalità di gestione dell’IP 0.0.0.0, includono l’uso di Selenium Grid e PyTorch Torchserve. Con entrambi i software è dimostrato che l’esecuzione di codice in modalità remota è possibile, proprio sfruttando richieste inviate verso l’indirizzo 0.0.0.0.

Sviluppatori dei browser al lavoro

In risposta alle segnalazioni di Oligo e al crescente numero di attacchi registrati negli ultimi mesi, i team di sicurezza dei principali browser stanno lavorando per bloccare completamente l’accesso a 0.0.0.0, un cambiamento che sarà implementato nelle future versioni di Chromium, Chrome, Safari e Firefox. Tuttavia, fino a quando questi aggiornamenti non saranno completamente distribuiti, è essenziale che gli sviluppatori adottino misure preventive per proteggere le loro applicazioni locali.

Nonostante gli sforzi di Google volti ad implementare misure di sicurezza come il PNA (Private Network Access), un indirizzo come 0.0.0.0 si sottrae a tali meccanismi in tutti i browser Chromium-based. La situazione è ancora più complessa, ad esempio, con Firefox che non ha mai implementato il PNA e quindi consente l’accesso alle reti private tramite browser.

Come proteggersi dagli attacchi

In attesa degli aggiornamenti per gli utenti dei vari browser, Oligo suggerisce alcuni passaggi da seguire per evitare di correre rischi inutili:

• Implementare l’header PNA: assicurarsi che le applicazioni locali utilizzino l’header PNA per limitare l’accesso alle reti private.
• Verificare l’header HOST: proteggersi contro gli attacchi di DNS rebinding verificando l’header HOST contenuto nelle richieste.
• Non fidarsi delle reti locali: anche se un’applicazione è eseguita in locale, implementare comunque un meccanismo di autorizzazione.
• Utilizzare HTTPS: quando possibile, preferire sempre l’uso di connessioni HTTPS.
• Implementare token CSRF: anche nel caso delle applicazioni locali, i token CSRF forniscono un ulteriore livello di protezione.

Credit immagine in apertura: iStock.com – da-kuk