Identity Lookup Service

Indice dei contenuti

• La struttura del record di autenticazione
• idstatuscache.plist
• Percorsi
• Il dubbio "Cellebrite"
• Conclusioni
• iLEAPP

Introduzione

Nel 2019 la Cellebrite pubblica l'articolo How iOS Properties Files Can Confirm a Suspect’s Contacts Even If Deleted dove in sintesi spiega l'importanza di trovare un archivio affidabile delle comunicazioni tra le parti che sia permanente e legittimo da consultare durante le indagini e in tribunale.

L'identificazione dell'elenco dei contatti sul telefono cellulare di un sospettato è sempre stata una sfida, poiché la deliberata cancellazione delle informazioni da parte del sospetto porta alla necessità di trovare un modo corretto dal punto di vista forense per recuperale. 

La ricercatrice della Cellebrite Izhar Carmel ha scoperto che il file com.apple.identityservices.idstatuscache.plist presente nel percorso "/private/var/mobile/Library/Preferences/" è la cache che contiene i record delle autenticazioni degli ID Apple.

Un utente Apple che utilizza iMessage o FaceTime, quando tenta di contattare un destinatario, viene interrogato l'Enterprise Shared Services, il server delle autenticazioni di Apple per la verifica dell'identità. A fine convalida, se è la prima volta che si cerca il destinatario, viene creato un nuovo record (dizionario) con l'ID del primo tentativo di contatto come numero di telefono (es. tel:+14693560xxx) o come indirizzo email (es. mailto:joshuahickmanxxx@gmail.com) e la data dell'evento stesso nel dizionario associato al servizio utilizzato (es. com.apple.madrid).

Non è necessario che l'operazione per esempio dell'invio del messaggio venga portata a termine; il nuovo record viene comunque registrato nella cache. Questi record non vengono sovrascritti dalle successive ricerche o selezione dello stesso destinatario e per la stessa applicazione.  

Successivamente nel 2020 pubblica How to Use the Identity Lookup Service in Cellebrite Physical Analyzer, una demo video con l'analisi dell'artefatto. 

Identity Lookup Service (Servizio di Ricerca dell'Identità) è il servizio di Apple che gestisce l'autenticazione dei processi. Questi dati confermano solo che è avvenuta l'autenticazione del destinatario e non danno nessuna informazione utile per quanto riguarda l'avvenuto invio di un messaggio o l'avvio di una conversazione. E' solo un indizio che indica che qualcosa è successo, ma per dimostrare che qualcosa è realmente avvenuto, bisogna tracciarlo altrove.

Per lo studio di questo artefatto è stata utilizzata una delle immagini pubbliche di iOS note nel settore e in particolare quella di Josh Hickman iOS 14.3 disponibile su MediaFire e i dati estratti dal mio iPhone 8 con iOS 16.7.8.

La struttura del record di autenticazione

Per la visualizzazione ho usato dfDataViewer, il mio visualizzatore di (B)Plist, JSON(B), (B)XML, ASN.1, Protobuf, LevelDB, etc. ancora in fase di sviluppo e non pubblico.

com.apple.identityservices.idstatuscache.plist

Il servizio com.apple.ess: (FaceTime)

• tel:+19192895xxx: (numero di telefono)
• IDStatus: 2 (1=iDevice, 2=Not iDevice);
• LookupDate: 635363625.519218 (timestamp della verifica dell'identità come real nel formato MAC Absolute Time 18 febbraio 2021 17:53:45);
• ...

Il servizio com.apple.madrid: (iMessage)

• tel:+14693560xxx: (numero di telefono)
• IDStatus: 2 (Not iDevice);
• LookupDate: 635433067.361745 (19 febbraio 2021 13:11:07);
• ...

com.apple.ess e com.apple.madrid sono gli identificatori dei servizi. E' noto a tutti che com.apple.madrid è l'identificatore del servizio iMessage e che com.apple.private.alloy.facetime.video è quello di FaceTime Video; ma come è possibile associare questi servizi a un nome da visualizzare? La risposta è nella directory "/System/Library/IdentityServices/ServiceDefinitions/" che contiene un serie di file Plist con le definizioni dei servizi.

com.apple.iMessage.plist

Queste sono le chiavi rappresentative per una corretta mappatura degli identificatori (Identifier e LegacyIdentifier) con il nome da visualizzare (DisplayName) oppure con il nome del servizio (ServiceName):

• DisplayName: iMessage (nome visualizzato "applicazione");
• Identifier: com.apple.madrid (identificatore univoco);
• LegacyIdentifier: com.apple.iMessage (identificatore univoco nelle vecchie versioni);
• ServiceName: Messenger (nome del servizio).

Quindi da questo file si ottengono due associazioni (id = valore):

1. com.apple.madrid = iMessage
2. com.apple.iMessage = iMessage

Altri esempi di associazioni:

• com.apple.private.ac = Calling
• com.apple.ess = FaceTime
• com.apple.private.alloy.sms = SMSRelay
• com.apple.private.alloy.maps = Maps
• com.apple.private.alloy.nearby = Nearby

idstatuscache.plist

A partire dalla versione iOS 14.7.0 il file com.apple.identityservices.idstatuscache.plist è vuoto o assente. La mia attenzione è stata catturata durante l'utilizzo di FaceTime, quando digitando per la prima volta i destinatari, sono stati autenticati in Blu per i dispositivi Apple e in Verde per gli altri, con un tempo superiore rispetto alla successiva ricerca degli stessi. L'effetto è visibile quando per esempio si digita un solo carattere comune a tanti contatti es. "a" e i colori cambiano di pari passo con il processo di autenticazione. Quindi mi son detto: dov'è questa cache con i record delle autenticazioni?

Rimboccandomi le maniche ed eseguendo qualche ricerca sul contenuto dei file è saltato fuori un file dal nome interessante idstatuscache.plist nel percorso  "/private/var/mobile/Library/IdentityServices/". Una verifica del Plist ha confermato che ha la stessa struttura del file com.apple.identityservices.idstatuscache.plist ed è presente solo nelle nuove versioni iOS. Bene! sembra di essere tornati alla vecchia situazione, ma è realmente così?

Per rispondere a questa domanda ho eseguito un po' di test su FaceTime e al fine di discriminare gli eventi in modo grossolano, ogni test è stato svolto a step di 1 minuto di distanza con riferimento all'ora sullo schermo del dispositivo.

Tutti i test consistono nella ricerca del destinatario, nella selezione/conferma un minuto dopo ed eventualmente un altro minuto nell'avvio della videochiamata.

Per facilitare l'estrazione e una prima analisi del file Plist ho utilizzato ArtEx di Ian Whiffin in modalità Live Connection: l'analisi finale con dfDataViewer.

Premessa: l'archivio iniziale idstatuscache.plist è allo stato di fabbrica e la ricerca di un destinatario per la prima volta nei test è proprio il primo tentativo di contatto.

Test 1

Questa prima sequenza di test è composta solo da "ricerca e selezione" del contatto iPhone (+393485495xxx): due volte al giorno e per due giorni consecutivi.

La prima richiesta di autenticazione del giorno viene registrata normalmente e la successiva nello stesso giorno non modifica il record. Nel secondo giorno viene aggiornato il record come prima autenticazione giornaliera e lo stato del record non viene modificato per la successiva nella stessa giornata.

Test 2

Il secondo test è molto simile al primo: solo un tentativo al giorno con il contatto iPhone (+393396472xxx).

Il secondo giorno aggiorna i timestamp come nel caso precedente.

Test 3

Il primo test è una videochiamata "senza risposta" con l'altro mio iPhone SE 2020 (django.faiola@xxx.com); il secondo test è una videochiamata "con risposta". Nel secondo giorno, il terzo test, di nuovo una videochiamata "senza risposta".

Anche in questo caso i timestamp sono aggiornati a quelli della prima autenticazione del secondo giorno.

Test 4

Questo è sempre un test di "ricerca e selezione" del contatto Android (+393381956xxx).

A differenza del Test 1 per il contatto iPhone, nel caso di Android viene aggiornato solo il timestamp dell'identificatore com.apple.private.alloy.facetime.multi, il servizio per la gestione delle chiamate in multiutente di FaceTime.

Test 5

Questo test è il più importante: dimostra la persistenza del record nella cache del contatto (+393489209xxx) dopo averlo eliminato dalla rubrica.

Attenzione! se il contatto viene di nuovo inserito in rubrica e poi autenticato in data successiva al 30 luglio 2024, il timestamp viene aggiornato come nei casi precedenti.

Ulteriore conferma della persistenza del record dopo qualche giorno dall'eliminazione del contatto.

Il record resiste alla eliminazione del contatto.

Test vari

Altri test non esaustivi sono stati svolti e non riportati sopra ma confermano quanto già esposto. Dalla rubrica per esempio, solita procedura test di ricerca e selezione di un contatto iDevice ho riscontrato in corrispondenza della selezione (visualizzazione della scheda) un aggiornamento del timestamp di FaceTime (com.apple.ess).

La verifica dell'identità non si limita solo a iMessage o FaceTime, ma viene eseguita anche per gli altri servizi, per es. FindMyFriend.

Ulteriori test possono mettere in luce situazioni particolari ma la sostanza è che i timestamp non rappresentano più il primo contatto come nel caso di com.apple.identityservices.idstatuscache.plist.

Percorsi

• /System/Library/IdentityServices/ServiceDefinitions/*.plist:  definizioni dei servizi;
• /private/var/mobile/Library/Preferences/com.apple.identityservices.idstatuscache.plist: cache dei record delle autenticazioni fino alla versione iOS 14.6.0 (incluso anche nel Backup);
• /private/var/mobile/Library/IdentityServices/idstatuscache.plist: cache dei record delle autenticazioni a partire dalla versione iOS 14.7.0 (non incluso nel Backup).

Il dubbio "Cellebrite"

Onestamente mi è sorto un dubbio: come mai questo comportamento così diverso se tutto sembra essere uguale? Inoltre i timestamp ottenuti dalla vecchia versione della cache non sembrano essere i più datati, da primo contatto, oserei quasi dire da ricerca recente. 

Non ho modo di fare qualche test con la vecchia cache quella precedente alla versione iOS 14.7.0, quindi ho pensato di dare giusto un'occhiata veloce ai dati estratti con iLEAPP dall'immagine di Josh Hickman iOS 14.3.

Per esempio il contatto (919) 888-7xxx This Is DFIR Two (quello con più messaggi scambiati in iMessage) ha da Identity Lookup Service il timestamp 2021-02-19 19:16:47.

iMessage: 

• 2021-02-15 18:14:29 primo messaggio in uscita "I have now switched to iPhone.";
• altri messaggi;
• 2021-02-15 18:33:17 ultimo messaggio in uscita "IMG_0018.JPG";
• 2021-02-15 18:34:53 ultimo messaggio (letto) in entrata "Very nice, and very true.";
• 2021-02-19 19:16:46 primo e ultimo messaggio (letto) in entrata "Memes 3.zip";
• 2021-02-19 19:49:34 primo e ultimo messaggio in uscita "iOS_Bug_Reporting_for_Forensic_Purposes_1.2.pdf".

InteractionC:

• 2021-02-15 18:04:46 prima interazione in uscita;
• altre interazioni;
• 2021-02-19 19:16:46 ultima interazione in entrata.

Ovvio che questo è come dire un controllo "superficiale", ma la domanda è: possibile che in tutte queste interazioni con il contatto quella riportata da ILS è temporalmente compatibile con l'ultima (la prima del giorno 19)?

Conclusioni

Quello che si può affermare è:

1. Eliminando il contatto dalla rubrica il record nella cache persiste;
2. I timestamp non sono quelli del primo contatto (caso limite), ma quelli del primo contatto del giorno dell'ultima richiesta di verifica dell'autenticazione;
3. Il contatto alla data/ora di ricerca di sicuro è presente nel dispositivo.

In conclusione, nella vecchia cache lo scopo dell'analisi era quello di avere un indizio di un potenziale contatto: bene, anche in questo caso la situazione è la stessa.

iLEAPP 💖

Come di consueto, a supporto del progetto iLEAPP (iOS Logs, Events, And Plists Parser) di Alexis Brignoni ho sviluppato il plugin idstatuscache.py che alla data odierna è in “pull request” e comunque disponibile sul mio GitHub.

Di seguito alcuni screenshot del report di Identity Lookup Service: