Con il termine mobile forensics si intende lo studio dei dati estratti da dispositivi mobili, come la lista dei contatti, l’elenco delle telefonate fatte e ricevute, gli SMS, le chat, foto e video, documenti prodotti o consultati, navigazioni, dati di geolocalizzazione, dati provenienti dalle varie app installate e così via.
Si tratta di un settore della digital forensics, la branca della scienza forense che si occupa della preservazione, dell’identificazione e dell’investigazione delle informazioni trovate all’interno dei dispositivi digitali, al fine di produrre evidenze che riguardano crimini informatici.
Indice degli argomenti
L’importanza crescente della mobile forensics
La mobile forensics sta assumendo un’importanza crescente nell’ambito della digital forensics, in quanto la diffusione dei dispositivi mobili nelle nostre vite fa sì che pressoché in ogni “scena del delitto” sia presente almeno un dispositivo mobile.
Questo non risparmia neanche l’ambito aziendale, visti i cambiamenti a cui è soggetto il nostro modo di lavorare, sempre più orientato alla mobilità, con il dispositivo mobile che sempre più spesso affianca o sostituisce il laptop come dispositivo principale di lavoro.
Per esempio, nei casi di indagine su furti di dati aziendali da parte di dipendenti, potrebbe essere necessario acquisire evidenze anche su dispositivi mobili.
Questo articolo sarà focalizzato sulle evidenze che possono essere estratte da dispositivi mobili e sulle tecniche utilizzate per la mobile forensics di dispositivi Android, piuttosto che sulla raccolta di informazioni relative a crimini informatici da utilizzare in tribunale.
Sfide della Mobile Forensics
La mobile forensics presenta diverse peculiarità che rendono più complessa l’estrazione e l’analisi dei dati da dispositivi mobili rispetto a quelli provenienti da PC. Vediamo un po’ più in dettaglio quali sono le cause:
- varietà dell’hardware. Sul mercato è disponibili una varietà enorme di modelli di smartphone provenienti da diversi produttori, che differiscono in termini di dimensioni, hardware, sistemi operativi, funzionalità. Inoltre, la velocità con il quale vengono rilasciati nuovi modelli e di nuove funzionalità rende difficile l’adozione e il consolidamento di tecniche di analisi. Si pensi ad esempio ai nuovi modelli sui quali non è più possibile estrarre la batteria, o alla difficoltà nello stabilire, sui nuovi modelli, se il dispositivo è acceso o spento;
- varietà dei sistemi operativi. Sebbene rispetto a qualche anno fa la situazione sembri essersi stabilizzata, con iOS e Android che coprono buona parte del mercato mondiale, anche all’interno di questi sistemi operativi esiste una grande varietà di versioni, con rilasci molto più frequenti e caratteristiche anche molto diverse tra una versione e l’altra. Se allarghiamo inoltre il campo dagli smartphone e tablet ad altre tipologie di dispositivi sempre più presenti nelle nostre vite (dispositivi indossabili, fotocamere digitali, home assistant ecc.) il discorso si complica ulteriormente;
- funzionalità di sicurezza presenti nei dispositivi mobili. Le versioni più recenti di dispositivi mobili contengono misure di sicurezza che hanno lo scopo di proteggere i dati e la privacy degli utenti. Queste funzionalità possono essere una sfida per chi deve acquisire e analizzare i dati. Si pensi per esempio ai meccanismi di cifratura hardware e software;
- alterazione dei dati. Una delle regole fondamentali della digital forensics è quella secondo la quale i dati presenti nel dispositivo non devono essere alterati dall’analisi. Nel caso dei dispositivi mobili questo è il più delle volte impossibile. Per esempio, se il dispositivo è protetto con un pin o una password, è necessario bypassare questo meccanismo. Inoltre, come vedremo nel corso dell’articolo, molte evidenze possono essere estratte solo nel caso in cui il dispositivo sia “rooted”, e quindi potrebbe essere necessario per l’analista effettuare il rooting, alterando quindi i dati. In realtà questa regola è diventata di difficile applicazione anche nel caso di acquisizione di evidenze volatili da PC, come ad esempio l’acquisizione della memoria.
Consapevoli delle difficoltà da affrontare, vediamo ora quali sono le principali tecniche di acquisizione ed analisi dei dati, con particolare attenzione al mondo Android.
Acquisizione dei dati
Acquisizione dei dati nell’ambito della mobile forensics è il processo attraverso il quale viene creata un’immagine, o vengono comunque estratti dati, dal dispositivo mobile. Vediamo quali sono i principali tipologie di acquisizione dei dati, dalla più completa (e complessa) a quella più parziale (ma facile).
Acquisizione fisica dei dati
Nella digital forensics l’acquisizione fisica è la copia bit a bit di un dispositivo elettronico. Declinata sui dispositivi mobili, l’acquisizione fisica avviene accedendo direttamente alla memoria flash e creando un’immagine bit a bit del suo contenuto. In questo modo avremo a disposizione un’immagine completa di tutto il file system, permettendo di aver accesso ad eventuali dati contenuti in file cancellati e al contenuto dello spazio non allocato.
Visto che si tratta dell’acquisizione più completa, perché non viene effettuata sempre? In primo luogo, essendo un’operazione piuttosto dispendiosa in termini di tempo, potrebbe essere sovradimensionata rispetto allo scopo dell’acquisizione: se sappiamo già cosa stiamo cercando, potremmo optare per un’acquisizione meno dispendiosa in termini di tempo.
In secondo luogo, l’acquisizione fisica dei dati via software richiede i privilegi di root sul dispositivo; il rooting del dispositivo potrebbe essere un’operazione distruttiva e comunque invasiva (vedi alla voce alterazione dei dati).
Un’altra possibile via per effettuare un’acquisizione fisica dei dati è quella di accedere fisicamente al chip della memoria estraendolo fisicamente dal dispositivo (chip-off), ma anche questa operazione richiede molto tempo ed è potenzialmente distruttiva, ancora più del rooting del dispositivo.
Acquisizione logica dei dati
Con questa modalità vengono estratti oggetti logici del dispositivo mobile, come ad esempio file e directory, attraverso un’interazione con il sistema operativo. Si tratta certamente di un’operazione più facile rispetto all’acquisizione fisica, ma ha la controindicazione di non permettere l’accesso a file cancellati o contenuti all’interno dello spazio non allocato.
Data la natura dei sistemi mobili tuttavia, vista la quantità di dati conservati all’interno di database SQLite, è possibile ripristinare alcuni dati cancellati a partire da un’acquisizione logica. La quantità di dati presenti in un’immagine risultato di acquisizione logica dipende fortemente dal fatto che l’acquisizione venga effettuata mediante un accesso di tipo root o meno.
Il sistema di sicurezza presente in Android non permette infatti l’accesso alle directory di sistema.
Acquisizione manuale dei dati
L’acquisizione manuale dei dati avviene interagendo con il dispositivo mobile attraverso l’interfaccia utente, ad esempio il touchscreen, cercando i dati di interesse e fotografando lo schermo che mostra tali dati.
Si tratta certamente di un metodo molto facile per l’acquisizione dei dati, ma introduce il rischio di errore umano che potrebbe portare alla cancellazione dei dati. Inoltre, può essere utilizzato come conferma delle evidenze estratte da un’acquisizione fisica o logica.
Acquisizione della RAM
Come già detto in un precedente articolo, tutto quello che viene eseguito in un sistema “passa” dalla RAM e quindi le informazioni presenti all’interno della RAM possono essere preziose per capire cosa sta avvenendo al suo interno.
Sebbene questo sia vero anche per i dispositivi mobili, l’acquisizione della RAM viene effettuata raramente, in quanto per essere effettuata è necessario essere dotati di un accesso root al dispositivo, cosa che può essere effettuata solo dopo un riavvio del dispositivo. Il riavvio del dispositivo causa l’azzeramento del contenuto della RAM, rendendo inutile l’acquisizione rispetto agli scopi per la quale si era intenzionati ad effettuarla.
Tale acquisizione può avere senso quando ci si trova davanti ad un dispositivo per il quale il rooting era già stato effettuato. In tal caso ha senso effettuare l’acquisizione, ma, per i motivi detti prima, i tool di analisi della RAM non sono così evoluti: l’unica analisi possibile è la ricerca di specifiche stringhe all’interno dell’immagine della RAM.
Tecniche di acquisizione in Android
Rooting del dispositivo
Abbiamo visto come l’acquisizione fisica dei dati e l’acquisizione della RAM possano essere effettuati solo se si dispone di accesso root al dispositivo. Anche se si opta per l’acquisizione logica, i dati delle applicazioni possono essere estratti solo se in possesso dell’accesso root.
Un altro motivo per il quale l’analista forense mobile ha necessità di conoscere le implicazioni di un dispositivo “rooted” è la possibilità di trovarsi ad analizzare un dispositivo con tali caratteristiche, cosa tutt’altro che infrequente.
Nei sistemi Unix o derivati, come appunto Android, l’utente amministratore, che ha i permessi per avviare o fermare i processi, modificare o cancellare qualsiasi file, modificare i privilegi degli altri utenti, è detto root. Normalmente, per ragioni di sicurezza, sui sistemi Android l’accesso come root non è possibile.
Il rooting del dispositivo Android è quindi l’operazione attraverso la quale viene guadagnato l’accesso al dispositivo come utente root, allo scopo di eseguire azioni normalmente non permesse sul dispositivo.
Essendo un’operazione generalmente non prevista dal produttore, per effettuare il rooting sono stati trovati diversi sistemi, dipendenti sostanzialmente dal dispositivo sottostante, ma generalmente basati sullo sfruttamento di una qualche vulnerabilità del firmware del dispositivo e sulla copia del tool su (super user) sul filesystem del dispositivo (generalmente in /system/xbin/su) e concedendogli i permessi di esecuzione.
Le modalità pratiche attraverso le quali questo può essere ottenuto sono fortemente dipendenti dal dispositivo: si va da dall’installazione/esecuzione di un’app sul dispositivo, all’installazione di un software di recovery modificato nella partizione di recovery, all’utilizzo di un tool per PC che permette il rooting del dispositivo connesso al PC via USB.
Un esempio di tool di quest’ultimo tipo, piuttosto semplice da utilizzare, è KingoRoot, di cui mostriamo una schermata:
- se qualcosa andasse storto durante il rooting del dispositivo, il dispositivo stesso potrebbe diventare inutilizzabile;
- l’operazione invalida la garanzia del dispositivo;
- un dispositivo “rooted” è più esposto a malware o altri attacchi; un malware o un attaccante a disposizione di privilegi di root potrebbe causare molti più danni;
- dal punto di vista forense, si tratta di un’alterazione dei dati del dispositivo da sottoporre ad analisi, che, come abbbiamo visto, potrebbe essere inevitabile, ma che costituisce comunque una contravvenzione ad uno dei principi cardine della digital forensics.
Acquisizione di dati attraverso ADB: Android Debug Bridge
L’Android Debug Bridge, o ADB, è un tool che fa parte degli Android SDK tools, un insieme di tool rivolti agli sviluppatori che permette di costruire, testare, effettuare il debug di app Android. Android SDK tools è disponibile per Windows, MacOS, Linux.
L’ADB è uno strumento fondamentale per la Mobile Forensics in Android, in quanto permette la comunicazione via USB fra il dispositivo mobile e un host computer, ovvero il computer utilizzato dall’analista forense per l’acquisizione dei dati dal dispositivo mobile.
Al fine di permettere la comunicazione via USB, sul dispositivo mobile deve essere abilitata la modalità sviluppatori e il debugging USB. Nei dispositivi più recenti la modalità sviluppatori potrebbe essere nascosta: le modalità con cui può essere abilitata variano da dispositivo a dispositivo.
Una delle modalità più comuni è quella di fare tap per 7 volte sul campo “build number” situato in Settings/System/Info. Una volta collegato il dispositivo ad un PC, occorre concedere esplicitamente il permesso.
Una volta attivato il debugging USB, all’interno del dispositivo mobile verrà avviato il demone ADB (adbd), il quale si occuperà della connessione USB con la workstation. Il demone è in esecuzione mediante un account non privilegiato: questo comporta che, se il dispositivo non è rooted, adb non permetterà né l’acquisizione fisica dei dati, né l’accesso ai dati interni delle applicazioni.
Sulla workstation dove sono installati gli Android SDK tool è presente un tool a riga di comando (adb) il quale, una volta lanciato, verificherà la presenza del demone ADB sulla workstation; se tale demone non è in esecuzione lo avvierà. Il client comunica con il demone attraverso una connessione TCP sulla porta 5037.
Attraverso ADB è possibile:
- copiare file da e verso il dispositivo;
- eseguire il debug di app in esecuzione sul dispositivo;
- eseguire comandi di shell sul dispositivo;
- ottenere i log di sistema e applicazioni;
- installare e rimuovere app.
Per esempio, attraverso adb può essere ottenuta una shell sul dispositivo:
fabio@buccia ~ $ adb shell
shell@B706:/ $
Se il dispositivo è rooted, attraverso il comando su può essere ottenuta una shell di root:
shell@B706:/ $ su
root@B706:/ #
L’acquisizione fisica dei dati da un dispositivo Android può essere effettuata da adb utilizzando il comando dd, un comando linux che permette la copia bit a bit; normalmente è presente sui sistemi Android.
La sintassi di dd prevede l’opzione if= per indicare il dispositivo (file) di input della copia, mentre l’opzione of= per indicare il dispositivo (file) di output della copia. Nel nostro caso il dispositivo di cui vogliamo effettuare la copia bit a bit è la flash memory del dispositivo.
Generalmente si tratta del dispositivo mmcblk0, ma è comunque possibile verificare leggendo il contenuto di /proc/partitions, che contiene l’elenco delle partizioni.
È possibile lanciare il comando dd sul dispositivo e salvare l’immagine sulla workstation dell’analista nel seguente modo.
fabio@buccia ~/analisys $ adb shell su -c dd if=/dev/block/mmcblk0 > mmcblk0.img
7514112+0 records in
7514112+0 records out
3847225344 bytes transferred in 1287.118 secs (2989023 bytes/sec)
fabio@buccia ~/analisys $
Attraverso una shell adb può essere anche effettuata un’acquisizione logica.
Nell’esempio seguente viene copiato il contenuto della directory /data (dove ci sono i dati delle applicazioni) in una nostra scheda SD inserita all’interno del dispositivo. Naturalmente questo può essere fatto se sul dispositivo non è già presente una scheda SD e la scheda utilizzata deve essere precedentemente ripulita. È possibile utilizzare tecniche per scrivere il risultato sulla workstation dell’analista, ma questo potrebbe richiedere l’installazione di tool aggiuntivi sul dispositivo mobile oggetto dell’analisi.
root@B706:/ # mkdir /storage/sdcard1/logical_extraction
root@B706:/ # cp -Rp /data /storage/sdcard1/logical_extraction
root@B706:/ #
Analisi dei dati
Le evidenze contenute all’interno dei dispositivi mobili e che possono essere estratte dai dati acquisiti sono molteplici e di diverso tipo. Riportiamo di seguito un elenco non esaustivo di categorie di evidenze che possono essere estratto da un dispositivo mobile:
- elenco dei contatti. Nomi, numeri di telefono, indirizzi e-mail;
- registro delle chiamate: chiamate effettuate, ricevute, durata delle chiamate;
- SMS e MMS: messaggi inviati e ricevuti;
- e-mail: e-mail ricevute, inviate, bozze, compresi gli allegati;
- cronologia della navigazione: cronologia dei siti web visitati;
- foto, video: foto e video prodotti dal dispositivo mobile oppure scaricati da Internet o da trasferiti altro dispositivo;
- musica e documenti: file musicali oppure documenti scaricati da Internet o trasferiti da altro dispositivo;
- agenda: appuntamenti registrati in agenda;
- posizioni: elenco delle posizioni GPS;
- mappe: elenco delle mappe scaricate, dei luoghi e degli itinerari ricercati;
- dati di social network: dati registrati da applicazioni come WhatsApp, Facebook, Twitter, Instagram Linkedin ecc.;
- dati cancellati: dati cancellati dal dispositivo.
Queste evidenze contengono generalmente timestamp di creazione, modifica e accesso.
Una trattazione completa di dove si trovino e come possano essere estratte queste evidenze richiederebbe troppo tempo: ci limiteremo quindi a qualche esempio di tecniche di analisi.
Analisi di dati con tool a riga di comando
Il file system con cui sono formattate le partizioni all’interno della immagini della flash memory acquisite da sistemi Android è solitamente di tipo ext4, come quello di molti sistemi Linux. Le tecniche di analisi che possono essere utilizzate, per esempio per il recovery dei file cancellati, l’analisi dei timestamp di apertura e/o modifica di file, la creazione della timeline, sono le stesse utilizzate per l’analisi forense di sistemi Linux.
Per esempio, può essere utilizzato Sleuthkit, una collezione di tool open source per l’analisi forense di filesystem e dispositivi: una trattazione completa di questi temi potrà essere oggetto di un articolo successivo.
Considerato però che le evidenze che possono essere estratte dai dispositivi mobili spesso sono contenute all’interno di database SQLIte, vediamo un esempio di come estrarre i dati sugli sms inviati e ricevuti. Il database contenente le informazioni sugli sms si trova in: /data/data/com.android.providers.telephony/databases/mmssms.db.
Se abbiamo effettuato un’acquisizione fisica della flash memory del dispositivo l’accesso a tale file non è così immediata, vediamo quindi come in un sistema Linux sia possibile, a partire dall’acquisizione fisica, analizzare il database degli SMS.
Con il tool mmls, parte di Sleuthkit, vediamo quali sono le partizioni contenute all’interno della nostra immagine:
buccia@sabayonx86-64 ~/analisys $ mmls mmcblk0.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
000: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
001: ——- 0000000000 0000018431 0000018432 Unallocated
002: Meta 0000001024 4294968318 4294967295 DOS Extended (0x05)
003: Meta 0000001024 0000001024 0000000001 Extended Table (#1)
004: 000:001 0000018432 0000038911 0000020480 Linux (0x83)
005: 000:002 0000038912 0000059391 0000020480 Linux (0x83)
006: ——- 0000059392 0000113151 0000053760 Unallocated
007: 000:003 0000113152 0001444351 0001331200 Linux (0x83)
008: 001:000 0001444352 0002214399 0000770048 Linux (0x83)
009: 001:001 0002214400 0004311551 0002097152 Linux (0x83)
010: 001:002 0004311552 4294968318 4290656767 Linux (0x83)
Se in fase di acquisizione avevamo preso dati relativi al partizionamento della flash memory, avremmo visto che la partizione /data era quella evidenziata, in caso contrario è possibile procedere per tentativi. Ora procediamo al mount della partizione, considerando che la dimensione dei settori è di 512 bytes:
fabio@buccia ~/analisys $ sudo mount -o loop,offset=$((2214400*512)) mmcblk0.img /mnt/usb/ -t ext4
fabio@buccia ~/analisys $
Quindi, attraverso il tool sqlite3 e una query SQL sulla tabella sms, visualizziamo gli sms presenti:
fabio@buccia ~/analisys $ sudo sqlite3 /mnt/usb/data/com.android.providers.telephony/databases/mmssms.db
SQLite version 3.28.0 2019-04-16 19:49:53
Enter “.help” for usage hints.
sqlite> .tables
addr pdu thread_settings
android_metadata pending_msgs threads
attachment quicktex wappush
canonical_addresses rate words
cellbroadcast raw words_content
drm sms words_segdir
part sr_pending words_segments
sqlite> select address, date, type, body, seen from sms;
+39XXXXXXXXXX|1455709266891|2|Grazie!|1
+39XXXXXXXXXX|1455709590851|2|Umm … |1
+39XXXXXXXXXX|1455709845786|1|Ha detto che …|1
+39XXXXXXXXXX|1455710125518|2|Naturalmente …
+39XXXXXXXXXX|1455710163950|1|Ok buona vacanza|1
sqlite> .quit
fabio@buccia ~/analisys $
Il campo address contiene il numero di telefono del destinatario o mittente dell’sms, il campo date contiene il timestamp in formato unix (facilmente convertibile in formato leggibile, utilizzando anche tool online, come ePochConverter), il campo type vale 1 se si tratta di sms ricevuto e 2 se si tratta di sms inviato, il campo body contiene il testo del messaggio e il campo seen vale 0 se il messaggio non è stato letto e 1 in caso contrario.
Infine, come già accennato in precedenza, all’interno del database possono essere conservati record marcati per la cancellazione ma non rimossi. Esistono tool attraverso i quali fare il recovery di tali record e recuperare sms che l’utente aveva cancellato, come ad esempio il tool Sqlite-Parser (). Vediamo un esempio di utilizzo:
fabio@buccia ~/analisys $ sudo python2 sqlparse.py
Usage: Parse deleted records from an SQLite file into a TSV File or text file
Examples:
-f /home/sanforensics/smsmms.db -o report.tsv
-f /home/sanforensics/smssms.db -r -o report.txt
Options:
-h, –help show this help message and exit
-f smsmms.db, –file=smsmms.db
sqlite database file
-o output.tsv, –output=output.tsv
Output to a tsv file. Strips white space, tabs and
non-printable characters from data field
-r, –raw Optional. Will out put data field in a raw format and
text file.
-p, –printpages Optional. Will print any printable non-whitespace
chars from all non-leaf b-tree pages (in case page has
been re-purposed). WARNING: May output a lot of string
data.
fabio@buccia ~/analisys $ sudo python2 sqlparse.py -f /mnt/usb/data/com.android.providers.telephony/databases/mmssms.db
-o report.tsv
fabio@buccia ~/analisys $
All’interno del file report.tsv sono contenuti, tra le altre cose, contenuti di sms cancellati.
Analisi di dati con Autopsy
Autopsy è un tool open source di analisi forense inizialmente nato come interfaccia grafica web based per il tool Sleuthkit, ma diventato poi un tool standalone per sistemi Windows.
Autopsy è a conoscenza di dove trovare le evidenze sui sistemi Android, per cui è possibile caricare un’immagine derivante da acquisizione fisica o logica di un dispositivo Android affinché un certo numero di informazioni venga estratto automaticamente, comprese informazioni sui file cancellati.
Dopo aver creato un nuovo caso, si aggiunge un nuovo data source, per esempio di tipo “Disk Image or VM File” se abbiamo disponibile un’immagine proveniente da un’acquisizione fisica. Selezionato il file, ci viene chiesto quale tipo di analisi effettuare.
Terminata l’apertura dell’immagine, è possibile visualizzare le informazioni sulle partizioni e sui documenti trovati all’interno dell’immagine.
Conclusioni
Lo scopo di questo articolo era quello di mostrare le potenzialità e accennare alle tecniche di mobile forensics su sistemi Android, con la speranza di creare curiosità e aumentare la consapevolezza.
Come avviene in generale per la digitale forensics, si tratta di tematiche poco conosciute all’interno delle aziende, che le ritengono di esclusiva competenza delle forze dell’ordine.
Se è vero che non tutte le aziende devono avere competenze tecniche come quelle illustrate in casa, è vero che occorre prepararsi a gestire eventuali incidenti anche sviluppando competenze di questo tipo all’interno dell’azienda o individuandole all’esterno, definendo policy e procedure, dotandosi di strumenti che permettano all’azienda di essere pronta in caso di incidente di qualsiasi tipo.
