Android rivela il vostro IP reale oltre la VPN, e Google non lo correggerà

Android ha un interruttore chiamato «Blocca connessioni senza VPN». Attivatelo insieme alla VPN sempre attiva e il sistema promette che nulla lascia il dispositivo fuori dal tunnel. Due scoperte indipendenti di quest'anno mostrano che qualsiasi app comune passa accanto a quell'interruttore e consegna il vostro indirizzo IP reale a un server di sua scelta. Google ha chiuso entrambe le segnalazioni senza riparare niente.

Che cosa dovrebbe garantire quell'interruttore

Quando su Android si alza una VPN, il sistema riscrive le regole di instradamento perché le app coperte raggiungano la rete soltanto attraverso di essa. Ogni socket porta un contrassegno che dice al kernel a quale rete appartiene, e se un'app prova a legare un socket direttamente all'interfaccia Wi-Fi fisica il controllo fallisce e la chiamata restituisce un errore di permessi. È questa la meccanica dietro l'impostazione, e funziona.

Funziona per le app. I socket dei componenti di sistema stanno sotto una soglia chiamata FIRST_APPLICATION_UID e vengono etichettati come di sistema, quindi raggiungono qualunque rete a prescindere da ciò che fa una VPN nello spazio utente. Il sistema deve poter parlare con la rete in ogni circostanza, perciò l'eccezione in sé è ragionevole. Diventa un problema nel momento in cui un'app comune riesce a convincere un processo di sistema a spedire un pacchetto per suo conto.

Falla numero uno: il saluto educato

Android 16 ha introdotto una funzione per chiudere in modo pulito le connessioni QUIC. Se il socket di un'app muore all'improvviso, il server dall'altra parte resta con una connessione mezza aperta fino alla scadenza, così ora il sistema consente di registrare in anticipo un pacchetto di commiato che consegnerà lui. Il ricercatore che ha trovato la falla, che pubblica come lowlevel, ha chiamato il risultato piccolo cannone UDP.

1. L'app chiama un metodo del servizio di rete e gli consegna un socket UDP e un blocco arbitrario di byte. Su quella chiamata non c'è alcun controllo dei permessi, né nel metodo, né nella descrizione dell'interfaccia, né nella politica di sicurezza.
2. Il sistema annota chi ha chiamato, la rete e gli indirizzi e le porte di origine e destinazione del socket.
3. L'app termina. Il kernel segnala il socket come distrutto.
4. Il processo di sistema apre un socket nuovo sulla rete Wi-Fi fisica, lo collega alla destinazione annotata e invia i byte annotati. La VPN quel pacchetto non lo vede mai, e la destinazione vede l'indirizzo reale del dispositivo.

Il ricercatore ha segnalato il problema tramite il programma di ricompense di Android. La segnalazione è stata chiusa come Won't Fix (Infeasible), sostenendo che la cosa non rientra nel modello delle minacce. Mullvad, che di solito non scrive dei bug altrui, ha pubblicato un avviso a maggio e ha ripresentato il caso sul tracker pubblico; la voce è stata poi contrassegnata come non accessibile senza spiegazioni. GrapheneOS ha rilasciato una correzione che spegne l'ottimizzazione.

Falla numero due: il keepalive lo manda il chip Wi-Fi al posto vostro

La seconda scoperta, pubblicata il 29 luglio da Armin Šupuk e ripresa da Mullvad il 10 settembre, entra nella stessa stanza da un'altra porta. Android espone un'interfaccia pubblica per tenere viva una traduzione NAT: un'app chiede al sistema di emettere periodicamente un piccolo pacchetto UDP perché una connessione che passa dal router di casa non cada. Per efficienza il compito scende al chip Wi-Fi o a quello cellulare, che i pacchetti li spara da sé.

Il framework accetta la richiesta senza verificare che il chiamante possieda davvero la risorsa indicata e senza chiedersi se su di lui valga il blocco della VPN. Da lì il keepalive nasce nell'hardware di rete, sotto il livello dove vivono le regole del tunnel. Pacchetti di formato fisso sulla porta UDP 4500 arrivano all'indirizzo scelto dall'app, portandosi dietro l'IP reale.

Il lavoro ricostruisce un modello di fiducia che si è sfaldato nel tempo. La chiamata era nata come interfaccia privilegiata che riceveva un descrittore di file grezzo, ha guadagnato un punto d'ingresso pubblico, poi una convalida della risorsa, e l'ha persa di nuovo in un ripristino. Quel che resta lascia passare la richiesta senza pretendere alcuna prova di proprietà.

La nota dello stesso segnalatore sul tracker di GrapheneOS è più stretta del titolo del lavoro: sui dispositivi Pixel funziona via Wi-Fi e quasi mai su IPv6. In compenso è ostinata. La perdita continua con l'app in secondo piano, a schermo bloccato, in modalità Doze, in risparmio energetico e sotto il congelamento dei processi, e sopravvive all'arresto forzato dell'app.

Che cosa esce davvero

Non i vostri messaggi. Entrambe le falle sono canali stretti: l'app decide dove va il pacchetto e, nel caso di QUIC, che cosa contengono pochi byte. Quello che l'altro capo impara è che un dispositivo preciso con un preciso IP pubblico esiste ed è online proprio adesso. Per un'app che sa già chi siete, quello è l'anello mancante fra un account e una posizione, cioè esattamente ciò che la VPN doveva impedire.

Perché continua a succedere

Le due falle nascono dalla stessa scelta di progetto: funzioni di comodo che lasciano a un processo di sistema il compito di agire per conto di un'app, scritte senza chiedersi se quell'app in quel momento possa uscire in rete per conto proprio. Il controllo del blocco filtra le identità delle app, quindi tutto ciò che gira con identità di sistema gli sfugge.

E l'elenco non si ferma a due. Nella discussione su GrapheneOS un manutentore ha osservato che il progetto ha trovato e corretto per conto proprio almeno altre dieci perdite, e che quelle che avvengono senza un'app che tenti deliberatamente di uscire hanno la precedenza su queste due. Lo stesso manutentore è stato netto sugli incentivi: Google per le perdite di VPN non paga, e segnalarle serve a lasciarne traccia, non ad aspettarsi una correzione.

Che cosa potete fare

Che cosa cambia nella scelta di una VPN

Conviene essere precisi su di chi sia la colpa, perché la pubblicità intorno alla vicenda precisa non sarà. Nessun servizio VPN può correggere queste falle e nessuno le ha create: i pacchetti non arrivano mai al livello applicativo in cui lavora un client VPN. Su cosa si può ragionevolmente giudicare un fornitore, qui, è se abbia avvisato i propri utenti. Se state scegliendo un'app per il telefono, la nostra guida alle VPN per Android riguarda ciò che l'app controlla davvero, cioè tutto quello che sta sopra questo livello.