Data carving e recupero file OpenOffice

Inserito da legionario il Gio, 10/16/2008 - 03:29

Nell’ambito di una simulazione di indagine su un dispositivo di memorizzazione di massa, effettuata ai fini dell’elaborazione di una tesi di laurea dal titolo “Computer Forensics e software Open Source”, è stato possibile mettere a punto una tecnica per il recupero dei file ODT che generalmente non vengono estrapolati in modo corretto dal famoso tool di data carving Foremost. In fase di simulazione, infatti, sono stati salvati sul dispositivo numerosi file, tra i quali diversi di tipo OpenOffice con estensione ODT. Dopo la formattazione del supporto si è proceduto al recupero dei dati eliminati prima con le tradizionali tecniche filesystem dependant e successivamente con il noto software di data carving. Al termine del recovery effettuato con quest’ultima tecnica si è appurato che:

a) ferme restando le impostazioni di default del file di configurazione foremost.conf , i file ODT venivano erroneamente riconosciuti come file ZIP;

b) in seguito ad opportuna modifica del foremost.conf , l’assenza del footer nel formato ODT comportava il recupero di numerosi file ODT corrotti e, soprattutto, mai esistiti sul supporto.

Si procedeva pertanto ad esaminare approfonditamente, a livello esadecimale, il formato ODT. Prima di entrare nel merito della procedura è opportuno fare un veloce volo pindarico sulla tecnica di data carving, indispensabile per il recupero dei file derefenziati dal filesystem, cioè di cui il filesystem ha perso traccia e pertanto non recuperabili con le tradizionali tecniche di recovery.

Un programma di data carving (d’ora in avanti “data carver”) accede a un dispositivo scorrendone byte a byte, come se fosse un nastro, tutto il contenuto. Nel momento in cui il programma di data carving incontra una sequenza di byte coincidente con uno degli header memorizzati nel suo file di configurazione, inizia l’estrazione dei byte a partire da quell’header fino alla prima occorrenza di byte coincidenti con il footer conosciuto. Se un particolare file non dovesse essere dotato di footer il carver si ferma dopo un numero di byte arbitrariamente predefinito dall’utente nel file di configurazione.
Ovviamente questo numero deve essere di dimensioni ragionevoli, preferibilmente sovradimensionato rispetto alle dimensioni presunte del file da recuperare in quanto eventuali byte eccedenti possono, in linea teorica, essere eliminati manualmente.

Header e footer fanno parte del cosiddetto magic number, cioè una sequenza di bit normalmente posta, rispettivamente, all’inizio e alla fine della sequenza di dati, che serve per definire il formato in cui i dati sono memorizzati.

Segue ora il percorso che ci ha condotto al raggiungimento del nostro obiettivo.

Abbiamo, in prima battuta, avviato foremost con i seguenti parametri:

______________________________________________________________________________________

legionario@bg:/mnt/forensic$ foremost -v -T -t all -i /mnt/forensic/penna.dd -o /mnt/forensic/recupero
______________________________________________________________________________________

Ove:

-v modalità verbose; con questa opzione il programma stampa a video un numero rilevante di utili informazioni relative al processo in corso;

-T aggiunge alla directory di output un suffisso formato dal time stamp, cioè dalla data e ora di avvio del programma; in questo modo è possibile mantenere la stessa directory di output senza il rischio di sovrascritture o cancellazioni dei processi precedentemente lanciati;

-t specifica la tipologia di file da recuperare; nel nostro caso all consente di recuperare i file di qualsiasi formato (tra quelli memorizzati nel file di configurazione ovviamente);

-i individua il file immagine su cui effettuare il carving;

-o è la directory di output che conterrà i file recuperati e il file audit.txt; questa directory conterrà una sottodirectory per ogni tipologia di file recuperato.

Tra i file così estrapolati l’attenzione è caduta su uno ZIP, in realtà mai esistito sul supporto esaminato. Al suo interno compaiono una serie di file piuttosto singolari e apparentemente inutilizzabili dal punto di vista pratico.
Di seguito possiamo vedere il contenuto del file in questione:

La particolarità di tale archivio è riscontrabile, per esempio, nel file settings.xml il quale presenta questo contenuto:

Tuttavia il file meta.xml potrebbe darci qualche utile indizio:

C’è un riferimento al programma di videoscrittura OpenOffice.org versione 2.3. Abbiamo presupposto che foremost abbia estratto un file riconoscendolo come ZIP, ma che ZIP non è. Abbiamo, quindi, cercato di verificare questa ipotesi.

Innanzitutto abbiamo analizzato il contenuto dei primi 128 byte del file in questione, al fine di individuare l’header del file:

________________________________________________________________________________________________

legionario@bg:/mnt/forensic$ xxd -l 128 recupero_Thu_Jul_10_01_58_42_2008/zip/00011250.zip

0000000: 504b 0304 1400 0000 0000 dd98 e938 5ec6 PK………..8^.
0000010: 320c 2700 0000 2700 0000 0800 0000 6d69 2.’…’…….mi
0000020: 6d65 7479 7065 6170 706c 6963 6174 696f metypeapplicatio
0000030: 6e2f 766e 642e 6f61 7369 732e 6f70 656e n/vnd.oasis.open
0000040: 646f 6375 6d65 6e74 2e74 6578 7450 4b03 document.textPK.
0000050: 0414 0000 0000 00dd 98e9 3800 0000 0000 ……….8…..
0000060: 0000 0000 0000 001a 0000 0043 6f6e 6669 ………..Confi
0000070: 6775 7261 7469 6f6e 7332 2f73 7461 7475 gurations2/statu 
_________________________________________________________________________________________________

Ne abbiamo, quindi, tratto due indizi:

1.l’header 504b 0304 ;

2.mimetypeapplication/vnd.oasis.opendocument.text .

Il primo indizio lo abbiamo confrontato con gli header contenuti nel file di configurazione foremost.conf di cui mostriamo una porzione:
___________________________________________________________________

[.....]
# (NOTE THIS FORMAT HAS BUILTIN EXTRACTION FUNCTION)

zip y 10000000 PK\x03\x04 \x3c\xac

# (NOTE THIS FORMAT HAS BUILTIN EXTRACTION FUNCTION)

rar y 10000000 Rar!

#

java y 1000000 \xca\xfe\xba\xbe

___________________________________________________________________

Ecco il significato dei parametri:

la prima colonna indica il formato del file;

la seconda colonna attiva (y) o disattiva (n) la ricerca degli header e degli eventuali footer con modalità case sensitive (distinzione tra maiuscole e minuscole);

la terza colonna pone la dimensione massima in byte da estrarre a partire dall’header; è indispensabile quando non sono presenti i footer;

la quarta colonna contiene l’header;

la quinta colonna contiene il footer.

È da precisare che l’header ed il footer possono essere specificati con valori esadecimali, ottali o in caratteri. Lo spazio è rappresentato da \s.

I valori esadecimali sono rappresentati come \x[0-f][0-f], quelli ottali come \[0-3][0-7][0-7]. È anche possibile inserire direttamente valori in carattere ASCII.

Dalla porzione sopraevidenziata di foremost.conf possiamo notare che il file in questione è stato estratto in quanto il suo header è coincidente con quello contenuto nel foremost.conf sotto la categoria “zip”. Tuttavia il secondo indizio ci porta a ritenere che si possa trattare di un file di tipo ODT, utilizzato da OpenOffice.

Come ulteriore verifica andiamo a controllare il valore dell’header dei file ODT e ZIP interrogando sul web il motore di ricerca delle estensioni1:

I due header coincidono: abbiamo, in definitva, avuto la conferma che questo è il motivo per cui foremost l’ha estrapolato come file ZIP. Non ci deve trarre in inganno il fatto che nel foremost.conf sia indicato, all’inizio dell’header, PK anziché 504b, in quanto questo valore esadecimale corrisponde ai aratteri ASCII PK .

Inseriamo una nuova riga nel foremost.conf omettendo di inserire il footer in quanto gli ODT, a differenza dei file ZIP, non sono dotati di un footer noto:
_________________________________________________________________________

odt n 12500000 \x50\x4b\x03\x04 
_________________________________________________________________________

È da notare che è stata disattivata la ricerca case sensitive e che la dimensione massima è stata aumentata a 12500000 bytes (circa 12 Mbytes).
Alla luce di tali modifiche abbiamo nuovamente avviato foremost:
______________________________________________________________________________________________

legionario@bg:/mnt/forensic$ foremost -v -T -t odt -i /mnt/forensic/penna.dd -o /mnt/forensic/recupero

Foremost version 1.5.3 by Jesse Kornblum, Kris Kendall, and Nick Mikus

Audit File

Foremost started at Thu Jul 10 02:39:01 2008

Invocation: foremost -v -T -t odt -i /mnt/forensic/penna.dd -o
/mnt/forensic/recupero

Output directory: /mnt/forensic/recupero_Thu_Jul_10_02_39_01_2008

Configuration file: /opt/foremost-1.5.3/foremost.conf

------------------------------------------------------------------

File: penna.dd

Start: Thu Jul 10 02:39:01 2008

Length: 1 GB (2062548992 bytes)

Num Name (bs=512) Size File Offset Comment

0: 00011250.odt 12207 KB 5760000
1: 00011250_1.odt 12207 KB 5760077
2: 00011250_2.odt 12207 KB 5760133
3: 00011250_3.odt 12207 KB 5760220
4: 00011250_4.odt 12207 KB 5760274
5: 00011250_5.odt 12207 KB 5760330
6: 00011250_6.odt 12207 KB 5760388
7: 00011250_7.odt 12207 KB 5760442
8: 00011250_8.odt 12207 KB 5760496
9: 00011251.odt 12207 KB 5760557
10: 00011507.odt 12207 KB 5892088
11: 00011508.odt 12207 KB 5892188
12: 00011511.odt 12207 KB 5893775
13: 00011514.odt 12207 KB 5895666
14: 00011515.odt 12207 KB 5896170
15: 00011554.odt 12207 KB 5915896
16: 00011556.odt 12207 KB 5917168

Finish: Thu Jul 10 02:41:26 2008

17 FILES EXTRACTED

odt:= 17

------------------------------------------------------------------

Foremost finished at Thu Jul 10 02:41:27 2008

______________________________________________________________________

Abbiamo recuperato addirittura ben 17 file ODT.

Una volta aperti con OpenOffice questi file, nonostante la loro dimensione sia di 12 Mbyte ciascuno, sono risultati, purtroppo, completamente vuoti, in pratica ci è apparsa solo una misera pagina bianca. Questa anomalia è da imputare sicuramente alla mancanza dei footer.

Per risolvere questo problema abbiamo cercato di verificare se effettivamente gli ODT fossero privi di footer. Abbiamo, quindi, analizzato gli ultimi byte di numerosi file ODT, confrontandoli poi tra loro. Riportiamo, come esempio, gli ultimi byte dei file “tutorial.odt” e “broker.odt”:
_______________________________________________________________________

legionario@bg:/mnt/forensic$ xxd -s 158650 tutorial.odt

0026bba: 504b 0102 1400 1400 0800 0800 dd98 e938 PK.............8
0026bca: 96b9 db94 be04 0000 9a1d 0000 0c00 0000 ................
0026bda: 0000 0000 0000 0000 0000 f860 0200 7365 ...........`..se
0026bea: 7474 696e 6773 2e78 6d6c 504b 0102 1400 ttings.xmlPK....
0026bfa: 1400 0800 0800 dd98 e938 9e24 0edb 8101 .........8.$....
0026c0a: 0000 7708 0000 1500 0000 0000 0000 0000 ..w.............
0026c1a: 0000 0000 f065 0200 4d45 5441 2d49 4e46 .....e..META-INF
0026c2a: 2f6d 616e 6966 6573 742e 786d 6c50 4b05 /manifest.xmlPK.
0026c3a: 0600 0000 0011 0011 0083 0400 00b4 6702 …………..g.
0026c4a: 0000 0000

legionario@bg:/mnt/forensic$ xxd -s 139050 ~/Monografia\ broker.odt

0021f2a: 6169 6c2e 706e 6750 4b01 0214 0014 0008 ail.pngPK…….
0021f3a: 0008 00b4 a2de 3857 c5ca dc16 0600 003d ……8W…….=
0021f4a: 2200 000c 0000 0000 0000 0000 0000 0000 “……………
0021f5a: 0020 1302 0073 6574 7469 6e67 732e 786d . …settings.xm
0021f6a: 6c50 4b01 0214 0014 0008 0008 00b4 a2de lPK………….
0021f7a: 3844 57e4 0978 0100 006d 0800 0015 0000 8DW..x…m……
0021f8a: 0000 0000 0000 0000 0000 0070 1902 004d ………..p…M
0021f9a: 4554 412d 494e 462f 6d61 6e69 6665 7374
ETA-INF/manifest
0021faa: 2e78 6d6c 504b 0506 0000 0000 1100 1100
xmlPK………..
0021fba: 8304 0000 2b1b 0200 0000 ….+…..
__________________________________________________________________________

Come si può notare non esiste un footer in quanto gli ultimi byte dei due file sono evidentemente diversi. Tuttavia, troviamo una serie di byte corrispondenti alle lettere ASCII manifestxmlPK . Questo particolare è molto interessante, soprattutto in considerazione del fatto che compare anche in tutti i file ODT analizzati.

A questo punto non ci è restato che inserire questo simil-footer nel foremost.conf :
___________________________________________________________________________________

legionario@bg:/mnt/forensic$ vim /opt/foremost-1.5.3/foremost.conf
___________________________________________________________________________________

Abbiamo pertanto riavviato il data carver:
____________________________________________________________________________________________

legionario@bg:/mnt/forensic$ foremost -v -T -c /opt/foremost-1.5.3/foremost.conf -i penna.dd -o recupero

Foremost version 1.5.3 by Jesse Kornblum, Kris Kendall, and Nick Mikus

Audit File

Foremost started at Thu Jul 10 02:39:01 2008

Invocation: foremost -v -T -c /opt/foremost-1.5.3/foremost.conf -i penna. dd -o recupero

Output directory: /mnt/forensic/recupero_Thu_Jul_10_02_39_01_2008

Configuration file: /opt/foremost-1.5.3/foremost.conf

Processing: penna.dd

|------------------------------------------------------------------

File: penna.dd

Start: Thu Jul 10 02:39:01 2008

Length: 1 GB (2062548992 bytes)

Num Name (bs=512) Size File Offset Comment

0: 00011250.odt 155 KB 5760000
1: 00011250_1.odt 154 KB 5760077
2: 00011250_2.odt 154 KB 5760133
3: 00011250_3.odt 154 KB 5760220
4: 00011250_4.odt 154 KB 5760274
5: 00011250_5.odt 154 KB 5760330
6: 00011250_6.odt 154 KB 5760388
7: 00011250_7.odt 154 KB 5760442
8: 00011250_8.odt 154 KB 5760496

********************|

Finish: Thu Jul 10 02:41:26 2008

8 FILES EXTRACTED

odt:= 8

------------------------------------------------------------------
_________________________________________________________________________________

Questa volta sono stati estratti solo 8 file ma il risultato non può essere considerato soddisfacente in quanto quelli dal numero 1 a 8 sono risultati vuoti, mentre il numero 0 si è rivelato l’unico file valido. Ciò che ci ha lasciato perplessi è stato il fatto che i file presentassero tutti lo stesso nome, fatta eccezione per un suffisso costituito da un numero progressivo posto dopo l’underscore (es: 00011250_1.odt 00011250_2.odt ecc.). Quel suffisso sta a indicare che lo stesso file è riallocato su più settori. Sicuramente una situazione anomala.

Abbiamo quindi affinato il data carving aggiungendo il parametro -q , che obbliga il programma a ricercare l’header solo all’inizio di ogni settore per la lunghezza massima dell’header più lungo presente nel file di configurazione, tralasciando il resto dei dati. In questo modo è teoricamente possibile ripulire l’output da file inutili.
_______________________________________________________________________________________________

legionario@bg:/mnt/forensic$ foremost -v -q -T -c /opt/foremost-1.5.3/foremost.conf -i penna.dd -o recupero

Foremost version 1.5.3 by Jesse Kornblum, Kris Kendall, and Nick Mikus

Audit File

Foremost started at Thu Jul 10 02:43:56 2008

Invocation: foremost -v -q -T -c /opt/foremost-1.5.3/foremost.conf -i penna.dd -o recupero

Output directory: /mnt/forensic/recupero_Thu_Jul_10_02_43_56_2008

Configuration file: /opt/foremost-1.5.3/foremost.conf

Processing: penna.dd

|------------------------------------------------------------------

File: penna.dd

Start: Thu Jul 10 02:43:56 2008

Length: 1 GB (2062548992 bytes)

Num Name (bs=512) Size File Offset Comment

0: 00011250.odt 155 KB 5760000

********************|

Finish: Thu Jul 10 02:45:49 2008

1 FILES EXTRACTED

odt:= 1

——————————————————————

Foremost finished at Thu Jul 10 02:45:49 2008

__________________________________________________________________________

La nostra intuizione si è rivelata corretta. Infatti abbiamo estratto un solo file.

La procedura sopraesposta ci ha consentito di scoprire l’esistenza di una sequenza univoca di byte posta non proprio alla fine dei file ODT, ma comunque nelle sue “vicinanze” e pertanto non considerabile come un footer vero e proprio. Da qui la coniazione del neologismo “simil-footer”. In questo modo, però, i byte finali dei file ODT vengono di fatto tagliati creando una potenziale corruzione dei file stessi. Tale inconveniente viene fortunatamente risolto dal software OpenOffice. Infatti, al momento dell’apertura di questi file, OpenOffice ci avvisa che il file è corrotto e ci chiede se vogliamo ripararlo. Cliccando su “Yes”:

i file saranno automaticamente riparati. In realtà, la riparazione consiste nell’aggiunta dei byte che abbiamo inevitabilmente tagliato con la nostra procedura.

In conclusione, questa tecnica può essere di grande aiuto per l’individuazione ed estrazione dei file ODT, altrimenti non possibile con il famoso data caver foremost.

- Alessio Grillo