sabato 20 dicembre 2008

NBSTEGO - bash script for steganography

Non so perchè, ma mi sono dedicato all'evoluzione di BrutalStego, ho scritto, infatti, un nuovo bash script, che fa realmente una steganografia di un testo, lo cripta in AES256 e lo nasconde in esadecimale nel file vettore.

La cosa che mi interessava era poter criptare il testo, nasconderlo e poterlo rilevare tramite immissione di password, insomma un tool di steganografia reale!

Strumenti usati:grep, awk, dd, bc, wc, xxd, openssl

In sostanza funziona così:si inserisce il nome del file vettore, si inserisce il nome del nuovo file (quello contenente il messaggio segreto), si inserisce il messaggio ed infine si inserisce la password.Dopo questi input, il programmino cripta con OpenSSL in AES256 il messaggio segreto, poi lo converte in esadecimale e lo posiziona all'interno del nuovo file vettore.
L'ho testato sulle JPG e sugli MP3 e non si nota alcuna perturbazione.
Rilanciando il programmino, si può andare a svelare il messaggio segreto, inserendo il nome del file vettore e la password
Ecco lo script:

#!/bin/bash
# NBStego - by Nanni Bassetti - http://www.nannibassetti.com - nannib@libero.it
# a simple steganographic tool for Linux. Tested on  JPG, MP3, AVI
# It uses AES256 algorithm by openssl


hid ()
{


echo "Insert the message to hide:"
read ms
echo $ms>ptext
echo "Insert the file where to hide:"
read fl
echo "Insert the file name of the new file:"
read nfl
echo "Insert your password:"
read pw
# here it crypts the plaintext in cyphered text by aes25 and save it into steg.bin
openssl aes-256-cbc -in ptext -out steg.bin
# password length
lenpw=$(expr length "$pw")
lenpw_mod=$(echo 0 + 10 | bc)
# temp1.bin is the head of the new file
dd if=$fl of=temp1.bin bs=1c count=$lenpw_mod
# temp2.bin is a 10 bytes file filled of zeroes to store the secret message length
dd if=$fl of=temp2.bin bs=1c skip=$lenpw_mod count=10
# temp2.bin is the end of the new file
dd if=$fl of=temp3.bin bs=1c skip=$(echo $lenpw_mod + 10 | bc)
dd if=/dev/zero of=temp2.bin count=10 bs=1c
# hex conversion of steg.bin
cat steg.bin | xxd -p > steghex.bin
# len is the length of the steghex.bin file
len=$(wc -c steghex.bin|awk '{print $1 }')
# hex conversion of len
echo $len | xxd -p > l.bin
# it builts the new file
cat temp1.bin l.bin temp2.bin steghex.bin temp3.bin > $nfl
rm temp1.bin
rm temp2.bin
rm temp3.bin
rm steg.bin
rm steghex.bin
rm ptext
rm l.bin
echo " "
echo " -------------------------- "
echo " "


}
#-----End Hide-----



reveal ()
{
echo "Insert the file name containing the secret message:"
read nfl
echo "Insert the password:"
read pw
lenpw=$(expr length "$pw")
lenpw_mod=$(echo 0 + 10 | bc)
len=$(dd if=$nfl skip=$lenpw_mod bs=1c count=10 | xxd -r -p)
# it finds the openssl aes256 signanture into the target file and it takes the offset
sk=$(grep -iaob -m 1 "53616c746564" $nfl | awk -F ":" '{print $1}')
dd if=$nfl bs=1c skip=$sk count=$len status=noxfer | xxd -r -p | openssl aes-256-cbc -d -out text.txt -k $pw
cat text.txt
}


echo "NBSTEGO by Nanni Bassetti - 2008-12"
echo "Choose if you want to hide or to reveal:"
echo "1) Hide"
echo "2) Reveal"
read answ1
case $answ1 in
     1)  hid ;;
     2)  reveal ;;
     *)  echo "Wrong answer! Write 1 or 2"
      echo " ";;
    esac
exit


Clicca qui per il DOWNLOAD

sabato 6 dicembre 2008

Linux Live distro ma quante ne porto?

Siamo ormai nel 2009, tutto si è evoluto, tutto è veloce e potente, ma la Giustizia italiana?
Quella rimane lenta, lentissima, ci sono cause iniziate nel 1998, che devono ancora finire e che magari richiedono ancora delle perizie.
Come attrezzarsi?
Potremmo trovarci di fronte a macchine Intel 386 se non 286, senza porte USB, senza lettori di CD-Rom, senza BIOS che permettano il boot da CD-ROM, con pochissima RAM, l'unica cosa positiva sarebbe la dimensione dell'hard disk da repertare, che probabilmente sarebbe di pochi megabytes.


A volte, anche le macchine "moderne", possono avere dei problemi di incompatibilità, con le Linux Live distro, perchè qui stiamo, chiaramente, parlando di usare una Live, per svariati motivi, e non di staccare l'hard disk e collegarlo alla nostra workstation, che sarebbe la soluzione ottimale per ovviare ad ogni questione.


Quindi nel nostro zainetto da bravo consulente tecnico informatico non dovrebbero mancare mai, secondo la mia personalissima classificazione, live distro come:

LIVELLO ALTO - Boot da Cd-Rom, ideali per i sistemi moderni, dotate di ottime interfacce grafiche.

Helix 2, CAINE, FCCU 12.1, ForLexDeft 4.1


LIVELLO MEDIO - boot da CD-ROM - sono più leggere e possono girare senza interfaccia grafica.


FCCU 11 o 10, F.I.R.E., IRItaly, PHLAK, Knoppix-STD, DSL


LIVELLO BASSO - boot da Floppy - partono da floppy disk e girano sui dinosauri informatici


SMART Linux, MuLinux, Floppix


Inoltre non sarebbe male portarsi sempre dietro il cd di GPArted e un rescue cd come Trinity, SystemRescueCd e un linux net-oriented come BackTrack.


Troppe? ;)
Bhè sono convinto che nei comments ne appariranno altre : - P

lunedì 1 dicembre 2008

Anti-Forensics alcune tecniche di base

Ho appena finito di leggere un interessante articolo di Mark Whitteker su ISSA Journal, che riassume alcune tecniche di base dell'anti-forensics, trovo questo genere di articoli molto costruttivi, perchè non dicono niente di nuovo, ma servono ad accorpare e sintetizzare dei concetti, cosa che è utile, specialmente in un settore così ricco di tecniche da dover ricordare.


Cos'è l'anti-forensics? Si tratta di tutti quegli escamotages, che servono a mettere in difficoltà i "digital investigators", in modo da riuscire ad occultare o a rendere estremamente diffcile il reperimento di evidenze digitali.


I tipi di anti-forensics possono suddividersi in tre grandi branche:



  • Data Hiding (occultare i dati)

  • Tool's weakness (debolezze note dei tool per la computer forensics)

  • Investigator's weakness (debolezza dell'investigatore)


DATA HIDING


I dati possono essere nascosti in moltissimi modi e non solo sull'hard disk in esame, ma anche su siti web di storage, qui potete trovare una trattazione di Mario Pascucci in merito ad alcune tecniche, ma esaminiamo quelle più comuni e conosciute:



Encryption


Criptare interi volumi o solo dei file , può essere quanto di più facile da mettere in atto, ma diventa uno degli ostacoli più duri per l'investigatore digitale, perchè un criptaggio con AES (Advanced Encryption Standard) a 128 bit ha 2128 possibili chiavi, con un brute force attack non si giunge a niente, se non in un tempo lunghissimo (parliamo di anni) di elaborazione costante e parallela.
Quindi, in questo caso, conviene che l'investigatore, cerchi la password in altra maniera, tipo cercare nella memoria del sistema (ram dumping) l'eventuale password inserita, se è presente in qualche file leggibile, avendo un log di un eventuale key-logger pre-istallato oppure con un profiling dell'indagato, ma sono tentativi veramente legati alla speranza ed alla fortuna, se per esempio la password è una parola di senso compiuto, magari basterà un dictionary attack e lo scrigno si aprirà.


Steganografia


Dal Greco antico "scrittura nascosta", è una tecnica nota per nascondere delle informazioni dentro altri file binari, per esempio immagini, file mp3, ecc.
Personalmente ho sviluppato un strumentino a fini didattici, che fa capire come può avvenire una steganografia banale: BrutalStego o una più complessa con NBSTEGO.
Ci sono tanti strumenti per la steganografia come: JHide, Digital Invisible Ink e tanti altri che potete leggere qui.
I sistemi per capire se un file contiene della steganografia sono basati su algortimi probabilistici, infatti spesso danno falsi positivi e falsi negativi, tutto ciò non può essere utile all'investigatore, a meno di non aver trovato tracce di programmi di steganografia sul PC dell'indagato, altrimenti diventa una caccia alla cieca.


Spazio non allocato e cancellazione sicura


Questo è lo spazio non occupato da file attivi, infatti quando un file viene cancellato da sistema, di fatto rimane fisicamente in uno spazio marcato come "unallocated", quindi disponibile alla scrittura di altri file.
L'operazione di cancellazione standard, serve solo ad eliminare il pointer al file dalla File Allocation Table (FAT) or Master File Table (MFT).
Con i tools di computer forensics, si riescono a recuperare dei file cancellati (pubblicità occulta FUNDL o SFDUMPER), ma se prima di cancellarli si riempiono i file di careatteri random o di zeri, alla fine non si recupera più il file originale.


SLACK SPACE


I file quando sono salvati vengono allocati in cluster, gruppi di settori del disco, ma se un file occupa 5 cluster e mezzo, viene allocato in sei cluster, lasciano mezzo cluster libero.
Ci sono strumenti come Metasploit’s Slacker utility che permettono di scrivere nello slack space, ossia quello spazio avanzante di un cluster, se poi si cripta il file e lo si inserisce nello slack space, l'investigatore può esser tratto in inganno, trovando solo dei dati che possono sembrare spazzatura di precedenti file allocati in quel cluster, quando invece è un file criptato.


TOOL'S WEAKNESS


Altre tecniche di anti-forensics, possono risedere nello sfruttare bachi o debolezze note dei più famosi tool per la computer forensics.
Gli ADS (Alternate Data Streams), oggi non più una minaccia.
La MD5 collision, ossia il poter modificare un file e far risultare lo stesso hash MD5 del file originale, questo può servire per occultare un file e spacciarlo per un file noto, quando l'investigatore effettua una ricerca usando il matching di un dizionario di hash MD5 noti sui file contenuti sul disco in esame.
La modifica del Timestamp, con questa tecnica si possono ingannare i tool che creano una timeline basata sui tempi di MAC (Modify, Access e Create file).
La manipolazione del magic number e dell'estensione dei file, questa tecnica è abbastanza fastidiosa per gli investigatori, perchè se si cambia solo l'estensione di un file, per esempio da JPG a DOC, i programmi di carving (Foremost, Photorec, Scalpel, ecc.) ed i programmi come "file" o "TridNet", se ne accorgono, perchè considerano gli headers ed i footers del file (nel caso della JPG sono FFD8 e FFD9 in esadecimale), ma se si cambiano anche i gli header ed i footer, si imbrogliano anche quest'ultimi tool, quindi va fatta un'ispezione accurata e manuale!


LA INVESTIGATOR'S WEAKNESS


Questa è, secondo me, la tecnica più problematica, infatti si condensa in un semplice concetto, ossia il tempo e le risorse che deve impiegare l'investigatore per analizzare i supporti sequestrati.
Basta avere dischi di parecchi gigabyte o terabyte, Raid, usare tecniche di data hiding e a quel punto le analisi da condurre porterebbero via moltissime risorse in termini di tempo e denaro, costringendo l'investigatore a lavorare alla grossa.
Questo è una riflessione che mi ero posto molte volte, quando leggevo di tutte le tecniche "fini" di anti-forensics, mi domandavo spesso:
"Ma se un consulente tecnico riceve da analizzare 10-100 hard disk da 250Gb l'uno, come può mettersi a lavorare di fino, su ogni hard disk, controllando eventuali criptazioni, steganografie, slack space, file nascosti negli spazi tra MBR ed inizio partizione, partizioni nascoste, file system dentro file system, ecc. ecc.?"


Conclusioni


Penso che sia utile conoscere più metodi possibili di data hiding, però credo sempre nel motto "è più facile occultare che scoprire"


Nanni Bassetti

venerdì 14 novembre 2008

BrutalStego, steganografia semplice ma efficace


Per divertirmi mi sono chiesto, cosa succederebbe ad un'immagine JPG o ad un MP3 se inserissi del codice esadecimale o del testo al loro interno, senza un orientamento ben preciso, insomma una steganografia manuale.
Quindi ho deciso di provare a tradurre in esadecimale una frase:


$ echo "ciao mondo! Uffa sempre questa come frase esempio :)" xxd -p

6369616f206d6f6e646f2120556666612073656d70726520717565737461
20636f6d65206672617365206573656d70696f203a290a

Ottenendo la conversione in esadecimale della frase, poi aprendo con un editor esadecimale una JPG ho provato ad incollare il suddetto codice, partendo dall'offset 11 (in decimale), salvo l'immagine modificata e provo a visualizzarla...tutto ok! L'immagine non presenta alterazioni visibili. :)


Se faccio l'operazione inversa:
$ echo "6369616f206d6f6e646f2120556666612073656d70726520717565737461
20636f6d65206672617365206573656d70696f203a290a" xxd -r -p
ciao mondo! Uffa sempre questa come frase esempio :)


Quindi ho pensato di automatizzare il procedimento di steganografia ed è nato bsteg.sh che riporto qui:



#!/bin/bash
# BrutalStego - by Nanni Bassetti - http://www.nannibassetti.com -
nannib@libero.it
# a simple steganographic tool for Linux
echo "Insert the message to hide:"
read ms

echo "Insert the file where to hide:"
read fl
echo "Insert the file name of the new file:"
read nfl
echo $ms | xxd -p>steg.bin
len=$(wc -c steg.bin)
dd if=$fl of=temp1.jpg bs=1c count=11
dd if=$fl of=temp2.jpg bs=1c skip=11
cat temp1.jpg steg.bin temp2.jpg > $nfl
len=$(wc -c steg.bin|awk '{print $1 }')
echo "Mesg lenght: "$len" for revealing the hidden message you have to cut from 11 to "$len
echo "dd if="$nfl" bs=1c skip=11 count="$len" | xxd -r -p"
rm temp1.jpg
rm temp2.jpg
rm steg.bin
echo " "
echo " -------------------------- "
echo " "
dd if=$nfl bs=1c skip=11 count=$len status=noxfer | xxd -r -p


Lo script funziona così:
1) Chiede il messaggio da nascondere
2) Chiede il nome del file si vuol nascondere il messaggio
3) Chiede il NUOVO nome del file alterato (così da non sovrascirvere l'originale)
4) Crea un file "steg.bin" che contiene il messaggio codificato in esadecimale
5) Calcola la lunghezza del file steg.bin
6) Ritaglia la "testa" del file dove si andrà a nascondere il messaggio, la testa è dal byte 0 al byte 11
7) Ritaglia il resto del file dal byte 11 in poi
8) Concatena e salva nel file nuovo i pezzi: testa + steg.bin + restante_del_file
9) A video ci dice qual'è la lunghezza del messaggio codificato e ci mostra la decodifica, per dimostrare che tutto è andato bene.


Alla fine, a qualcuno basterebbe avere la lunghezza del messaggio codificato es. "112" e sapendo che deve cominciare dal byte 11, con un semplice editor esadecimale o con un dd dovrebbe tagliare la parte da 11 a 112 del file per ottenere il messaggio originale.


Testato su JPG e MP3 e tutto funziona benissimo....chiaramente ci si può sbizzarrire parametrizzando anche il punto di partenza, che non deve essere necessariamente 11.
Un esempio per passare la lunghezza all'amico che dovrà decodificare il messaggio?


"Ciao, ma con tutto il casino che hai combinato ieri dovevamo chiamare il 112? : - D"


Facile no? ;)


FKLook - cerca keyword e copia i file

ecco il mio nuovo nato FKLook trattasi di uno script bash per Linux, che vi permette di cercare le keyword in una directory piena zeppa di file e copiare tutti quelli che la contengono in una directory di vostra scelta, in modo tale da avere un repository di file selezionati in base alla keyword.
Testatelo!
ciao

# /bin/bash/
# File Keywords searching tool by Nanni bassetti http://www.nannibassetti.com - nannib@libero.it
echo "#########################################"
echo "FKLOOK - by Nanni Bassetti http://www.nannibassetti.com - nannib@libero.it"
echo "by this script you can search for a keyword in many files"
echo "and it copies only the files those match with the keyword, in a separated directory you chose"
echo "########################################"
echo " "

echo "Write the output directory where you to save the files (eg. /media/myfiles):"
read outdi
data=$(date | sed 's/ //g' | sed 's/://g' | sed 's/[[:alpha:]]//g')
mkdir $outdi$data
outdir=$outdi$data
echo "This is the directory for your repository: ".$outdir
echo "Write directory contains the files where you want to looking for the keyword:"
read indir
echo "Write the keyword search:"
read key
grep -aR -i $key $indir/*.* > $outdir/filelist.txt
fn="$(cat $outdir/filelist.txt | awk -F ":" '{print $1}'|sed 's/*//')"
cp $indir/$fn $outdir 2>/dev/null
cd $outdir
ls -l

venerdì 31 ottobre 2008

CAINE V0.3


Annuncio l'uscita di CAINE v0.3
- Aggiunti: libewf-20080501, afflib-3.3.4.
- Aggiornato TSK 3.0 (ricompilato).
- Sistema aggiornato con l’ultimo kernel.
- Corretto un bug a SFDumper di adattamento al sistema CAINE
Adesso CAINE ha lo Sleuthkit ed Autopsy ricompilati per il riconoscimento delle immagini AFF e formato ENCASE.
http://www.caine-live.net/page5/page5.html

lunedì 27 ottobre 2008

CFI - Linux Day Modena 2008

Oggi sono molto contento, perchè sia il Linux Day di Reggio Calabria dove hanno partecipato i CFIini:

Gianni Amato, Loris Borgese, Achille Foti

è andato benissimo, da quel che mi dicono, vi è stata una platea interessata ed interattiva...

Il Linux Day di Modena con:
Nanni Bassetti, Denis Frati, Giancarlo Giustini e Giordano Lanzi
è andato lo stesso benissmo, abbiamo conosciuto il professor Michele Colajanni, il ricercatore Mauro (scusami non ricordo il cognome) dell'Università di Modena, persone disponibilissime ed aperte a futuri progetti e collaborazioni.

Grande interesse è stato mostrato sin dal mio intervento introduttivo su CFI (Computer Forensics Italy) e sulle Best Practices forensi, con tante domande che stimolavano il dialogo.

Poi è stato il turno di Giancarlo Giustini, che ha presentato la Linux Live DistroCAINE, la prima al MONDO a montare lo Sleuthkit 3.0 e Autopsy 2.20 e tutti gli altri tool aggiornati (Photorec, testdisk, foremost, ecc.), inoltre contiene ancheFUNDL, SFDumper e LRRP tool sviluppati dal sottoscritto e Denis Frati.
Su questa presentazione, c'è stato molto interesse, personalmente sono stato ORGOGLIOSO del lavoro di Giancarlo, perchè ci abbiamo messo tutti noi un pò di competenza e idee e questo ci è stato riconosciuto a gran voce più volte e per questo li ringrazio tanto....ho avuto, ancora una volta il piacere di respirare una sana aria di collaborazione, condivisione di conoscenza, senza gare di celodurismo, ma con una voglia ed un entusiamo positivo e costruttivo....bello, bello, bello!

Infine ha chiuso i lavori Denis, con una serie di slides "piccanti", : - ) ma molto interessanti, perchè ha spiegato, parecchi motivi per cui Linux è una buona scelta per la digital forensics.

Molto spazio di Q&A (Domande e Risposte), la platea è stata veramente incuriosita, tanti complimenti e richieste....poi ci siam tutti separati.

La sera, mi hanno portato a cena a Modena, ho mangiato da cavia della Danone per il Danacol, (non capisco come facciano in Emila-Romagna con le arterie!) : - D

Speciali ringraziamaneti a: Giordano Lanzi, Francesco Allertsen, Federico, Mauro per la bella compagnia!

Speriamo, che questo cammino intrapreso da CFI, vada avanti, per adesso abbiamo messo le bandierine su: Modena, Roma e Reggio Calabria...http://www.cfitaly.net/italiacfi

sabato 18 ottobre 2008

Grep e Strings due giganti di Linux


Il tempo libero serve anche a sperimentare e quando si ha la passione per la computer forensics, son dolori....


Tramite Nigilant32 (presente nella parte Live di Helix 2) faccio l'immaginedella Ram del mio PC, mentre è in uso, e la salvo sul file RAM.IMG.


ram.img - dump della mia ram 1.3Gb


Tramite editor esadecimale, vedo che tra le tante stringhe, contenute nel file, ne prendo una a casaccio per fare il mio test, la stringa è "awatarami".
Cerco con strings e il parametro -t d (che mi genera anche l'offset in decimale) ottenendo:



strings -t d ram.img | less
33593  Skype z awatarami


Quindi segno l'offset come: 33593


Poi cerco con grep ed i parametri
-i ignora il maiuscolo/minuscolo;
-a tratta il file binario come se fosse testuale;
-b stampa il byte offset;
-o Mostra solo la parte di linea che coincide con la stringa cercata;


grep -iabo awatarami ram.img
4923:awatarami


Segno l'offset: 4923
Ho cercato la parola "awatarami" ed ho ottenuto due offset diversi....ma qual'è quello giusto?
Passo all'uso di xxd (editor esadecimale da riga di comando) e con -s lo faccio partire dall'offset trovato:


 xxd -s 4923 ram.img | less
00133b: 0366 2e0f 011e 1203 662e a10c 0090 9090  .f......f.......
00134b: 9090 9090 9090 9090 900f 22d8 662e a1ec  ..........".f...
00135b: 0266 0bc0 7403 0f22 e066 2ef7  0604 0002   .f..t..".f......
00136b: 0000 0074 1666 b980 0000 c00f 3266 0d00  ...t.f......2f..
00137b:  0800 0066  b980 0000 c00f 3066 2e8b 2e10  ...f......0f....
00138b: 0066 2e8b 0eac 0066 2e8b 1ee8 0266 2ea1  .f.....f.....f..
00139b: e002 662e 8b3e 0800 0f22 c066 ea20 456e  ..f..>...".f. En
0013ab: 8008 0000 0000 0000 0000 0000 0000 0000  ................
0013bb: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0013cb: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0013db: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0013eb: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0013fb: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00140b: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00141b: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00142b: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00143b: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00144b: 0000 0000 0000 0000 0000 0000 0000 0000  ................


Non c'è traccia della parola "awatarami"....
Provo con l'offset ottenuto da strings:


xxd -s 33593 ram.img | less
08339: 2053 6b79 7065 207a 2061 7761 7461 7261   Skype z awatara
08349: 6d69 204b 6c6f 6e69 6573 2e3c 6272 2f3e  mi Klonies.

08359: 3c61 2068 7265 663d 2273 6b79 7065 3a3f 
08389: 5374 77c3 b372 7a20 4b6c 6f6e 6965 3c2f  Stw..rz Klonie08399: 613e 0050 6f6b 61c5 bc20 c59b 7769 6174  a>.Poka.. ..wiat
083a9: 7520 7377 c3b3 6a20 5765 654d 6565 2e3c  u sw..j WeeMee.<


quindi strings mi fornisce l'indirizzo corretto, mentre grep no! 
Errata corrige: (col grep aggiornato funziona invece)
Ne parlo con Mario Pascucci e lui mi suggerisce questa soluzione al dilemma, ossia che grep ha tutto un altro modo di ragionare con i caratteri e potrebbe interpretare erroneamente i caratteri di controllo
e soprattutto fare confusione con i caratteri multibyte, ossia interpretare sequenze di caratteri come multibyte, quando invece sono tutt'altro, e contarli come uno solo.


Un mistero è risolto!
Ma su questi due strumenti NON ho finito di lavorarci, quindi, armato di cronometro ho fatto questo esperimento:


grep -iaob mustafa /cygdrive/c/immaginidd/barbuto.dd
tempo: 52 secondi e 50 centesimi - offset corretto 113917010


$ strings -t d /cygdrive/c/immaginidd/barbuto.dd | grep -i mustafa
113917010 tuo fratello Mustafa
tempo: 29 secondi e 84 centesimi - offset corretto 113917010


Insomma strings in pipe con grep è molto più veloce (il 51% in più).


Sempre consultandomi con Mario, mi suggerisce una spiegazione, che avevo intuito anch'io e che fa capire la potenza dell'operatore "pipe" (|) e di Linux.
Le ragioni della lentezza sono molteplici, ma una su tutte:
strings ha un algoritmo infinitamente più semplice e veloce di grep, e la quantità di dati che estrae è esigua, per cui il secondo grep, il cui input è generato da strings, ha molto meno input da esaminare.


Per avere conferma di ciò, basta mandare l'output di strings su un file, e vedere che è immensamente più piccolo del file intero su cui strings ha lavorato.
inoltre ci sono altre ragioni, fra cui il fatto che grep è costruito per cercare in file di testo, suddiviso in righe, e con un set di caratteri ben definito, e passsandogli un binario, come appunto un'immagine dd, non è che lo aiuti molto.
Strings invece produce un output molto vicino a quello su cui grep offre le prestazioni migliori.


In sostanza, strings estrae le stringhe da un file binario e passa il suo output in pipe a grep, che opererà la ricerca della parola "mustafa", su un output testuale e ridotto, sfruttando al massimo la sua potenza.


La stessa sperimentazione la si può fare usando queste immagini.


Nanni Bassetti


lunedì 13 ottobre 2008

EVENTI CFI - AUTUNNO 2008

Con immenso piacere annuncio a tutta la community CFI la ns pagina degli eventi:

http://www.cfitaly.net/italiacfi

da qui potete vedere sia gli eventi passati sia quelli in fieri....

Per il 25/10 abbiamo:
http://www.conoscerelinux.it/Members/pigio/linuxday-2008/linuxday-2008/
a Modena (Bassetti, Frati, Giustini, Lanzi), con presentazione di CAINE
http://www.caine-live.net/

poi Gianni Amato, Achille Foti e Loris Borgese e forse Calogero Bonasia su Reggio Calabria:
http://rclug.linux.it:80/eventi/linux-day/2008

Insomma ringraziando la disponibilità dei LUG, CFI sta, pian pianino, mantenendo la promessa, di muovere la conoscenza sul territorio nazionale....speriamo di continuare così e col contributo di TUTTI....Grazie!!

giovedì 2 ottobre 2008

CAINE: A new open source live distribution for digital forensics


CAINE: A new open source live distribution for digital forensics
Sviluppata da: Giancarlo Giustini, Mauro Andreolini, Michele Colajanni
E-mail: ing.giustini@gmail.com, mauro.andreolini@unimore.it, michele.colajannig@unimore.it
Department of Information Engineering University of Modena and Reggio Emilia
SITO WEB: http://www.caine-live.net

Nella versione in sviluppo è stato inserito anche Selective File Dumper (SFDumper)
Qual'è la diversità di CAINE? L'idea NUOVA è sulla creazione del report automatico, dopo aver effettuato tutte le operazioni, di acquisizione, analisi, comandi da terminale ecc., l'interfaccia permette di creare un report con tutti i log files delle operazioni fatte ed in più permette di aggiungere delle note ed una personalizzazione.

Ma non solo questo....CAINE si differenzia dalle altre distro, per la facilità d'uso, l'uso di un'unica GUI (interfaccia grafica) che permette il lancio dei vari tool ed una buona usabilità del tutto.
E' poco dispersiva, facile da usare, svincolando così l'operatore da ciò che spaventa tanti, ossia la difficoltà di operare con Linux e con le sue Terminal Windows
Questo è quanto mi ha colpito di più...ma magari Giancarlo ha da aggiungere qualcosa che mi è sfuggito ;)
La distro è stata presentata alla OSSConf2008 SITO: http://www.caine-live.net

Helix 2 è finalmente tra noi!


Ho appena provato Helix 2 sul mio laptop Acer 1694 Centrino M760 con 1250Mb di Ram.
Boot: 6 minuti =8-O
Piacevole sorpresa è INSTALLABILE!
Una volta dentro noto:
1) Ottimo il configuratore di rete wireless ed ethernet
2) Manca Air ma c'è Adepto.
3) I menù sono messi bene, noto subito una facile usabilità degli strumenti
4) RegViewer come al solito....non funziona...appena seleziono un file di
registro ...sparisce il tool.
5) Ophcrack richiede un percorso per le rainbow tables...che nn son riuscito
a trovare...forse nn ci sono
6) Per il resto sembra molto carino ;)

Parte Windows:
ben fatta....

molti tool utili specialmente per il dumping della RAM
un utile WinAudit tool per sapere di tutto del sistema Windows sul quale si sta operando
un tool chiamato USB Deview per visualizzare tutti i dispositivi USB che sono e che sono stati attaccati almeno una volta al PC analizzato.
Un Disk Manager con possibilità di lock sui dischi.
Un Pre-Search tool per la ricerca e la preview veloce delle immagini
L'ho provato sulla workstation con 1Gb di Ram e Intel Pentium Dual Core + Hd Sata e Hd PATA.


Boot: 2.5 minuti
Piacevole novità il mio hard disk SATA viene visto, mentre con la 1.9a no!


www.e-fense.com/helix/

Virtualizzare Windows con VirtualBox




Spesso si parla di creare una macchina virtuale sotto Linux, al fine di lanciare
un altro sistema operativo "virtualizzato", spesso questo sistema è rappresentato da Windows.
Il concetto è semplice, si crea una macchina virtuale, con un suo hard disk virtuale e su di esso si installa Windows come se fosse un'installazione normale, chiaramente, nella macchina
virtuale bisogna attivare il dispositivo CD-Rom, in modo da poter inserire il cd di Windows.
Una volta installato il sistema operativo di Microsoft, rimane il problema di come farlo
comunicare col sistema host di Linux, per sfogliare le directories condivise ad esempio.
Ma tra la teoria e la pratica, come al solito, c'è sempre qualche difficoltà, dato che, al fine di sfogliare la rete e vedere le cartelle condivise, bisogna configurare sia Linux sia le connessioni di rete del sistema virtualizzato.
Qui descrivo la mia esperienza con Virtualbox (http://www.virtualbox.org/) se qualcuno ha qualcosa da aggiungere o da correggere non esiti a scrivere i commenti....perchè questo è un tipico frutto di prova ed errore!

Prima di tutto bisogna creare un file shell tipo questo:

tunctl -t vbox0 -u nbs
chmod 666 /dev/net/tun
brctl addbr br0
brctl addif br0 eth0
ifconfig br0 192.168.1.100 netmask 255.255.255.0
brctl addif br0 vbox0
ifconfig vbox0 up
ifconfig

Oppure inserire questi comandi nel file /etc/network/interfaces

Se si decide di creare il file, lo nominiamo, ad esempio, vbox.sh.
In questo esempio ho usato l'indirizzamento 192.168.1.x, si noti che la mia scheda di rete di Linux è configurata con indirizzo IP 192.168.0.222 e gateway 192.168.0.1, quindi il bridge che si va a creare con questo script appartiene ad una sottorete diversa.
Cosa fa lo script:
tunctl - crea e gestisce un'interfaccia TUN/TAP persistente
Tratto da Wikipedia:
"Nelle reti Informatiche, TUN e TAP sono driver che permettono la creazione di periferiche di rete virtuali. Rispetto alle comuni periferiche (ad es. eth0) che sono controllate direttamente dalle schede di rete, i pacchetti spediti da o verso dispositivi TUN/TAP sono spediti da o verso programmi software. TUN è in grado di simulare una periferica di rete di tipo punto-punto e lavora con pacchetti di tipo IP mentre TAP è in grado di simulare un dispositivo Ethernet e logicamente utilizza i frame Ethernet."
chmod 666 /dev/net/tun - setta i diritti di lettura e scrittura per tutti gli utenti sul device virtuale
brctl addbr br0 - crea un bridge virtuale. Il bridge è un dispositivo di rete che riesce a smistare i pacchetti tra sottoreti anche differenti.
brctl addif br0 eth0 - rende l'interfaccia di rete eth0 una porta del bridge, insomma si pone in modo da poter smistare i pacchetti provenienti da eth0
ifconfig br0 192.168.1.100 netmask 255.255.255.0 - configura l'IP e la netmask del bridge
brctl addif br0 vbox0 - come per eth0 solo che lo fa per vbox0.

A questo punto lanciamo Virtualbox (nel quale abbiamo già creato la macchina virtuale con Windows installato), ed andiamo nei settings di rete.
Qui configuramo una scheda di rete (che comparirà sotto Windows), come Interfac Host, Mac adress assegnato da Virtualbox e nome interfaccia Vbox0.




Poi configuriamo una seconda scheda di rete e la mettiamo in modalità Nat.



Adesso mandiamo in running la macchina virtuale.

Stiamo su Windows.

Vedremo due schede di rete attive, quella col Nat, che avrà un indirizzo IP assegnato e che ci permette di navigare sul web e quella che dovrebbe permetterci di sfogliare le cartelle condivise di Linux.

Ma per farlo devo disattivare la Nat, non so perchè, ma solo così funziona.
Facciamo un passo indietro.
Sotto Linux devo aver installato il Samba, il samba-common ed il demone nmbd.
Dopo aver installato questi pacchetti devo abilitare l'utente con il comando:
sudo smbpasswd -a nomeutente_che usate_per_Linux
sudo smbpasswd -e nomeutente_che usate_per_Linux

Per guardare altre configurazioni di Samba, si può dare un'occhiata al file:
/usr/share/apps/samba/smb.conf

Poi prendete una cartella di Linux (es. /home/nomeutente/Documenti) e sceglite l'opzione "Condivisione", a questo punto da Windows virtualizzato, si dovrebbe poter sfogliare la rete e arrivare alla cartella Documenti, condivisa sotto Linux.
Buna virtualizzazione!

Links:
http://guide.debianizzati.org/index.php/Condivisione_risorse_con_Samba
http://samiux.wordpress.com/2007/07/11/bridge-network-interface-on-virtualbox/

FUNDL per Win32

Ecco qui la versione di FUNDL - File Undeleter, tool basato su lo Sleuthkit per Linux, finalmente per Windows 32:
DOWNLOAD
In sostanza si tratta di un ripping dell'ambiente CygWin, che ho fatto con le mie manine, portandomi appresso i file necessari per far funzionare il tutto.Sfrutta lo Sleuthkit 3.0.0b4 (adesso è disponibile TSK 3.0) col nuovo FLS che risolve i problemi di recupero dei file orfani....insomma con questo si recuperano tutti i files cancellati!
Si parte con START.BAT
Il percorso del file immagine deve essere sempre scritto così:
/cygdrive/LETTERA_VOLUME/Dir_file_immagine/file.dd
LETTERA_VOLUME sarebbe C o D ecc. ecc.
Fatemi sapere se funzia bene Grazie!

PICCOLI TOOL

Nella digital forensics c'è sempre bisogno di strumenti e idee nuove....
Qui mi son limitato a creare tre piccoli tool, che forse non hanno nemeno un'utilità, però, almeno da un punto di vista didattico, possono esser validi:
FUNDL - File Undeleter - Trattasi di un file bash shell per Linux, (richiede l'uso dello Sleuthkit), che serve a recuperare tutti i files cancellati da un disco o da una sua bitstream image. Qui la Windows version.
JPG_Builder - Trattasi di un bash shell script per Linux, che inserisce l'header ed il footer binari di un'immagine JPG in un file. Questo può servire per tentare di ripristinare qualche JPG corrotta alla quale mancano l'header e/o il footer.
Spywarino - Questo è un programmino per Windows, che sfrutta i pre-compilati di dd, nc per duplicare bit a bit, un disco in rete LAN, senza che il proprietario del disco se ne accorga (chiaramente un monkey user). Utile per duplicare il disco di qualcuno e poi analizzarlo con tutta calma. ;)
Bhè sono tre toollini divertenti...ripeto non so quanto utili...forse FUNDL è quello più utile...ma sicuramente da sviluppare meglio....comunque hanno un valore didattico.

LA FAUNA DELLA COMPUTER FORENSICS

Di Admin (del 16/09/2008 @ 09:07:53, in Computer Forensics, linkato 207 volte)
Come si misura la competenza?
Negli ultimi tempi si è dibattuto parecchio su quello che serve per poter parlare, insegnare o operare nella computer forensics e a mio vedere sono uscite varie realtà:

A) I MEGALOMANI: prima solo di pronunciare le parole "computer forensics" devi:
1) Aver fatto un numero vicino al diametro di Giove di CTU e CTP! Scherzi a parte è un numero ed è sempre imprecisato....forse volutamente....se ne hai fatte 5,10, 100 non si sa ...c'è sempre quello che dice che son poche...la qualità di queste CT? Mha!...non conta...per questi della categoria A, contano solo le "misure" (potremmo ribattezzarli i pornodivi). 2) Devi aver dibattuto in tribunale, sempre per un numero di volte imprecisato, contro gli avvocati più temibili del pianeta, quelli clonati dalle cellule di Bill Gates e Linus Torvald, con un'iniezione di DNA di Perry Mason ed un pò di DNA di cane lupo, insomma figure mitologiche o estremamente rare.
3) Devi aver fatto anni ed anni (sempre per un numero imprecisato) di apprendistato con i grandissimi (grandi è troppo poco) della CF, in pratica quei 4 gatti più famosi, che dovrebbero aprirsi un residence per ospitare tutti i loro apprendisti....ah certo se fai affiancamento ad uno NON conosciuto dai MEGALOMANI, non hai fatto niente....perchè anche chi lavora da anni nel settore non è nessuno se non è "riconosciuto" da uno di loro.
4) Devi aver pranzato, cenato e preso l'aperitivo con un numero imprecisato di PM! Attenzione non basta parlare coi PM, bisogna avere quasi un rapporto intimo, per potersi fregiare di essere un CT completo.
5) Per concludere, devi avere qualche certificazioncina internazionale, completamente inutile, ma che fa tanto fico!

B) I SUPERFICIALI:
1) Categoria diffusissima specialmente in Italia, loro prendono tutto, insegnano, prendono le CT, ne hanno anche tante (per la felicità dei megalomani), ma magari non sanno nemmeno cos'è un codice hash o che il copia ed incolla non è "forense".
2) Loro hanno sempre a che fare con questi "rarissimi" (ironico) AVVOCATI normali, che non capiscono una mazza di Best Practices. e di informatica e che le loro perizie non le contestano mai.
3) Sono tantissimi e spesso si rivolgono ai Megalomani o agli Studiosi (categoria che vedremo in seguito), per chiedere consigli.
4) Tendono spesso ad usare i tool di c.f. più semplici e più costosi, ma di fronte a parole come "offset", ti guardano in maniera interrogativa.

C) GLI STUDIOSI:
1) Categoria poco diffusa, composta da persone che hanno varie esperienze informatiche, hanno studiato molto, usano le best practices e quello che hanno fatto o detto è sempre stato circostanziato e dimostrato o dimostrabile.
2) Hanno poche consulenze, dovute non ad imperizia, ma a opportunità della vita, però quelle poche son sempre state fatte con tutti i crismi e qualità.
3) Hanno la passione per la divulgazione, scrivono sul web, nei forum, sui magazine cartacei, magari si autopubblicano ed hanno un feedback positivo da tantissima gente.
4) In genere non dicono o scrivono cose inesatte (per quanto sempre esseri umani sono), però vengo attaccati dalla cat. A (i megalomani), senza motivi reali o tecnico/scientifici.
5) Già il fatto di aver studiato, scritto, fatto delle CT, ecc. li differenzia da moltissimi altri informatici comuni, NON è da tutti farsi pubblicare sulle riviste, anche se in certi settori ristretti semba essere una cosa normale....Loro per tutto il resto del mondo, e sono tante persone, sono degli esempi, perchè tanti sono informatici, ma pochi hanno fatto anche UNA sola CT o hanno pubblicato qualcosa.
6) Hanno sempre un gran successo quando parlano in pubblico o insegnano, sempre feedback positivi da parte di pubblico eterogeneo, non vengono quasi mai attaccati sui FATTI, ma sempre su concetti fumosi.
7) I loro nemici giurati sono i megalomani, quest'ultimi non sopportano, che qualcuno, che non faccia parte del loro giro, sia ammirato, senza essere mai stato nemmeno una volta a cena con Brian Carrier.....ma che scandalo!Ah però se Brian Carrier o Grundy fanno al "paria" dei complimenti....i megalomani glissano su questo... ;)

CONCLUSIONE:

La computer forensics in Italia è variegata, è fatta da tante realtà diverse, spesso cambiano da procura a procura di città in città.
Alla fine, quelli della categoria B sono quelli che vanno meglio di tutti, lavorano tanto, sono nell'ombra, attingono dalle categorie A e C e nessuno li critica.
Sì perchè quelli della categoria A tendono ad attaccare ferocemente quelli della C, ma a dare dei buffetti paterni a quelli della B, che invece dovrebbero incarnare tutto ciò che loro odiano. Ma chissà cosa odiano realmente quelli della A, forse odiano chi diventa più popolare di loro e non chi fa REALMENTE male il lavoro di CT.

Penso che se uno segue, con rigore scientifico e passione le best practices, si tiene sempre aggiornato, si mantiene sempre sul tecnico, sarà un buon CT, a prescindere dal numero delle sue consulenze....i bit non chiedono i curricula....e l'esperienze sono sempre diverse!
Uno può aver fatto 100 CT a cercar file JPG cancellati....ed un'altro ne ha fatte 5 tutte diverse, tutte con problematiche difficili da risolvere....chi vale di più? Uno può anche non averne fatta nemmeno una di CT però studia e simula nei propri laboratori le casistiche più comuni e quelle più strane....alla fine se riesce ad estrarre i dati da un hard disk di un amico o del proprio laboratorio (chiaramente applicando le best practices), perchè non dovrebbe riuscirci durante una CT? (parlo di un discorso squisitamente tecnico)
Il metodo quello è!
RICORDIAMO che la computer forensics è una disciplina INTELLETTUALE e non sportiva.....l'allenamento e l'esperienza si fanno STUDIANDO, anche da casi gestiti da altri, fa tutto bagaglio di esperienza, magari da sfruttare quando ci si troverà in casi similari.....è tutto nella mente, non nei muscoli!

domenica 14 settembre 2008

INDAGINI DIGITALI

Questo è un vademecum, un prontuario, sulle procedure e le casistiche, che possono accadere durante un'indagine informatica. Non è il solito libro di computer o digital forensics per tutti, ma è rivolto agli operatori del settore, ai formatori, come insieme di linee guida e procedure da seguire durante l'individuazione, l'acquisizione, l'analisi ed il reporting.
Un manuale per diventare degli Sherlock Holmes digitali!
http://www.lulu.com/content/1356430

Convegno CFI - LUSPIO resoconto finale

Il convegno è stato bello lungo dalle 9.30 a quasi le 15:30, gli argomenti sono stati molto interessanti e tecnici, anche nello specifico....


Per non parlare della parte legale curata da Francesco Paolo Micozzi e Giovanni Battista Gallus, che sono riuscito a seguire poco (causa aereo), ma sapevo di cosa avrebbero parlato, un grande Giancarlo Cucinotta, che ci ha fatto vedere delle slides fenomenali su analisi sui microprocessori, addirittura forensics sui trasponder delle chiavi delle automobili, ecc. ecc. SPETTACOLO!

Gianni Amato è stato tartassato dalle domande del pubblico....

Un grande Mario Pascucci con uno "nascondino dei bit" intrigante ))

Infine me e Denis Frati che abbiamo parlato di CFI e B.P.A breve avremo le slides in linea e ,non so quando, anche il filmato che la LUSPIO ha fatto ....

In ogni caso è un passo importante nella storia di questo gruppo e speriamo serva a farne altri...in tante città...perchè detto tra noi....MINKIA CHE SFACCHINATA!!!!DDDDDGRANDE TEAM!ciao (scusate l'adrenalina) ;)
Ecco il report completo:

FOREMOST ed i suoi segreti

Molti di voi sapranno cos'è Foremost, il più famoso "carver" nell'ambito del recupero dati e della computer forensics, ma per chi non lo sapesse:Foremost è un programma da console per recuperare i file in base alle loro intestazioni, footers, e le strutture dati interne.
Questo processo viene comunemente denominato data carving.Foremost è in grado di lavorare su file immagine (bitstream), come quelli generati dai dd, Safeback, Encase, ecc, o direttamente sul dispositivo.Gli headers ed i footers possono essere specificati da un file di configurazione o è possibile utilizzare parametri della riga di comando per specificare i tipi di file built-in.
Originariamente sviluppato da parte degli US Air Force Office of Special Investigations e dal The Center for Information Systems Security Studies and Research, attualmente Foremost è Open Source ed è mantenuto da Jesse Kornblum, Kris Kendall, and Nick Mikus.
Quando questo fantastico programmino viene lanciato, crea nella directory di output un file "audit.txt" ed una serie di sottocartelle nominate col tipo di file ricercato (es. jpg, doc, tiff, ecc.).
All'interno di queste cartelle ci sono i files "carvati", ossia estratti in base al loro "magic number" presente negli headers e nei footers, questi files sono quelli attivi, quelli cancellati e anche quelli non-allocati.Dato che Foremost agisce sulla parte dati del dispositivo da analizzare e non considera il File System,(ecco perchè si può usare per recuperare i dati dai supporti formattati), i files trovati non avranno il nome, ma saranno nominati con l'indirizzo del settore sul quale sono allocati, che moltiplicato per l'offset dà l'indirizzo assoluto sul dispositivo, sia i nomi dei files sia i loro offset sono scritti nel file AUDIT.TXT.Ecco un esempio:

Foremost version 1.5.2 by Jesse Kornblum, Kris Kendall, and Nick MikusAudit FileForemost started at Fri Mar 28 11:59:15 2008Invocation: foremost usb.ddOutput directory: /home/nemo/immagini_dd/outputConfiguration file:
/usr/local/etc/foremost.conf
------------------------------------------------------------------
File: usb.ddStart: Fri Mar 28 11:59:15 2008
Length: 962 MB (1009254400 bytes)
Num Name (bs=512)
Size File Offset Comment0:
0: 00000611.jpg 11 KB 312832
1: 00000643.jpg 8 KB 329216
2: 00000675.jpg 3 KB 345600
3: 00000707.jpg 9 KB 361984
4: 00000739.jpg 8 KB 378768
-------------------------------------------------
il nome rappresenta il settore in cui si trova il file.esempio per il primo filenome_file=611 >> il settore in cui si trova, il cui offset è 611*512=312832 dove 512 bytes è la misura minima del settore.
L'offset ci indica l'indirizzo assoluto in bytes sul disco, quindi 611 settori sono equivalenti a 312832 bytes.
nemo@nexus:~/immagini_dd$ xxd -s 312832 -l 512 usb.dd
004c600: ffd8 ffe0 0010 4a46 4946 0001 0100 0001 ......JFIF......
004c610: 0001 0000 ffdb 0043 0005 0304 0404 0305 .......C........
004c620: 0404 0405 0505 0607 0c08 0707 0707 0f0b ................
004c630: 0b09 0c11 0f12 1211 0f11 1113 161c 1713 ................
004c640: 141a 1511 1118 2118 1a1d 1d1f 1f1f 1317 ......!.........
004c650: 2224 221e 241c 1e1f 1eff db00 4301 0505 "$".$.......C...
004c660: 0507 0607 0e08 080e 1e14 1114 1e1e 1e1e ................

Da un'analisi di Andrea Ghirardini è emerso, che per supporti di grandi dimensioni Foremost non riesce a scrivere il numero del settore corretto.
Quando Andrea ne parlò sospettammo subito in una limitazione di qualche variabile, notando che tutti i files carvati avevano il nome composto sempre di 8 + 3 caratteri (nome+estensione), ed infatti dopo molti giorni di passione, i curatori di Foremost risposero ad Andrea, confermando il fatto che se il nome del file non può superare gli otto caratteri, il bug è causato da un integer overflow che comporta un errato calcolo.

SELECTIVE FILE DUMPER (sfdumper)

http://sfdumper.sourceforge.net
Il sottoscritto, insieme a Denis Frati, ha sviluppato un tool che faciliterà la ricerca dei files per tipologia o meglio per estensione (es. .doc o .jpg).
Infatti per cercare tutti i files di un certo tipo e poi salvarli diventa abbastanza complicato o manuale.
Grazie allo Sleuthkit ed Autopsy si possono cercare i files con una certa estensione, nel file system, ma poi bisogna esportarli manualmente nella cartella REPERTI, stesso dicasi per i files cancellati ed infine col FOREMOST si effettua un carving, con conseguente duplicazione tra i files “carvati”, di quelli già estratti in precedenza (attivi e cancellati), infine si potrebbe effettuare una ricerca per stringhe/keywords sul set di files che si sono salvati usando Sleuthkit e foremost.
Tutte queste operazioni portano via moltissimo tempo e vanno fatte manualmente.
Ecco che abbiamo pensato a scrivere questo bash script SFDUMPER.SH che fa tutte le operazioni su descritte automaticamente ed inoltre elimina i file carvati doppioni dei files cancellati e attivi estratti con lo Sleuthkit.
Lo script è interattivo, lavora sulla partizione che chiede di scegliere, partendo da un file immagine o direttamente dal dispositivo (es. /dev/sdb).
Download ed informazioni su:
http://sfdumper.sourceforge.net

Online i filmati del convegno

Grazie all’Università S. PIO V ed al paziente lavoro di Nanni Bassetti, sono disponibili i filmati (320×200) degli interventi tenuti per il convegno di CFItaly dello scorso 18 giugno:http://www.cfitaly.net/filmati
Salve a tutti!
Benvenuti nel mio nuovo blog.....spero di riorganizzare al meglio tutta l'informazione che ho prodotto nel corso degli anni, con una piattaforma migliore.... ;)

giovedì 19 giugno 2008

Convegno CFI - LUSPIO resoconto finale

Il convegno è stato bello lungo dalle 9.30 a quasi le 15:30, gli argomenti sono stati molto icfilogonteressanti e tecnici, anche nello specifico....
Per non parlare della parte legale curata daFrancesco Paolo Micozzi e Giovanni Battista Gallus, che sono
riuscito a seguire poco (causa aereo), ma sapevo di cosa avrebbero parlato,
un grande Giancarlo Cucinotta, che ci ha fatto vedere delle slides fenomenali su
analisi sui microprocessori, addirittura forensics sui trasponder delle
chiavi delle automobili, ecc. ecc. SPETTACOLO!
Gianni Amato è stato tartassato dalle domande del pubblico....
Un grande Mario Pascucci con uno "nascondino dei bit" intrigante : - )))
Infine me  e Denis Frati che abbiamo parlato di CFI e B.P.
A breve avremo le slides in linea e ,non so quando, anche il filmato che la
LUSPIO ha fatto .... : - )
In ogni caso è un passo importante nella storia di questo gruppo e speriamo
serva a farne altri...in tante città...perchè detto tra noi....MINKIA CHE
SFACCHINATA!!!!
: - DDDDDD
GRANDE TEAM!
ciao (scusate l'adrenalina) ;)

venerdì 15 febbraio 2008

ANCORA UN’INDAGINE FORENSE

Che fare quando nel 2008 ti chiamano per un’indagine informatica? 

La prima cosa che ti domandi è: 
“Ma cosa dovrò acquisire? Come dovrò attrezzarmi?” 

Chiaramente sono domande paragonabili agli interrogativi filosofici sui massimi sistemi ed in genere ricevono risposte onomatopeiche a suoni tipo “Bho?”. 
Però questa volta c’è una novità, ti invitano a presenziare al sequestro, al fine di effettuare, professionalmente, il prelievo dei supporti informatici presenti. 

Siamo nel 2008 è già il piccolo investigatore informatico immagina terabytes di hard disk da acquisire, macchine RAID, 200 PC di cui 150 sono accesi e magari hanno sistemi crittografici e tutto questo rende le notti prima della data dello “sbarco” più dure della fatidica notte prima degli esami. 

Ma bisogna farsi coraggio e procedere per passi, quindi subito scrivere una checklist di cose da fare il giorno del sequestro: 

CHECKLIST 
1) Controllare se i PC sono accesi. 
1.1) Verificare che non vi siano volumi criptati (in caso affermativo chiedere passwords e/o analizzare live). 
1.2) Spegnerli col distacco dell'alimentazione. 
2) I PC spenti si sequestrano: perchè serve avere il PC per leggere orario BIOS ed eventualmente capirne l’architettura degli hard disk (es. se sono RAID). 
3) Domandare: 
3.1) Ci sono altri dati su altri supporti oltre i PC (es. cd-rom, pendrive, hd esterni), backup (196/03). 
3.1.1) In caso affermativo sequestrare. 
3.2) Chiedere eventuali passwords e/o buste con le passwords come da D.Lgs. 196/03. 
3.3) Ci sono software proprietari che usano per l'elaborazione dati? 
3.4) Ci sono connessioni internet per trasmissioni dei dati che ci interessano? 
3.4.1) In caso affermativo c'è connessione dedicata? (oppure chiedere il provider es. Wind, telecom, ecc. e relative password ed username) 
3.4.2) Ci sono software proprietari di trasmissione? 
3.4.3) Ci sono dati memorizzati su host remoti? 
3.5) Ci sono Fax/Stampanti con memoria? 
3.5.1In caso affermativo sequestrare o vedere in loco. 
4) Domandare fattura, documentazione varia per capire la tipologia degli hard disk. 
5) In caso di mancanza di risposte sulla tipologia degli hard disk: 
5.1) Spiegare che si andrà ad aprire per motivi tecnici: capire la capienza e la tipologia degli hard disk. 
5.2) Indossare i guanti in lattice (per elettricita statica/non lasciare impronte), scaricarsi da possibile elettricità elettrostatica, aprire il “case”, leggere l'etichette dei dischi ed eventualmente fotografare/videoregistrare tutto. 
5.3) Spiegare che non si sta alterando alcun dato ma solo leggendo delle etichette. 
6) Imballare tutto e portare via. 
7) Fissare una data per l'acquisizione (duplicazione) dei supporti. 

Questa lista è di massima e sarebbe utile controllarla ed aggiornarla a seconda del caso che si andrà ad affrontare. 

Arriva la data, si partecipa insieme alle forze dell’ordine, forte della tua nomina di ausiliario di P.G. (Polizia Giudiziaria), si attende che qualcuno entri nell’ufficio sorvegliato e si pensa di vivere in un film (bhè a chi non è del mestiere fa questo effetto….). 
Finalmente si entra e mentre i militari si presentano ed espletano le formalità del caso, l’occhio adrenalinico del computer forenser, scruta affamato in cerca di computers, palmtop ed ogni diavoleria elettronica, covando segretamente la speranza di trovare un piccolo PC con un piccolo hard disk. 

Ci sono solo due PC uno portatile e l’altro fisso (desktop), sul portatile c’è un’etichetta su stampigliata la misura dell’hard disk …wow solo 40Gb…uno è fatto! 

Poi si guarda e si riguarda il PC Desktop, ricordando la famose frase di Michelangelo “perché non parli!”, infatti il monolite metallico non riporta alcuna indicazione su quanti Gigabyte custodisce nel suo disco rigido, questo implica un’apertura del case e conseguente metamorfosi di un militare, in novello Spielberg ,che dovrà riprendere il guantato investigatore digitale mentre, armato di cacciavite e torcia alla CSI, si appresta a violare l’intimità del mostro d’alluminio. 

Dopo un quarto d’ora di speologia informatica, finalmente la torcia riesce ad inquadrare la stampigliatura dei GigaBytes sull’hard disk, solo 100Gb!!! Inoltre è un semplice disco IDE, molti incubi hardware svaniscono… 
Qualcuno potrebbe domandarsi come mai non si è semplicemnte acceso il computer per capire la dimensione dell’hard disk? 
La risposta è semplice: perché NON si fa! Il computer sospetto non va mai acceso se non dopo averlo privato dell’hard disk, in modo da non compromettere l’integrità dei dati in esso presenti. 

In attesa della convocazione per il giorno della duplicazione dei dischi, si appronta la workstation di lavoro, che, al minimo, dovrebbe essere così composta: 
Cpu abbastanza potente 
Due hard disk, uno col sistema operativo o più sistemi operativi (es. Linux e Windows) ed uno vergine pronto ad ospitare le copie o file immagini degli hard disk suspect. 
Almeno 1 Gb di Ram 
Almeno un bay per inserire l’hard disk suspect senza aprire la workstation. 
Un lettore ed un masterizzatore DVD 
Porte USB 2.0 
Porte FireWire 
Scheda di rete ethernet 
La scheda wi-fi, la scheda video e quella audio non hanno importanza particolare. 
Mainboard con controller SATA ed IDE. 


Dopo innumerevoli giorni, finalmente si è convocati per la duplicazione dei supporti, ci si sveglia di buon ora, si carica l’automobile con la seguente attrezzatura: 
Workstation priva di tastiera e monitor (useremo quelli della caserma), ma il mouse sì…non si sa mai… 
Case per hard disk esterni dotato di adattatore IDE e SATA con uscita USB 2 e E-SATA. 
Case per hard disk da 2.5” (quelli dei portatili) con uscita USB 2.0. 
Adattatore Ide 2.5” a Ide 3.5” per acquisire l’hard disk del portatile direttamente dal rack della workstation. 
Laptop con tutta la tua vita dentro….(non si sa mai). 
Cavi vari (alimentazioni, doppie prese, usb, firewire, ecc.) e set di cacciaviti e pinzette. 
Guanti in lattice 
Videocamera. 

Tutto per fugare ogni problema…ma tanto si userà solo la workstation, il cacciavite e l’adattatore ide 2.5” – 3.5 “, i guanti e la videocamera. 

Arriva il proprietario dei computer ed il suo legale, rigorosamente non accompagnati da un CTP (tecnico di parte), costringendo l’investigatore della procura a sgonfiarsi come un palloncino forato, infatti egli s’era preparato alla pugna, armato di tutte le risposte e pronto a demolire il suo, probabilmente, “incompetente” avversario, ma questa tenzone non sa da fare…. 

Dopo un estrazione, paragonabile ad un parto cesareo, difficile degli hard disk, ecco che si procede ad accendere i computer per dare un’occhiata al BIOS ed al clock di ognuno di essi, tutto con una mano sola, perché l’altra impugna la videocamera che riprende le operazioni, commentandole ad alta voce, come un medico patologo fa durante le autopsie. 

Si inserisce l’hard disk del laptop nel rack della workstation, utilizzando l’adattatore 2.5” – 3.5” e si lanciano i comandi: 
mount –l 
fdisk –lu 
disktype /dev/hda 
hdparm –gI /dev/hda 

e si ridereziona l’output di questi verso dei file txt con nomi di fantasia come fdisk.txt, disktype.txt ecc. ecc. e si fa lo sha256sum di ognuno di essi conservando l’output in un file chiamato hash.txt, che a sua volta sarà sottoposto allo sha256sum, così da avere l’hash del file degli hash. 

È molto importante il “mount –l” per dimostrare che Linux non ha montato in alcun modo il disco da duplicare, così si garantisce la non alterazione, tutti gli altri comandi servono a fornire ulteriori informazioni sul disco suspect. 
È il momento di accendere i motori, dopo aver inserito l’hard disk da duplicare nel rack, si lancia AIR 1.2.8 e si procede alla duplicazione del disco utilizzando i parametri: 
ibs=512 e obs=2048 (da alcuni test condotti l’obs>512 velocizza la scrittura dell’immagine) 
l’hash prescelto è lo SHA256, algortimo che non ha presentato ancora collisioni, quindi inattaccabile pure dagli avvocati USA. 
Chiaramente impostiamo la VERIFICA, in modo da far risultare che l’hash del disco originale coincida con quello della copia. 
Per concludere si salva il log file di AIR e si sottopone ad hashing. 

L’acquisizione è terminata, come la mattinata e con una fame da lupi si torna alle proprie dimore, ma già con l’idea di procedere al backup delle immagini dei dischi. 

L’ANALISI 

La prima cosa che si fa è quella di lanciare AUTOPSY ed iniziare l’esplorazione del file system, individuare i files che possono interessare, effettuare una ricerca per stringhe/keywords, creare una timeline per vedere le ultime attività, ordinare i files per tipologia ed ad uno ad uno aprirli per capirne il contenuto. Dato che non si sta cercando niente di particolare e dato che il “profiling” del proprietario dei dischi sequestrati è di utente medio-basso, si evitano le indagini sulle occultazioni sofisticate. 
Infine si può procedere ad un carving con foremost o scalpel per estrarre tutti i files presenti nello spazio non allocato. 

IL REPORT E LA CONSEGNA 

Finito il tutto, si crea una cartella REPERTI dove si conservano tutti i files estratti dal contenuto più o meno interessante, si sottopone ad hash e si ridereziona l’output in un file hash_reperti.txt (per esempio), poi si fa l’hash di quest’ultimo e lo si conserva. 
Infine si comprime l’immagine dell’hard disk con gz, tar, zip o quel che si vuole e si sottopone a hash, si copia tutto su hard disk da consegnare all’Autorità Giudiziaria o A.G. per sicurezza si masterizzano i reperti e tutti gli hash files su CD/DVD-ROM non riscrivibile, che, come al solito, per prudenza, lo si può anche firmare col pennarello indelebile. 
Il rapporto finale va scritto in due versioni, una completa di tutto, output di fdisk, mmls, disktype,log files di air, hash dei reperti, hash dei file consegnati, ecc. ed una sintetica per far capire “velocemente” i risultati raccolti. 
Si deve scrivere anche un rapporto di consegna di tutto ciò che si va rilasciare all’A.G. e farlo firmare da almeno un “verificatore” esterno che testimoni la presenza di ciò che si è dichiarato di consegnare. 
Infine la nota spese,che comprende le ore lavoro e le fatture del materiale di consumo utilizzato.
_________________