sfdumper
Febbraio 21st, 2008
Qualcuno avrà notato questa mia assenza di quasi venti giorni.
Accantonati gli altri impegni, come l’articolo sulla virtualizzazione, mi sono impegnato nel progetto “sfdumper”.
Sfdumper, acronimo per Selective File Dumper, nasce dalla necessità di procedere al recupero di file da immagini forensi, o da device, in modo selettivo.
Per chi opera con software commerciali per Windows, probabilmente questo non è un grosso problema. Tools quali EnCase e FTK, dividono già i file rinvenuti per tipologia, se non erro (non avendoli mai utilizzati mi baso su quanto sentito raccontare).
Per chi opera da piattaforma *nix, il discorso è un poco differente.
Autopsy permette di individuare i file di una data estensione e i file cancellati, ma talvolta, su grosse moli di dati, l’interfaccia grafica tende a rallentarsi oltremodo, sino a bloccarsi (almeno questa è la mia esperienza). Inoltre l’estrazione dei file deve avvenire manualmente, uno alla volta, il che richiede tempi piuttosto lunghi.
Lo SleuthKit, i tools alla base di Autopsy, dei quali è l’interfaccia grafica, permettono di intervenire in modo molto potente e selettivo sui files contenuti in un dispositivo/immagine, ma per far ciò è necessario avere una certa confidenza con i differenti tools che lo compongono e con le loro opzioni.
Foremost rappresenta un validissimo ausilio, ma consegna all’utente un insieme di file senza nomi “human readable”, che non si sa se fossero attivi, cancellati o altro.
Tutto ciò impone al forenser che si ostina ad utilizzare Linux ed i tools per esso disponibili, un lavoro piuttosto lento.
Un valido ausilio è rappresentato dagli script per la shell, che però possono perdere di validità se realizzati ad hoc per i singoli casi.
Dal confronto con Nanni Basseti su queste problematiche è nata l’idea di sviluppare un tool che agevolasse l’operato dei forenser Linux lover, che consentisse di lavorare risparmiando tempo e che permettesse ad utenti con minor confidenza con Linux di operare con una discreta autonomia.
Sfdumper è il nostro primo script. Mentre per Nanni la programmazione rappresenta anche un lavoro, per me queste sono le prime righe di codice dopo diversi anni, inoltre la realizzazione di script per la bash è una novità per entrambi, quindi non ci aspettiamo di aver sviluppato del codice elegante ed ottimizzato.
L’idea è quella di lavorarci ancora, per migliorarlo anche grazie ai suggerimenti degli utenti.
Il tool oltre che per la forensics, può essere utilizzato per il semplice data recovery, di cui ogni utente di computer può aver necessità.
I requisiti per utilizzare Sfdumper sono l’avere installato lo Sleuth Kit, Foremost, sha256deep, grep, awk, sed e dd (gli ultimi quattro usualmente già presenti sui sistemi GNU/Linux).
Abbiamo cercato di inserire tutti quei controlli, di per se ovvi, sull’esistenza del file da analizzare, delle directory di output, sulla ripetizione delle operazioni.
Il principale problema è stato definire la tipologia di immagine dd (parlando da forenser preferisco considerare l’utilizzo di sfdumper sulle sole immagini e non direttamente sui device) sulla quale si andava ad operare, al fine di comprendere se si trattava di quella di un device, di una partizione, se era presente un file system e se questo era supportato dallo Sleuth Kit.
Nel caso si operi su immagini, o parti di esse, in cui non è presente un file system (aree non allocate), o questo non è supportato dallo Sleuth Kit (ReiserFS, HP, ecc..), si permette di effetuare data carving, con foremost, di una specifica tipologia di file.
Se il file system presente è supportato dallo Sleuth Kit si può operare al recupero dei file, di una specifica tipologia (da estensione e non da headers), referenziati dal file system, attivi e cancellati, e successivamente al data carving. In tal caso si procede alla successiva eliminazione dai file carvati di eventuali doppioni dei file referenziati. Ciò consente di avere tra i rimanenti carvati solo quei file cancellati e non referenziati dal file system.
Può essere questo il caso in cui si operi sull’immagine di un file system reinstallato, dove tra i file recuperati con il carving avremo solo quelli riferiti alla precedente installazione e non referenziati dal nuovo file system.
In entrambi i casi, sia che si sia fatto solo data carving, sia che si siano recuperati anche i file referenziati, sarà possibile effettuare la ricerca di stringhe nei file recuperati.
Tale operazione viene svolta con il semplice utilizzo di grep. Le prove svolte hanno evidenziato come alcune tipologie di file, ad esempio i file del word processor di OpenOffice trasformati in pdf, siano impermeabili alla ricerca di stringhe.
Nella directory di output si avrà quindi una directory “report” contenente il Sfdumper main_log.txt e gli elenchi dei file referenziati attivi, cancellati e irrecuperabili, suddivisi per partizioni (o meglio aree come definite dall’output di mmls) ed estensione ricercata.
I file referenziati, attivi e cancellati, recuperati avranno il nome definito dall’inode corrispondente e dal proprio nome, comprensivo di percorso. La presenza di spazi e degli slash del percorso rappresentavano un problema per la definizione del nome, gli spazi sono quindi stati sostituiti con l’underscore, mentre gli slash dal “-”.
Sarà poi presente una directory per ogni estensione ricercata, il cui nome permetterà di riconoscere l’area esaminata e l’estensione ricercata.
Al suo interno tre directory conterranno i file attivi, cancellati e carvati.
Se l’operatore svolgerà ricerche di stringhe nei file in questione, nella directory si troverà anche il file di log riportante i risultati della ricerca.
Nel caso si sia operato su immagini che non contengano più aree/partizioni il nome di file/direcory sarà definito solo dal termine “image” e dall’estensione ricercata.
Il file di log contiene la registrazione di tutte le operazioni svolte e del percorso in cui si trovano i diversi file recuperati, gli elenchi degli stessi ed i report dei file che fanno match con le stringhe eventualmente ricercate.
Ci tenevo ad evidenziare quella che secondo me è una feature piuttosto carica: se con foremost non si specifica un file di configurazione, questi opera potendo recuperare i file di estensioni inserite nel suo builtin, visionabili nella pagina del manuale. Una quantità maggiore di file è recuperabile personalizzando il file di configurazione.
Abbiamo quindi inserito in coda allo script gli headers ed i footer dei formati di file presenti nel file di configurazione, che nel caso tali tipologie siano ricercate, permettono a Sfdumper di crearsi un proprio file di configurazione da utilizzare con foremost.
Ciò permette, tra le altre cose, all’utente che disponga di un proprio foremost.config, ottimizzato con in base alle proprie esperienze, di integrarlo con facilità nel nostro script.
Se anzi lo desiderate potete inviarci altri herders e footer affinchè ci sia possibile inserirli nelle prossime versioni.
Il carving successivo al recupero dei file referenziati, ricercati per estensione, ci consente di recuperare anche quei file ai quali sia stata cambiata l’estensione.
Questi pur sfuggendo al recupero dei referenziati (fls -F -r -f file_system_type -o offset image| grep formato) ricercati in base all’estensione, cadono tra le braccia di foremost che li individua dall’headers/footer recuperandoli, se non allocati in cluster non contigui.
Abbiamo testato Sfdumper per quanto possibile, siamo tuttavia certi che l’utilizzo reale evidenzierà eventuali errori, motivo per il quale vi preghiamo, nel caso decidiate di testarlo, di riportarci i vostri commenti e suggerimenti.
Sfdumper, tradotto in inglese, può essere scaricato dalla sua pagina su Sourceforge.
Per utilizzarlo è sufficiente assegnargli i permessi di esecuzione
# chmod +x sfdumper.sh
e lanciarlo
# ./sfdumper.sh
Uno dei possibili utilizzi è ad esempio la veloce ricerca di evidence sul campo.
Ci troviamo in fase di perquisizione presso i locali del sospetto. Il magistrato, o le forze dell’ordine vogliono un immediato riscontro, obbligandoci ad una preview.
Non mi soffermo sulla discutibilità di tale procedura, ma le esperienze di chi opera sul campo confermano che sono situazioni che si verificano, quindi possiamo parlarne con realismo.
Possiamo avviare il pc sospetto (con le dovute cautele) con una distro live per la forensic, montare la partizione e metterci a cercare quanto desiderato sfogliando il sistema con il file browser.
Oppure possiamo avviare il pc con la distro live, montare un device esterno su cui raccogliere le evidence e lanciare Sfdumper.
In breve la directory di output si popolerà con i file della tipologia ricercata, che potremo visionare scegliendoli in base al nome, conservato, o in base al matching con le stringhe ricercate.
L’eventuale immediato riscontro ci permetterà di valutare le successive operazioni (sequestro, ecc…).
Buon utilizzo
Aggiornamento 4 marzo 2008
Abbiamo realizzato una versione con interfaccia grafica basata su Zenity, la descrizione è qui.
Leave a Reply