Il punto centrale: l’esclusività dell’hardware non era l’unico elemento di fiducia

La restrizione ai dispositivi Apple si è rivelata, in questo percorso, soprattutto un confine di prodotto e di implementazione, non un requisito crittografico assoluto legato all’hardware Apple. Quando il client Linux ha fornito credenziali dell’account, identità del dispositivo, certificati, capacità e comportamento di rete attesi dai servizi Apple, i server lo hanno trattato come un altro ricevitore affidabile.

Questo non significa che bastasse aprire un computer Linux e interrogare Find My in modo anonimo. La ricerca mostra piuttosto che un sistema operativo non Apple può riprodurre il comportamento del client previsto dopo aver completato i passaggi di autenticazione e registrazione richiesti da Apple.

Come Linux ha ricreato il flusso di Find My

Il progetto ha collegato diversi componenti normalmente nascosti dell’ecosistema Apple:

1. Autenticazione dell’account. Zerotistic ha utilizzato GrandSlam, il protocollo di accesso agli account Apple già implementato da FindMy.py. Il flusso comprendeva uno scambio Secure Remote Password (SRP) e l’autenticazione a due fattori, con la produzione di identificativi dell’account e di un token temporaneo equivalente a una password.

2. Registrazione del dispositivo. Il client ha generato una richiesta di firma del certificato PKCS#10 contenente una chiave RSA da 2048 bit e una firma SHA-1. La richiesta è stata inviata al vecchio endpoint di registrazione del profilo authenticateDS, che ha restituito un certificato Apple Identity Services.

3. Registrazione in IDS. Grazie al certificato e ai dati identificativi associati, Linux ha potuto registrarsi come dispositivo compatibile con Identity Services, dichiarare i tipi di cifratura supportati, iscriversi ai sottoservizi di messaggistica necessari e ottenere le credenziali di consegna per Apple Push Notification Service, o APNs.

4. Sincronizzazione con Find My. Il client ha riprodotto la sequenza di richieste del servizio Find My People, comprese inizializzazione, operazioni di aggiornamento e una richiesta SubscribeAndFetch con intent: distributeKeys e mode: proactive. Apple ha quindi indicato al dispositivo del contatto consenziente di inviare il materiale aggiornato delle chiavi di localizzazione alla nuova identità registrata, attraverso IDS e APNs.

5. Decrittazione locale. Il messaggio IDS cifrato conteneva materiale relativo alla relazione di condivisione e alle chiavi SearchParty. La libreria open source pypush gestiva il livello push e IDS, mentre FindMy.py interrogava e decifrava i rapporti Find My, ottenendo coordinate, orari e dati sulla precisione della posizione.

Si è trattato quindi di emulazione dei protocolli, non di un certificato Apple falsificato. Le credenziali sono state comunque emesse dai server dopo il completamento del percorso di autenticazione e registrazione dell’account.

Cosa rivela la distribuzione delle chiavi tramite IDS

Il comportamento di SubscribeAndFetch osservato nella dimostrazione suggerisce che Apple può consegnare il materiale corrente delle chiavi di localizzazione a un nuovo dispositivo autorizzato quando la relazione di condivisione esiste già. È una funzione pratica per sostituire un dispositivo o sincronizzare un account: altrimenti, ogni volta che si aggiungesse un nuovo dispositivo, l’utente dovrebbe chiedere a tutti i contatti di interrompere e riattivare la condivisione della posizione.

Il payload analizzato includeva un identificativo della relazione, un indice della chiave, una chiave di annuncio sottoposta ad hashing di 32 byte e una rappresentazione della chiave privata di 85 byte. Nel loro insieme, questi campi indicano che la decrittazione dei rapporti di posizione di Find My dipende da materiale associato alla specifica relazione e alla versione della chiave, che può essere ridistribuito attraverso IDS.

La documentazione pubblica mostra meccanismi di sincronizzazione e rotazione, ma non stabilisce un intervallo universale per la rotazione delle chiavi. È un limite importante: la ricerca illustra come viene consegnato lo stato aggiornato delle chiavi, non fornisce una specifica pubblica completa del calendario di gestione delle chiavi di Apple.

Cosa poteva e non poteva fare il client Linux

Il client testato era volutamente circoscritto. Poteva leggere una condivisione della posizione già accettata dall’account Apple del ricercatore e processare i dati localmente. Anche la logica delle geofence, cioè le notifiche associate all’ingresso o all’uscita da determinate aree, veniva eseguita sul computer Linux e non sui server Apple.

Secondo la documentazione pubblicata, il client non poteva:

• inviare nuovi inviti alla condivisione della posizione;
• modificare i permessi di condivisione esistenti;
• aggiungere membri alla famiglia;
• creare geofence gestite da Apple;
• impartire comandi ai dispositivi.

Il risultato va quindi interpretato come una scoperta di interoperabilità e di confine della fiducia, non come un exploit per seguire da remoto qualunque persona. Il rischio più realistico riguarda la compromissione dell’account o di un dispositivo considerato affidabile: se un aggressore ottenesse il controllo di un Apple Account o riuscisse a registrarvi un dispositivo non autorizzato, potrebbe potenzialmente esporre le condivisioni già disponibili per quell’account.

La differenza rispetto alla ricerca nRootTag del 2025

La dimostrazione di Zerotistic e nRootTag riguardano parti diverse di Find My e descrivono minacce differenti.

Zerotistic si è concentrato su Find My People. Il lavoro ha riprodotto il lato ricevente di una relazione di condivisione già esistente e autorizzata. L’account e il dispositivo dovevano essere accettati da Apple, mentre la posizione della persona doveva essere già condivisa con quell’account.

nRootTag riguardava invece Find My Network e la ricerca offline. I ricercatori hanno riferito che il servizio Apple accettava più tipologie di indirizzi Bluetooth rispetto a quelle previste. Questa debolezza poteva consentire di far comportare un computer dotato di Bluetooth come un dispositivo di tracciamento simile a un AirTag, usando i dispositivi Apple nelle vicinanze per inoltrare la posizione senza che il proprietario del dispositivo bersaglio ne fosse consapevole.

In sintesi, il progetto di Zerotistic riceveva dati che un account era già autorizzato a vedere; nRootTag cercava di creare un meccanismo di tracciamento non autorizzato. Confondere i due casi farebbe apparire la dimostrazione Linux molto più potente di quanto consentano le prove disponibili.

L’obiettivo iniziale e i tempi del progetto

La motivazione dichiarata era legata a un’automazione basata sul consenso. Un amico che condivideva già la propria posizione aveva accettato che un sistema Linux mantenesse geofence locali e inviasse notifiche su Discord quando la persona arrivava in luoghi specifici o li lasciava.

Inizialmente Zerotistic pensava che sarebbe bastata una richiesta web autenticata e stimava circa una serata di lavoro. Il reverse engineering si è però ampliato molto oltre le aspettative iniziali. Le fonti disponibili non stabiliscono una durata complessiva precisa per il progetto finito, quindi indicare un numero più esatto sarebbe speculativo.

La risposta di Apple

Le fonti citate confermano la dimostrazione, ma non riportano una dichiarazione pubblica verificata di Apple su questa specifica implementazione Linux di Find My People, né una correzione confermata o un esito noto di un programma bug bounty.

La lezione principale resta comunque chiara: limitare una funzione all’hardware Apple non significa automaticamente che l’hardware sia il vero confine di sicurezza. Se la fiducia lato server dipende soprattutto da credenziali, certificati, capacità dichiarate e comportamento del protocollo, un client sufficientemente compatibile su un altro sistema operativo può oltrepassare il confine di prodotto, restando però vincolato ai permessi dell’account e alle chiavi crittografiche che riesce a ottenere legittimamente.

Il punto centrale: l’esclusività dell’hardware non era l’unico elemento di fiducia

La restrizione ai dispositivi Apple si è rivelata, in questo percorso, soprattutto un confine di prodotto e di implementazione, non un requisito crittografico assoluto legato all’hardware Apple. Quando il client Linux ha fornito credenziali dell’account, identità del dispositivo, certificati, capacità e comportamento di rete attesi dai servizi Apple, i server lo hanno trattato come un altro ricevitore affidabile.

Questo non significa che bastasse aprire un computer Linux e interrogare Find My in modo anonimo. La ricerca mostra piuttosto che un sistema operativo non Apple può riprodurre il comportamento del client previsto dopo aver completato i passaggi di autenticazione e registrazione richiesti da Apple.

Come Linux ha ricreato il flusso di Find My

Il progetto ha collegato diversi componenti normalmente nascosti dell’ecosistema Apple:

1. Autenticazione dell’account. Zerotistic ha utilizzato GrandSlam, il protocollo di accesso agli account Apple già implementato da FindMy.py. Il flusso comprendeva uno scambio Secure Remote Password (SRP) e l’autenticazione a due fattori, con la produzione di identificativi dell’account e di un token temporaneo equivalente a una password.

2. Registrazione del dispositivo. Il client ha generato una richiesta di firma del certificato PKCS#10 contenente una chiave RSA da 2048 bit e una firma SHA-1. La richiesta è stata inviata al vecchio endpoint di registrazione del profilo authenticateDS, che ha restituito un certificato Apple Identity Services.

3. Registrazione in IDS. Grazie al certificato e ai dati identificativi associati, Linux ha potuto registrarsi come dispositivo compatibile con Identity Services, dichiarare i tipi di cifratura supportati, iscriversi ai sottoservizi di messaggistica necessari e ottenere le credenziali di consegna per Apple Push Notification Service, o APNs.

4. Sincronizzazione con Find My. Il client ha riprodotto la sequenza di richieste del servizio Find My People, comprese inizializzazione, operazioni di aggiornamento e una richiesta SubscribeAndFetch con intent: distributeKeys e mode: proactive. Apple ha quindi indicato al dispositivo del contatto consenziente di inviare il materiale aggiornato delle chiavi di localizzazione alla nuova identità registrata, attraverso IDS e APNs.

5. Decrittazione locale. Il messaggio IDS cifrato conteneva materiale relativo alla relazione di condivisione e alle chiavi SearchParty. La libreria open source pypush gestiva il livello push e IDS, mentre FindMy.py interrogava e decifrava i rapporti Find My, ottenendo coordinate, orari e dati sulla precisione della posizione.

Si è trattato quindi di emulazione dei protocolli, non di un certificato Apple falsificato. Le credenziali sono state comunque emesse dai server dopo il completamento del percorso di autenticazione e registrazione dell’account.

Cosa rivela la distribuzione delle chiavi tramite IDS

Il comportamento di SubscribeAndFetch osservato nella dimostrazione suggerisce che Apple può consegnare il materiale corrente delle chiavi di localizzazione a un nuovo dispositivo autorizzato quando la relazione di condivisione esiste già. È una funzione pratica per sostituire un dispositivo o sincronizzare un account: altrimenti, ogni volta che si aggiungesse un nuovo dispositivo, l’utente dovrebbe chiedere a tutti i contatti di interrompere e riattivare la condivisione della posizione.

Il payload analizzato includeva un identificativo della relazione, un indice della chiave, una chiave di annuncio sottoposta ad hashing di 32 byte e una rappresentazione della chiave privata di 85 byte. Nel loro insieme, questi campi indicano che la decrittazione dei rapporti di posizione di Find My dipende da materiale associato alla specifica relazione e alla versione della chiave, che può essere ridistribuito attraverso IDS.

La documentazione pubblica mostra meccanismi di sincronizzazione e rotazione, ma non stabilisce un intervallo universale per la rotazione delle chiavi. È un limite importante: la ricerca illustra come viene consegnato lo stato aggiornato delle chiavi, non fornisce una specifica pubblica completa del calendario di gestione delle chiavi di Apple.

Cosa poteva e non poteva fare il client Linux

Il client testato era volutamente circoscritto. Poteva leggere una condivisione della posizione già accettata dall’account Apple del ricercatore e processare i dati localmente. Anche la logica delle geofence, cioè le notifiche associate all’ingresso o all’uscita da determinate aree, veniva eseguita sul computer Linux e non sui server Apple.

Secondo la documentazione pubblicata, il client non poteva:

• inviare nuovi inviti alla condivisione della posizione;
• modificare i permessi di condivisione esistenti;
• aggiungere membri alla famiglia;
• creare geofence gestite da Apple;
• impartire comandi ai dispositivi.

Il risultato va quindi interpretato come una scoperta di interoperabilità e di confine della fiducia, non come un exploit per seguire da remoto qualunque persona. Il rischio più realistico riguarda la compromissione dell’account o di un dispositivo considerato affidabile: se un aggressore ottenesse il controllo di un Apple Account o riuscisse a registrarvi un dispositivo non autorizzato, potrebbe potenzialmente esporre le condivisioni già disponibili per quell’account.

La differenza rispetto alla ricerca nRootTag del 2025

La dimostrazione di Zerotistic e nRootTag riguardano parti diverse di Find My e descrivono minacce differenti.

Zerotistic si è concentrato su Find My People. Il lavoro ha riprodotto il lato ricevente di una relazione di condivisione già esistente e autorizzata. L’account e il dispositivo dovevano essere accettati da Apple, mentre la posizione della persona doveva essere già condivisa con quell’account.

nRootTag riguardava invece Find My Network e la ricerca offline. I ricercatori hanno riferito che il servizio Apple accettava più tipologie di indirizzi Bluetooth rispetto a quelle previste. Questa debolezza poteva consentire di far comportare un computer dotato di Bluetooth come un dispositivo di tracciamento simile a un AirTag, usando i dispositivi Apple nelle vicinanze per inoltrare la posizione senza che il proprietario del dispositivo bersaglio ne fosse consapevole.

In sintesi, il progetto di Zerotistic riceveva dati che un account era già autorizzato a vedere; nRootTag cercava di creare un meccanismo di tracciamento non autorizzato. Confondere i due casi farebbe apparire la dimostrazione Linux molto più potente di quanto consentano le prove disponibili.

L’obiettivo iniziale e i tempi del progetto

La motivazione dichiarata era legata a un’automazione basata sul consenso. Un amico che condivideva già la propria posizione aveva accettato che un sistema Linux mantenesse geofence locali e inviasse notifiche su Discord quando la persona arrivava in luoghi specifici o li lasciava.

Inizialmente Zerotistic pensava che sarebbe bastata una richiesta web autenticata e stimava circa una serata di lavoro. Il reverse engineering si è però ampliato molto oltre le aspettative iniziali. Le fonti disponibili non stabiliscono una durata complessiva precisa per il progetto finito, quindi indicare un numero più esatto sarebbe speculativo.

La risposta di Apple

Le fonti citate confermano la dimostrazione, ma non riportano una dichiarazione pubblica verificata di Apple su questa specifica implementazione Linux di Find My People, né una correzione confermata o un esito noto di un programma bug bounty.

La lezione principale resta comunque chiara: limitare una funzione all’hardware Apple non significa automaticamente che l’hardware sia il vero confine di sicurezza. Se la fiducia lato server dipende soprattutto da credenziali, certificati, capacità dichiarate e comportamento del protocollo, un client sufficientemente compatibile su un altro sistema operativo può oltrepassare il confine di prodotto, restando però vincolato ai permessi dell’account e alle chiavi crittografiche che riesce a ottenere legittimamente.