iCloud Private Relay può esporre l’IP reale durante l’uso di passkey

Se usi iCloud Private Relay per proteggere la tua privacy, è importante sapere che non copre tutti gli scenari. In alcuni casi, soprattutto durante l’uso delle passkey, un sito potrebbe vedere il tuo indirizzo IP reale invece di quello mascherato. La soluzione più pratica, nell’immediato, è aggiornare i dispositivi Apple, fare attenzione ai siti che chiedono l’accesso con passkey e usare strumenti di anonimato più completi quando serve davvero privacy forte.

Questa situazione non indica che il dispositivo sia compromesso o che l’account sia stato rubato. Il problema riguarda soprattutto una fuga di informazioni, cioè la possibilità che un sito raccolga un dato sensibile che l’utente credeva nascosto. Un indirizzo IP, infatti, può rivelare il provider di rete e una posizione geografica approssimativa, oltre a facilitare profilazione e tracciamento.

Cosa sta succedendo

Alcune falle nel motore WebKit, usato su iPhone e iPad per i browser e varie funzioni web, possono consentire a un sito di vedere l’IP reale dell’utente anche quando è attivo iCloud Private Relay. Il problema emerge quando un sito supporta, o dichiara di supportare, le passkey.

Durante questo flusso, il dispositivo può effettuare una richiesta di rete separata che non passa dal percorso protetto di Private Relay. In quel momento, il server di destinazione riceve l’indirizzo IP reale dell’utente invece di quello filtrato dal servizio di Apple.

In pratica, l’utente può vedere solo una normale richiesta di autenticazione con passkey, mentre in background avviene una connessione che lascia trapelare un’informazione utile a identificare la sessione.

Perché è importante per la privacy

iCloud Private Relay è progettato per nascondere l’IP dell’abbonato iCloud+ durante la navigazione in Safari, ma non è un VPN completo a livello di dispositivo. Questo significa che non tutte le applicazioni e non tutti i processi usano lo stesso canale protetto.

Il punto critico è che una protezione pensata per la navigazione può perdere efficacia quando una parte del sistema operativo gestisce una richiesta fuori dal normale percorso del browser. È proprio in questi casi che un sito malevolo potrebbe sfruttare il comportamento del sistema per registrare gli indirizzi IP dei visitatori.

Un leak di questo tipo non è meno rilevante solo perché non installa malware o non richiede una password. Per molti attaccanti, sapere da dove proviene una connessione è già sufficiente per restringere il campo e migliorare il tracciamento.

Come può essere sfruttato

Un operatore malevolo può costruire una pagina che sembra legittima e che invita l’utente a usare una passkey. Se il flusso genera una richiesta di rete separata, il sito può registrare l’IP reale senza che l’utente se ne accorga.

Questo rende il problema particolarmente delicato perché:

• non richiede il download di file;
• non richiede l’apertura di allegati;
• non richiede la condivisione di una password;
• può attivarsi con una semplice interazione web.

Per questo motivo, i controlli sulla privacy non vanno valutati solo per la loro presenza, ma anche per i loro limiti operativi.

Impatto su navigazione anonima e Tor su iPhone

Lo stesso comportamento di WebKit può influire anche su applicazioni iOS che usano la rete Tor, come OnionBrowser. Poiché i browser su iOS devono utilizzare WebKit, un’app può ereditare restrizioni e comportamenti del motore di rendering anche quando adotta una propria strategia di privacy.

Secondo quanto emerso, alcune delle perdite di dati dipendono da componenti sotto il controllo di Apple, mentre almeno un altro caso non colpisce il comportamento predefinito dell’app coinvolta. Questo dettaglio è importante perché mostra che la superficie del problema non riguarda soltanto un singolo browser, ma l’architettura web di iOS nel suo insieme.

Il browser ufficiale Tor Browser del progetto Tor non risulta coinvolto in questo specifico problema e resta la scelta consigliata quando l’obiettivo è ottenere anonimato di livello Tor su piattaforme supportate.

Cosa dovrebbero fare gli utenti

Per la maggior parte delle persone, la misura più utile è semplice: installare subito gli aggiornamenti Apple non appena disponibili. Gli aggiornamenti possono correggere comportamenti di WebKit e ridurre la probabilità di esposizione dell’IP reale.

Inoltre, conviene:

• diffidare dei siti sconosciuti che richiedono passkey senza una chiara necessità;
• controllare con attenzione le richieste di autenticazione;
• non considerare Private Relay come sostituto di uno strumento di anonimato completo;
• usare Tor Browser ufficiale quando serve un livello di protezione più elevato;
• limitare l’uso di servizi sensibili su reti e siti poco affidabili.

Se la privacy è un requisito essenziale, trattare un indirizzo IP come un dato innocuo è un errore. Questo valore può collegare sessioni diverse, suggerire la zona geografica approssimativa e alimentare sistemi di profilazione.

Cosa dovrebbero fare aziende e team di sicurezza

Le organizzazioni non dovrebbero assumere che Private Relay impedisca ogni forma di logging basato sull’IP quando il traffico parte da Safari o da altri flussi web correlati. Una valutazione corretta della privacy deve considerare anche i percorsi laterali del sistema operativo, non solo il traffico browser standard.

I team di sicurezza dovrebbero inoltre:

• rivedere i flussi di autenticazione basati su passkey;
• verificare come vengono gestiti i dati di rete nelle pagine di login;
• evitare di usare l’IP come segnale identitario affidabile senza ulteriori controlli;
• aggiornare le comunicazioni interne sulle reali capacità di Private Relay;
• distinguere tra protezione della navigazione e anonimato completo del dispositivo.

Dal punto di vista operativo, il problema è soprattutto una lezione di architettura: una funzione di privacy può funzionare bene nel suo perimetro, ma non coprire tutti i percorsi laterali generati da autenticazione, sistema operativo e browser engine.

Perché questo caso è diverso da un attacco più grave

Non si tratta di un exploit che installa codice, compromette l’iPhone o prende controllo dell’account. La questione segnalata riguarda principalmente la perdita di anonimato.

Questo non la rende trascurabile. In ambito privacy, un leak dell’indirizzo IP può bastare per:

• collegare attività online alla stessa persona o rete;
• facilitare campagne di tracciamento;
• supportare attacchi mirati;
• aiutare un aggressore a confermare una posizione approssimativa.

Per utenti esposti a stalking, frodi, monitoraggio pubblicitario aggressivo o minacce mirate, anche una sola informazione aggiuntiva può fare la differenza.

Come leggere correttamente i limiti di Private Relay

Private Relay è utile, ma va interpretato nel modo giusto. È una protezione per una parte della navigazione, non un sistema universale che rende invisibili tutti i dati di rete del dispositivo.

La differenza è fondamentale: una persona può credere di navigare in modo protetto mentre, in realtà, alcune richieste escono da percorsi diversi e lasciano tracce identificabili. Questo è il motivo per cui la sicurezza informatica richiede sempre una valutazione basata su scenari reali e non solo sulle etichette commerciali.

Technical Deep Dive

Il comportamento descritto è coerente con una separazione tra il traffico gestito da Safari e le richieste generate da componenti di sistema chiamati durante il flusso di autenticazione WebAuthn. In questi casi, il browser può avviare un’interazione con il servizio credenziali del sistema operativo, che a sua volta effettua una richiesta di rete non instradata attraverso il proxy di Private Relay.

Dal punto di vista tecnico, il punto cruciale non è la compromissione del browser, ma il fatto che il percorso di rete usato dal sottosistema di autenticazione non eredita automaticamente lo stesso tunnel di privacy della sessione web. Questo crea una discrepanza tra l’aspettativa dell’utente e il comportamento effettivo del sistema.

WebKit è un elemento centrale dell’ecosistema iOS proprio perché molte app browser su iPhone sono vincolate a usarlo. Di conseguenza, un limite del motore può avere effetti più ampi di una vulnerabilità isolata in una singola app. Anche quando l’app ha una propria interfaccia o un proprio branding, il livello di rendering e diversi comportamenti web restano dipendenti da WebKit.

Nel caso delle passkey, il rischio deriva dal fatto che l’autenticazione è progettata per essere semplice e quasi trasparente. Questa comodità può però nascondere richieste di rete secondarie, rendendo più difficile per l’utente capire quando un flusso esce dal perimetro protetto. Per i ricercatori di sicurezza, questo è un esempio tipico di data leakage causato da confini architetturali non allineati.

Per gli ambienti ad alta sensibilità, le contromisure più robuste includono test specifici sui flussi di autenticazione, revisione delle dipendenze dal motore web, segmentazione dei dati di telemetria e adozione di strumenti di anonimato che operino a livello più ampio del solo browser. In altre parole, se la minaccia è la correlazione dell’identità di rete, la difesa deve coprire tutti i punti in cui l’identità può riemergere, non solo la pagina visualizzata dall’utente.

Fonte: https://cybersecuritynews.com/apple-icloud-private-relay/