Ntfs, fls ed ifind

da www.denisfrati.it

La scorsa settimana eravamo impegnati a testare Sfdumper, per verificare le modifiche che Chupacabra (in vero spirito open source) sta apportando al codice al fine di pulirlo e renderlo più performante.

In particolare lavorando su una immagine realizzata da Brian Carrier per i test, ci siamo accorti che non eravamo in grado di rilevare alcuni file cancellati.
L'immagine in questione è in formato ntfs.
Le verifiche venivano portate avanti lavorando in parallelo con Autopsy, in modo da controllare il corretto funzionamento di quei tools facenti parte dello Sleuth Kit, che avevamo implementato in Sfdumper.
Personalmente trovo Autopsy uno strumento particolarmente utile a fini didattici, in quanto la consultazione dei log relativi al caso/host, contemporanea all'utilizzo delle funzionalità della GUI, consente di comprendere il funzionamento "segreto" del tool, o meglio, di tutti quei tools che in esso sono implementati.
I log permettono di identificare i comandi e le opzioni utilizzate per ottenere un determinato risultato.

In particolare analizzando il contenuto del log "unknown.exec.log", ci si è accorti che quando dal browser si navigava all'interno di una directory, il suo contenuto veniva listato attraverso i due seguenti comandi:

'/usr/bin/fls' -f ntfs -lau -s '0' -o 0 -i raw 'immagine.dd' 30

'/usr/bin/ifind' -f ntfs -l -p 30 -o 0 -i raw 'immagine.dd'

(per facilitare la comprensione/lettura ho sostituito con "immagine.dd" il percorso al link immagine contenuto nel log "/var/lib/autopsy/test_im_carrier/host1/images/b.dd" )
Il primo comando lista il contenuto (solo i file non cancellati, vedasi opzione u) della direcory identificata dall'inode 30, ma il secondo cosa fa?
La sua funzione è spiegata da Carrier nel numero 16 dello SleuthKit Informer.
Qui l'autore dell'STK, ci spiega che nei file system NTFS (e non solo) quando si ha un file allocato, il suo nome punta all'indirizzo dove possiamo trovare i meta-dati ad esso relativi, nella $MFT. Cancellando un file, il nome può essere sovrascritto, portando alla perdita del link tra il percorso assoluto dello stesso ed il file.
Questo rende complicato determinare quale file era collegato ad una entry sulla $MFT che ora risulta non allocata e, visualizzando il contenuto di una directory, mostrare i file cancellati.
Il comando "ifind" con il flag "p" e l'indicativo della directory di interesse, consente di cercare tra tutte le entry non allocate che puntano alla directory indicata.

Spero che la spiegazione non sia troppo illeggibile :-( , fortunatamente ci viene in aiuto l'esempio pratico:
se volessimo visualizzare il contenuto della directory

d/d 104711-144-5: Documents and Settings/baginov/Dati applicazioni/DNA

contraddistinta dall'inode 104711, potremmo usare il comando

$ sudo fls -f ntfs -a -s '0' -o 63 /dev/sda 104711
d/d 104711-144-5: .
d/d 40045-144-6: ..
r/r 47907-128-1: dht.dat
r/r 71403-128-1: resume.dat
r/r 15504-128-1: resume.dat.old
r/r 46291-128-4: settings.dat
r/r 105644-128-4: settings.dat.old

possiamo notare l'assenza di file cancellati, usualmente identificati dall'asterisco (r/r * 123456-128-1: pippo.txt).
La sorpresa viene quando lanciamo il comando ifind con il flag p:

$ sudo ifind -f ntfs -o 63 -p 104711 /dev/sda
-/r * 105650: resume.dat.old

che ci permette di individuare una entry non allocata, relativa al file resume.dat.old, che punta alla directory da noi indicata.

Durante una analisi non è pensabile di lanciare il comando per ogni singola directory presente nel file system.
Ho quindi realizzato un semplice script (Ifinder), che partendo dall'elenco delle directory presenti, ottenuto tramite "fls -Dr ecc...." cerchi eventuali entry non allocate che puntano ad ogni una.
Lo script non è assolutamente interattivo, tuttavia basta aprirlo con un editor di testo ed editare i valori assegnati alle variabili relative a:

• offset del primo settore del file system;
• percorso e nome dell'immagine/device;
• percorso e nome dei file di output.

Non aspettatevi che lo script sia veloce, per analizzare una partizione NTFS da 25 G, contenente 7770 direcorty ha impiegato circa 21 minuti.

nemo@nexus:~/Scrivania/ifind$ sudo ./ifinder.sh
ricerca avviata mer apr 30 05:06:11 CEST 2008
ricerca completata mer apr 30 05:27:52 CEST 2008

Tuttavia, a meno di voler esplorare tutte le directory del file system attraverso Autopsy, o di avere precise indicazioni/sospetti sul contenuto di una in particolare, usando software open source non credo si abbiano molte altre possibilità.
L'elenco dei file cancellati, individuati in tal modo (da sommarsi eventualmente a quelli precedentemente individuati con fls) è contenuto nel file da voi assegnato alla variabile $file_cancellati.

Tornando al test eseguito sulla partizione da 25 G, i file individuati erano 4:

-/r * 105650: resume.dat.old
-/r * 105611: parent.lock
-/r * 105642: sessionstore.js
-/r * 105612: permdata.box

a questo punto sarebbe stato sufficiente lanciare icat quattro volte ed il recupero era effettuato.
Quanto si sarebbe impiegato ricorrendo al carving? meno?
Anche ipotizzando che sommando questi 25 minuti (tra ricerca [21] e recupero), al tempo impiegato da Sfdumper per effettuare un recupero selettivo, si superi il tempo impiegato da foremost, non dobbiamo scordare che operando con due script rimaniamo in possesso dei percorsi e dei nomi dei file, talvolta utili ed indicativi al fine di velocizzarne l'analisi.
La semplicità dello script permette con estrema facilità di filtrare le ricerche (grep) in base al nome delle directory e/o all'estensione dei file da recuperare.

Prossimamente lavoreremo per integrare Ifinder.sh in Sfdumper, valutando probabilmente di farlo eseguire su precisa scelta, visto il tempo impiegato per l'esecuzione.

Per utilizzare lo script è sufficiente assegnargli i permessi di esecuzione

# chmod +x ifinder.sh

lanciandolo con

# ./ifinder.sh

Lo script va lanciato da utente root solo nel caso si desideri operare sui dischi di sistema.

Ifindersh.zip md5: cafa512b372d5dd4c1e4a04a86bc7e25