Durante End Summer Camp, alla Ville Forensics si è svolta un'interessante analisi di un dispositivo mobile poco diffuso, e per questo poco noto nel mondo della forensics: uno smartphone Jolla con sistema operativo Sailfish.

ForensicFocus. com ha pubblicato il nostro articolo in inglese sull'esperienza, ma ve lo raccontiamo comunque anche qui, in italiano:

Durante l’hacker camp MOCA 2016, al termine di un talk tenuto da Rebus sui metodi di circonvenzione dei passcode, uno spettatore propone un’intrigante challenge: dona a fini di ricerca uno smartphone per cercare di scoprire se e come sia possibile eseguirne un’analisi forense.

Si tratta di uno smartphone Jolla White 16GB JP-1301, equipaggiato con il sistema operativo Sailfish OS 2.0.1.11. Il dispositivo, inizialmente protetto da un PIN a 5 cifre, è stato sottoposto a due consecutivi reset; non utilizza cifratura sugli storage (non ancora supportata dal sistema operativo) e la modalità sviluppatore non è attiva (richiede la registrazione di un account Jolla che, per ora, non ci preoccupiamo di richiedere).

La sfida viene raccolta al successivo End Summer Camp, dove un dream team di tecnici affronta il problema presso la Ville Forensics, tra gli occhi curiosi degli altri hacker.

Il cellulare non espone un servizio analogo ad adb, ma soltanto (se autorizzato, ovvero attivando la connessione in modalità PC, che richiede la conoscenza del PIN, se questo è stato impostato) la partizione dati interna come Mass storage device. Di tale partizione è possibile eseguire copia logica dei file e delle cartelle visibili, ma l’accesso fisico presenta le limitazioni del protocollo MTP. Per quanto i dati utente esposti in questo modo possano essere significativi, il metodo è comunque parziale e insoddisfacente.

Per il resto, UFED4PC e Magnet Acquire falliscono, come prevedibile, nel rilevare il dispositivo da acquisire e sono pertanto inutilizzabili.

Esame fisico

Il cellulare è stato smontato in ogni sua parte e la scheda madre è stata esposta. Tutti i connettori sono di tipo ZIF e gli shield sono in parte ad incastro e in parte a clip.

Due cose saltano subito all’occhio.

La prima è la difficoltà di identificare il SoC, che è occultato da un chip di memoria installato sopra con metodo PoP. Quindi il grosso chip riportante il codice 3TA78 D9QMM (peraltro non documentato pubblicamente, e quindi probabilmente custom) è un chip di RAM prodotto da Micron, che nasconde il SoC sottostante, dichiarato genericamente “Qualcomm Dual Core” dal costruttore.

La seconda difficoltà deriva dalla pletora di test pin sulla mainboard, circostanza che, se da un lato certo aiuta, dall’altro non permette di trovare facilmente la funzione di questi e comprendere quali usare per un accesso a livello service, il che non ci consente di procedere via JTAG come eravamo intenzionati.

Collegando il telefono via USB senza batteria, il sistema non evidenzia purtroppo il comune comportamento dei dispositivi basati su SoC MediaTek che, collegati in questo modo, espongono una interfaccia USB da cui si può effettuare un flash del sistema oppure la copia della memoria. Il telefono infatti continua a vibrare e non si vedono nuovi device USB comparire sul computer.

Abbiamo tentato quindi una procedura suggerita su Internet per accedere alla recovery:

1. Rimuovere la batteria
2. Tenere premuto volume down e reinserire la batteria
3. Tenere premuto volume down, premere anche power e attendere finchè il telefono vibra
4. Rilasciare i pulsanti power e volume down

Se collegato in questa modalità, il dispositivo si annuncia come un nuovo device USB denominato “Generic RNDIS device”. Su sistema operativo Microsoft Windows 10, il driver non viene caricato automaticamente, ma se si procede manualmente all’installazione di un driver “Generic RNDIS device” tra quelli scritti da Microsoft,  il dispositivo viene correttamente riconosciuto come scheda di rete.

Collegando il telefono ad un sistema operativo Linux, il dispositivo viene invece immediatamente riconosciuto come scheda ethernet USB, è possibile quindi abilitare l’interfaccia e osservare che sul telefono è presente un deamon DHCP che assegna un indirizzo IP al computer. 

Il telefono espone unicamente la porta 23 (telnet); una volta entrati, senza che venga richiesta alcuna autenticazione, viene messa a disposizione dell’utente una shell con privilegi di root (come appurato in seguito, quando sul device viene configurato il PIN a 5 cifre, per accedere alla shell di root è necessario inserire il PIN. Le possibilità di brute forcing dipendono dalla configurazione impostata dall’utente).

Lanciando il comando mount per verificare l’elenco dei filesystem ci si accorge con piacere che la partizione principale del sistema non è montata, mentre il device (/dev/mmcblk0) presenta un partizionamento GPT con 28 partizioni.

Il fatto che il sistema di recovery sia basato su Linux viene senz’altro in aiuto, in quanto è già presente tutta la toolchain che può essere necessaria per fare l’acquisizione fisica della memoria del telefono: sono presenti sia dd sia netcat, e quindi il metodo più semplice consiste nello sfruttare la connessione di rete già presente tra il computer e il device per effettuare un dd over netcat.

Mettendo un netcat in ascolto sul PC e dd in pipe è possibile ottenere, in circa 3 ore, un’immagine bitstream dell’intero chip di memoria:

Prima, dal computer:

nc -lvp 8888 | dd of=/path/to/destination/image.raw

E quindi, dal cellulare:

dd if=/dev/mmcblk0 conv=noerror,sync | nc [IP_computer] 8888

CHINEX

Dal momento che lo smontaggio del telefono aveva inizialmente fatto sospettare l’uso di un processore MTK, si è tentata l’acquisizione mediante il kit CHINEX di UFED, ma senza che questo riuscisse a superare con successo procedura MTK Pinfind. Anche gli altri metodi previsti per device generici MTK hanno fallito.

L’esito dell’acquisizione è stata una bit stream image da 16GB.

La prima cosa che abbiamo voluto verificare è il partizionamento. Per fare questo abbiamo aperto l’immagine con X-Ways Forensics. Partizionamento GPT, interpretato correttamente dal software. 28 partizioni rilevate. Viene da pensare: ottimo, siamo a buon punto.

La prima delusione è con UFED Physical Analyzer: pur servendogli il dump raw pronto all’uso, nessuno dei profili predefiniti, delle catene di script preconfigurate , dei singoli plug-in Python in dotazione è in grado di estrarre informazioni utili. Il risultato apparentemente migliore di tutti lo si ottiene con un profilo generico per device MTK, che sembra rilevare alcuni messaggi e-mail ed sms cancellati, che però si rivelano per lo più falsi positivi. Nulla di utile.

Parallelamente, con X-Ways cominciamo ad analizzare le singole partizioni, riscontrando che quelle di maggiori dimensioni (e quindi potenzialmente contenitori di informazioni) sono la numero 24 (Linux Swap da 500 MB) e la numero 28 da 13.5 GB. Ma purtroppo arriva il primo problema: la partizione ha file system Btrfs, non supportato da X-Ways (ed evidentemente neanche da UFED PA). Stesso esito quindi per l’ispezione dell’immagine con FTK Imager o con Autopsy, ma lo stesso avremmo ottenuto anche con Encase o FTK: nessuno dei più popolari software di analisi forense si preoccupa di supportare btrfs. Ma Linux sì.

Decidiamo quindi di “sdoppiare” il lavoro: Pila, con l’aiuto di un po’ di amici lì presenti, si occupa di montare il file system in ambiente Linux per tirare fuori un TAR dei file visibili, mentre Mattia e Rebus lavorano sul dato grezzo della partizione alla ricerca di informazioni o frammenti di informazioni.

La prima attività si conclude con successo e il file TAR viene nuovamente dato in pasto ad X-Ways Forensics: come era legittimo attendersi i file attuali presenti sul dispositivo non contengono dati, poiché il dispositivo era stato resettato dal proprietario prima di consegnarcelo.

Ci resta quindi solo la strada dell’ignoto: il dato grezzo. Si parte quindi con carving spinto (byte level) con X-Ways Forensics e con PhotoRec, mentre si cercano informazioni più strutturate con Internet Evidence Finder (IEF) e Bulk Extractor.

Già dopo pochi secondi cominciano a comparire in X-Ways immagini riferibili alla navigazione su siti web di natura medica e, poco dopo, IEF e Bulk Extractor ci riportano una lunga serie di keywords utilizzate su Google e proprio relative a una ricerca di natura medica. Il carving continua e cominciano e venire fuori db SQLite (569 per la precisione, poco più di 600 per PhotoRec). Tra questi individuiamo il database dei Cookies, che ci forniscono l’URL di provenienza delle immagini mediche. Riusciamo quindi a dare una data precisa al momento in cui è stata fatta la ricerca e alla successiva visita del sito web.

Proseguiamo quindi con il carving dei file e cominciano ad emergere le schermate di una applicazione di GPS, probabilmente quella preinstallata nel sistema. Da questi screenshot è possibile capire dove e come si è mosso il proprietario del dispositivo e, in alcuni casi, vedere esattamente l’origine e la destinazione.

Come ultimo aspetto decidiamo di cercare tracce di comunicazione con altri soggetti e di capire tutte le informazioni recuperabili sull’identità del proprietario del dispositivo. Il carving delle email ci tira fuori una sola email integra in formato EML: in tale mail sono presenti il mittente e il destinatario, con indicazione di nome, cognome e, ovviamente, indirizzo email.

A questo punto lanciamo una ricerca per parola chiave utilizzando l’indirizzo del mittente e del destinatario e questo ci permette di recuperare circa 400 corrispondenze: una analisi dettagliata dei risultati consente di recuperare circa 200 messaggi di posta elettronica, solo parzialmente sovrascritti ma che permettono di ricavare informazioni in relazione al lavoro svolto dal proprietario e i nomi di diversi clienti.

Decidiamo a questo punto di fermarci: l’esperimento di dimostrare che anche da un telefono non supportato dai comuni tool forensi e sottoposto a reset è possibile recuperare delle informazioni è perfettamente riuscito.

Possiamo quindi passare alla prossima birra, non prima di esserci gustati la faccia del proprietario quando abbiamo cominciato a chiedergli se conoscesse determinati soggetti o se era stato in determinati posti.

ESC “Ville Forensics” batte Jolla 2-0 (almeno!)