Cybercrimes.it - Computer Forensics & Crimine Informatico

The Sleuth Kit Informer

Numero 23

http://www.sleuthkit.org/informer
http://sleuthkit.sourceforge.net/informer

Brian Carrier
carrier at sleuthkit dot org

Numero 23
17 Maggio 2006

Traduzione : Maurizio Anconelli

Contenuti

Introduzione
Novità
Call For Papers

Expert Witness e supporto AFF
Un'introduzione alla libreria libewf Expert Witness

Introduzione

Nel numero 23 dell'Informer, parleremo di alcune delle nuove funzionalità della versione 2.04 di The Sleuth Kit. In particolare ci soffermeremo sui nuovi formati di file immagine. Il primo articolo descrive l'utilizzo di TSK con i formati ed il secondo parla delle librerie sviluppate da Joachim Metz e Robert-Jan Mora per il supporto del formato Expert Witness.

Novità

Le nuove versioni di The Sleuth Kit (TSK) e Autopsy sono state rilasciate l'11 Maggio 2006. TSK 2.04 include alcuni bug fixes ed alcune nuove funzionalità incluso il supporto ai formati di file immagine EWF ed AFF, al filesystem ISO 9660, ed un sistema di gestione degli errori aggiornato. E' compreso anche un nuovo tool 'img_cat' per mostrare il contenuto raw di un file immagine. Ad Autopsy 2.07 è stato aggiunto il supporto per i nuovi formati di file e filesystem di TSK ed un visulizzatore esadecimale per i file.

E' stato pubblicato il concorso DFRWS 2006 basato sul file carving. Il pacchetto dati contiene i file ed i frammenti e la sfida consiste nello sviluppare tool e tecniche per recuperare più file possibili con il minor numero di falsi positivi.

http://www.dfrws.org/2006/challenge/

Call For Papers

The Sleuth Kit Informer sta cercando articoli su strumenti open source e tecniche per l'investigazione digitale (computer / digital forensics) ed incident response. Sono apprezzati, ma non richiesti, articoli che parlano di The Sleuth Kit e Autopsy. Argomentazioni d'esempio includono (ma non sono limitate a):

Tutorials strumenti open source
Esperienze e commenti sull'utilizzo di strumenti open source
Nuove tecniche di investigazione con tool open source
Test e risultati di tool open source

Maggiori dettagli:

http://www.sleuthkit.org/informer/cfp.html

Supporto Expert Witness e AFF

By: Brian Carrier

La release 2.04 di The Sleuth Kit (TSK) include il supporto per i nuovi formati di file immagine. Questa integrazione è stata relativamente diretta a causa della struttura del layer immagine in TSK [1] e delle librerie sviluppate per supportare i formati. Gli articoli in questo e nei futuri numeri dell'Informer, descriveranno in dettaglio i formati immagine e le librerie. Questo articolo descrive le basi e l'utilizzo dei formati in TSK ed Autopsy.

Expert Witness Support

Il formato Expert Witness (EWF) è alla base dei formati immagine creati da EnCase ed altri tool. Il relativo supporto è stato aggiunto a TSK da Joachim Metz e Robert Jan Mora della Hoffmann Investigations attraverso l'utilizzo di libewf [2], che è descritto nel prossimo articolo in questo numero dell'Informer.

Nell'header del file EWF è presente una signature che può essere utilizzata come identificazione e di conseguenza TSK può rilevare automaticamente i file EWF quando sono passati come input senza il formato dell'immagine. Se si vuole specificare il formato immagine bisogna aggiungere il flag '-i ewf' alla linea di comando. Il normale flag '-o' può essere sempre utilizzato per specificare l'offset nel file immagine. Se si vuole specificare, ad esempio, il tipo di file immagine ed elencare i file nel settore 63 della partizione, il comando da utilizzare è il seguente:

# fls -i ewf -o 63 disk1.E01

La libreria libewf convertirà l'offset nella corretta posizione all'interno del file immagine compresso. Utilizzare EWF con TSK non è differente dall'utilizzo di file grezzi.

Se il tool di acquisizione ha settato un limite di grandezza dell'immagine, l'acquisizione di dischi estesi può comportare la creazione di file EWF multipli. E' comune, ad esempio, l'utilizzo del limite di 2 GB se il file sarà contenuto all'interno di un drive formattato in FAT32. TSK e libewf supportano file EWF segmentati ma, tutti i file devono essere specificati alla linea di comando. Per elencare i file che iniziano al settore 63, è ad esempio possibile utilizzare i seguenti comandi:

# fls -o 63 disk1.E01 disk1.E02

# fls -o 63 disk1.E0?

Il tool 'img_stat' attualmente mostra la grandezza e l'hash MD5 di un file EWF. Le future release mostreranno possibilmente altri metadata contenuti nel file.

AFF Support

Il supporto per l'Advanced Forensic Format (AFF) è fornito da AFFlib [3] di Simson Garfinkel e Basis Technology (disclaimer: io lavoro per Basis Technology). Ulteriori dettagli saranno inclusi nei futuri numeri di Informer ed il sito AFFlib descrive in dettaglio il formato immagine.

AFF è un formato immagine sviluppato per essere estensibile ed aperto. La sua struttura dei dati è documentata ed il formatoconsiste in un gruppo di coppie nome-valore, chiamati segmenti. Alcuni segmenti contengono i dati ed altri contengono i metadata. Il valore in ciascuno dei segmenti può essere compresso.

Esistono tre differenti tipi di file AFF: AFF, AFD, e AFM. Tutti utilizzano la stessa struttura dei dati. Il formato AFF utilizza un singolo file per contenere tutti i segmenti. Il formato AFD può essere composto da file multipli contenuti tutti in una directory, aventi l'estensione '.afd'. Questo formato è utilizzato quando è necessario un limite di grandezza del file ed ogni file contiene un determinato numero di segmenti. Il formato AFM contiene i dati in uno o più raw file ed i metadata in un file separato che ha la struttura dei segmenti standard. Il formato AFM permette di avere i metadata e di importare i dati grezzi in tool che supportano il formato raw. Con AFM, esiste un file con estensione '.afm' ed i file raw hanno lo stesso nome di base con numeri come estensione.

TSK può automaticamente rilevare i tipi AFF, AFD, o AFM. E' possibile comunque specificarli attraverso la linea di comando con '-i aff', '-i afd', o '-i afm'. Quando è utilizzato uno dei tre formati, dev'essere specificato un solo nome di file alla linea di comando. Con AFF, dev'essere specificato solo il nome del file AFF. Con AFD, dev'essere passato solo il nome della directory e i tool troveranno i file al suo interno. Con AFM, dev'essere specificato solo il nome del file AFM, i tool si occuperanno di trovare i relativi file raw. Il tool 'img_stat' mostrerà i valori MD5 e SHA-1, la grandezza delle immagini, e vari altri segmenti che possono essere definiti dal tool 'aimage' , il tool di acquisizione in AFFlib.

Conclusion

Il supporto a AFF e EWF dovrebbe essere trasparente per l'utente, poiché TSK può rilevare automaticamente i formati immagine. Grazie al lavoro di Joachim, Robert, Simson, e gli altri, TSK può ora essere utilizzato in più situazioni. Versioni future di TSK includeranno tool per la verifica dell'integrità dell'immagine ed il tool 'img_stat' mostrerà più metadata dei file.

References

[1] The Sleuth Kit Informer Issue #19: http://www.sleuthkit.org/informer/sleuthkit-informer-19.html

[2] libewf: http://www.uitwisselplatform.nl/projects/libewf/

[3] AFFlib: http://www.afflib.org

Un'introduzione alla libreria libewf Expert Witness

Di: Joachim Metz, Robert-Jan Mora

Hoffmann Investigations <forensics at hoffmannbv.nl> [1]

Descrizione

Il formato Expert Witness Compression (EWF) è utilizzato da EnCase (Guidance) e FTK (AccessData) per creare immagini complete. EWF è attualmente lo standard de-facto utilizzato all'interno della comunità forense. Questo formato non è documentato completamente e non può quindi essere utilizzato nativamente in Sleuth Kit.

Sleuth Kit include attualmente il supporto in lettura per le immagini in formato Expert Witness Format (EWF). Ciò è ottenuto utilizzando libewf, che è una libreria C open source da noi sviluppata. In aggiunta alla libreria, la distribuzione libewf è fornita anche di tool per esportare i dati da file EWF (ewfexport), mostrare i metadata contenuti (ewfinfo), e verificarne l'integrità (ewfverify). Questo articolo descrive la storia della libreria, le capacità e ne fornisce una panoramica sull'utilizzo in un programma.

Breve storia

Nel 2005, Michael Cohen utilizza le specifiche Expert Witness format [4] per creare una libreria chiamata ‘iowrapper’ che permette a PyFlag [7] la lettura dei file immagine EnCase 4. Il tool 'iowrapper' utilizza le tecniche di library hooking per permettere ai programmi di accedere ai dati nei formati immagine.[6]. Il tool 'iowrapper' supporta i file immagine EnCase 5 solo quando è utilizzato la chunk size di default. Anche se 'iowrapper' era una grande scoperta, noi abbiamo preferito il supporto nativo a EWF all'interno di Sleuth Kit. Di conseguenza abbiamo creato libefw per i correnti e futuri tool open source.

Inizialmente, libewf è stato sviluppato in C e per la macchine Linux i386. Inizialmente abbiamo utilizzato come riferimento il codice di Michael Cohen, ma abbiamo presto deciso di eseguire una completa riscrittura della sua implementazione.

E' apparso subito chiaro che sia le specifiche Expert Witness che il codice in 'iowrapper' non erano completi per la versione corrente del formato. I file immagine creati con EnCase 5, ad esempio, contengono nuovi metadata mai documentati prima.

Nei nostri test abbiamo analizzato versioni differenti di file immagine EWF. Abbiamo trovato differenze rispetto alle specifiche originali. Abbiamo così concluso che le specifiche originali di Andrew Rosen [4] erano superate.

Le più notevoli differenze erano descritte in questo articolo. Sul sito del progetto[3] è stato rilasciato un documento contenente specifiche dettagliate del formato. Questo documento contiene scoperte e deduzioni sul formato EWF. E' da tener presente che è documentazione in sviluppo e può quindi contenere errori. Se trovaste errori o aveste informazioni addizionali sul formato, siete pregati di contattarci attraverso e-mail.

Specifiche

EWF può dividere i file immagine in più file, chiamati segmenti (E01, E02, etc). I dati all'interno dei file sono contenuti in ordine little endian. Il formato utilizza zlib per la compressione.

Ogni segmento inizia con una signature di 8 byte: 0x455646090d0a0ff00. I primi tre byte di questa signature sono “EVF" in ASCII. Questa signature è unica dei file EWF.

Dopo la signature è presente una parte contenente il numero di segmento. All'interno dei file sono presenti differenti sezioni specifiche. Ogni sezione inizia con un header, al quale ci riferiremo per chiarezza come section start. L'inizio della sezione contiene campi che rappresentano:

il tipo di sezione
la grandezza della sezione (64 bit)
l'offset della sezione seguente (64 bit)
un cyclical redundancy check (CRC) dei dati all'interno della section start

Queste sezioni contengono differenti tipi di informazione riguardo il formato EWF. Sono rappresentate dal 'section type' all'interno del section start e sono:

le sezioni “header” e “header2”, che contengono i case data
le sezioni “volume” o “disk” e “data”, che contengono informazioni sul media acquisito
le sezioni “sectors” che contengono i reali dati duplicati
le sezioni “table” e “table2” che contengono informazioni sui dati nella sectors section
le sezioni “next” e “done” utilizzare per segnalare la fine di un segmento
la sezione “hash” che contine l'hash MD5 dei dati duplicati
la sezione “error2” che contiene informazioni sugli errori di lettura durante l'acquisizione.

Le specifiche originali contengono solo le sezioni “header”, “volume”, “table”, “table2”, “next” e“done”. Segue un breve riassunto di due sezioni importanti.

La sezione header

Sia la sezione header che header2 contengono informazioni sul caso, come il nome dell'esaminatore, il numero del caso, evidence number e l'hash della password.

La sezione header consiste in una stringa di testo compressa.

Nella sezione header la stringa contiene valori ASCII.
Nella sezione header2 la stringa contiene valori Unicode UTF16.

Queste stringhe contengono valori separati dal carattere di tabulazione. I valori sono rappresentati da identificatori differenti. I valori nella sezione header di Encase 4 e 5, ad esempio, contengono:

Case number (identified by c)
Evidence number (identified by n)
Unique description (identified by a)
Examiner name (identified by e)
Notes (identified by t)
The EnCase (software) version used to acquire the media (identified by av)
The platform/operating system used to acquire the media (identified by ov)
Acquired date (identified by m)
System date (identified by u)
Password Hash (identified by p)

Solo il primo segmento di file contiene l'header section. L' header section è la prima sezione nel file segment dopo le parti signature e field. Esiste una differenza nell'header section a seconda della versione di Encase utilizzata. Anche i dati all'interno dell'header section differiscono a seconda della versione. Questo può essere verificato nelle specifiche dettagliate.

La hash section

La hash section contiene un hash MD5 dei dati acquisiti. In Encase 4 e 5, queste sezioni contengono anche dati addizionali (16 bytes) dei quali continuiamo a non comprendere cosa rappresentino realmente.

La hash section si trova nell'ultimo segmento, prima della sezione done. La hash section è una sezione opzionale che possiamo escludere. E' unicamente l'hash che permette la verifica dei dati acquisiti, non la verifica dei metadata addizionali come le informazioni del caso nell'header. L'hash può, ad esempio, essere calcolato anche sui deati negli header, sulle informazioni del media e sulle sezioni delle tabelle.

Integrità delle Prove?

Non sempre l'impostazione della password all'interno di Case protegge i dati nei segmenti.. La password è utilizzata unicamente dall'applicazione EnCase. In questo modo solo EnCase può leggere l'hash delle password dalla sezione header. Nell'implementazione di libewf in Sleuth Kit, la password è ignorata.

Il formato EWF consente la protezione da diverse forme di corruzione dei dati. Non permette però la protezione contro la manipolazione. La versione recente di EnCase mantiene il valore hash opzionale.

Questo consente la manipolazione delle prove. Quello che segue è un teorico approccio alla manipolazione dei dati. Pensiamo sia possibile ma non l'abbiamo verificato realmente. Ciò richiede successive analisi, ma penso che sia necessario comprendere come nosn si possa affidarsi completamente alle funzioni di integrità incluse nel formato EWF.

E' possibile modificare le informazioni del caso nella sezione header. L'header contiene diversi valori che può essere interessante modificare. Approccio:

estrarre il payload della sezione header
decomprimere il payload
aggiustare il valore
comprimere i dati modificati
inserire nuovamente i dati compressi nel file

La quantità di dati che è possibile modificare dipende dalla versione di EWF. Per Encase 5, ad esempio, i dati possono essere modificati sia nella sezione header che header2.

Se il nuovo heder è più largo dell'originale, occorre correggere tutti gli offset delle sezioni nel primo segmento. Se il nuovo header è più piccolo è probabile che basti un semplice riempimento. La maggior parte delle volte può comunque bastare la manipolazione di un unico dato:

E' possibile aggiustare l'hash della password, rendendo il file inleggibile in EnCase.
E' pssibile modificare la data di acquisizione che è semplicemente una stringa data nella sezione header e una stringa time stamp nell'header2.

Ciò non è molto grave, finchè i valori sono aggiunti ai dati addizioneli del caso. Come comportarsi però di ffronte alla corte se questi valori sono stati manipolati?

I dati in chunk specifici possono essere manipolati. Possono essere modificati visto che il CRC di chunk specifici può essere ricalcolato ed aggiustato. Questo approccio è più difficile per i chunk compressi, in quanto bisogna aggiornare anche gli offset nella tabella e nelle sezioni. Un approccio per la modifica di un chunk non compresso è:

leggere un chunk dal file
aggiustare i dati
calcolare il nuovo CRC
scrivere i dati ed il CRC nuovamente sul file

Tuttavia se una hash è stato specificato, la manipolazione può essere rilevata. Ciò non è un problema, visto che la sezione hash è opzionale e quindi può essere rimosso completamente. Ciò è veramente semplice:

trovare l'offset iniziale della sezione hash nell'ultimo segmento
rimuoverlo
aggiustare l'offset nella sezione affinchè punti a sé stessa, il valore può essere ottenuto dalla sezione precedente della sezione hash

A parte la rimozieone della sezione hash, è in teoria possibile modificare l'hash MD5 direttamente nella sezione hash. Se è possibile determinare il nuovo hash MD5 per i dati manipolati tutto ciò che occorre fare è scriverlo nella sezione hash.

Un altro più difficile approccio consiste nel determinare dei dati che abbiano l'hash MD5 identico ai dati originali (collisione). L'unica modifica da fare è sui chunks e valori CRC relativi. Gli attacchi di collisione agli hash MD5 sono possibili.

Volendo essere accurati, è possibile anche calcolare l'hash individuale dei segmenti (EWF) utilizzando tools come md5sum e/o sha1sum, al fine di verificare l'integrità dei segmenti.

La libreria

Visto che sono state trovate differenze nelle immagini EWF create da differenti programmi, abbiamo analizzato i file immagine creati delle versioni 1.991, 2.17a, 3.21b, 4.22, e 5.04a di EnCase e da FTK Imager 2.3.

Abbiamo anche testato differenti funzionalità per ciascun programma, incluso differenti livelli di compressione, impostazioni delle password, impostazioni hash, grandezza dei dischi ed immagini intere e frammentate. Abbiamo prestato particolare attenzione ad EnCase 5 e sono stati eseguiti test addizionali con differenti grandezze dei blocchi ed errori sui blocchi.

Questi test ci hanno permesso di determinare i dettagli delle differenti implementazioni del formato immagine. Da questo lavoro libewf può leggere e verificare:

Singoli e multipli segmenti EWF
File EWF compressi e non compressi
File EWF con o senza password
File EWF con o senza hash
File EWF con grandezza chunk differente da 32k
File EWF contenenti immagini estese (fino a 300 Giga bytes)

Libewf è stata sviluppata per supportare piattaforme multiple in modo da poter essere integrata in The Sleuth Kit. Di consegueza supporta diversi ordini endian, sistemi a 64-bit, ed altre piattaforme oltre a Linux.

Libewf supporta le seguenti piattaforme e compilatori:

Linux Fedora Core 4, i386, gcc 4.0.2
Linux Fedora Core 5, x86_64, gcc 4.1.0
Linux buntu 5.10, i386, gcc 4.0.2
Mac OS-X Tiger, G4 Motolora, gcc
Cygwin/Windows XP, i386, gcc
FreeBSD 6.0, i386, gcc 3.4.4
OpenBSD 3.8, i386, gcc 3.3.5
NetBSD 3.0, i386, gcc 3.3.3
SunOS 5.11 / Solaris 11, i386, gcc 3.3.2
Debian 3.1, i386, gcc 2.9.5 and gcc 3.3

Funzionalità della Libreria

Libewf fornisce un facile sistema di interfacciamento che permette ai programmi di aprire i file EWF, leggere i dati e verificarne l'integrità. Quando legge i file immagine, libewf esegue vari test di integrità. In particolare:

che la struttura dei segmenti sia corretta e non esistano offset o valori di grandezza corrotti;
che il valore CRC per le sezioni sia corretto e non esistano strutture dei file corrotti;
che il valore CRC del media sia corretto
che il valore offset dei dati nelle sezioni tabella e tabella 2 siano uguali e non corrotti

Quando nei chunks è incontrato un errore CRC, viene visualizzato un messaggio di avviso. Se vengono incontrati altri errori il codice termina. Uno dei futuri obiettivi da implementare è un metodo più semplice per la gestione degli errori. Oltre all'accesso ai dati contenuti nel formato immagine, la libreria permette anche l'accesso ai metadata, come le informazioni del caso ed i valori MD5.

Sorgenti e dipendenze

Il codice sorgente di libewf è organizzato in più file. E' utilizzata la seguente convenzione:

I file che iniziano per ewf_ contengono definizioni specifiche dell'implementazione EWF, come il layout delle implementazioni di differenti sezioni
I file rimanenti contengono codice riguardante il lavoro delle librerie. Il codice di modifica principale è ad esempio in file.c ed il codice di lettura è in file_read.c.

Il file “libewf.h” dovrebbe essere incluso per l'utilizzo di libewf con altri tool.

Libewf è dipendente da due librerie, che sono presenti di default in molti sistemi:

zlib per supporto (de)compressione
openssl libcrypto per il supporto al calcolo MD5

Il clockwork

In questa sezione diamo uno sguardo su come è possibile sviluppare tool con libewf e descrivere una parte del clockwork interno.

Per leggere da un file immagine bisogna che lo stesso sia prima aperto attraverso libewf_open, che creerà dinamicamente un'istanza della struttura LIBEWF_HANDLE. Questa struttura è utilizzata da altre funzioni libewf per inserire e ricavare dati. Alcune funzioni allocano memoria nella struttura e di conseguenza dovrebbe essere chiusa alla chiusura di libewf_close.

La funzione libewf_open costruisce un array dinamico dei segmenti in un'immagine frammentata, si riferisce alla tabella segmenti e verifica:

Che ciascun file contenga la signature EWF
Che il segment number sia specificato solo una volta

Dopo l'aggiunta di ogni segmento alla tabella viene creata la tabella degli offset. La tabella degli offset è un array dinamico contenente l'offset di ogni chunk all'interno dei segment file. Questo è il processo:

Verifica che non sia tralasciato alcun segment file.
Costruisce una lista delle sezioni in ciascun segmento.
Verifica il valore CRC in ciascuna sezione. Attualmente avvisa se un CRC non è valido ma continua comunque a processare.
Compara le copie di backup dei dati nel formato immagine per assicurarsi che siano consistenti, tuttavia il codice attualmente non corregge gli errori nelle strutture.

Per riportare l'intero media in un descrittore di file, ad esempio per esportare i dati, può essere utilizzata la funzione libewf_read_to_file_descriptor. Questa funzione legge i dati dai file EWF e li riporta in un descrittore di file. Questa funzione permette di specificare una funzione di callback che può essere utilizzata per fornire un indicatore di progressione come in ewfexport.

Per tool come TSK, è richiesta la lettura da posizioni random. A questo scopo può essere utilizzata la funzione libewf_read_random. La funzione convertirà un valore offset nel file segmento in esso contenuto.

libewf_read_random mette da parte i dati di un singolo chunk per migliorare le performarce nella lettura di un gran numero di piccole letture. Come menzionato prima, attualmentem in caso di discrepanza di CRC avvisa solamente. Questo solo quando legge il chunk attuale da un file, non dalla versione cache.

Libewf fornisce ulteriori funzioni per accedere all'MD5 contenuto nei file EWF e calcola l'hash MD5 sui dati del media. Il tool ewfverify utilizza questa funzionalità.

Per accedere ai valori hash MD5, può essere utilizzata la funzione libewf_data_md5hash. Entrambe ritornano una stringa contenente il valore hash MD5.

Il futuro

L'immediato futuro per libewf ne implica la pubblicazione on line. Abiamo creato una pagina di progetto sulla uitwissel platform (translated exchange platform). Il link alla pagine ed alla documentazione corrente può essere rilevato sotto nei riferimenti. Il codice sorgente sarà aggiornato a breve.

I futuri obiettivi sono:

Implementare il supporto in scrittura
Implementare una più agevole gestione degli errori
Estrarre più dettagli dei valori sconosciuti nelle nuove versioni del formato.
Maggiori verifiche dei dati sulla coerenza tra sezioni dati e sezioni volume o immagine
Permettere l'esclusione di alcuni passaggi di validazione per permettere il processo di immagini corrotte o modificate.

Apprezzeremmo commenti sulle specifiche che abbiamo pubblicato in merito a EWF e libewf, sia positivi che negativi. Siamo interessati anche a commenti e relazioni sui file EWF creati da altri tool che non abbiamo potuto analizzare.