Indice dei contenuti
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):
-
com.apple.madrid =
iMessage
-
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 è:
-
Eliminando il contatto dalla rubrica il record nella cache persiste;
-
I timestamp non sono quelli del
primo contatto (caso limite), ma quelli del primo contatto del giorno
dell'ultima richiesta di verifica dell'autenticazione;
-
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:
