Articoli con tag forensic game

IISFA Forum & CyberCop 2009: una esperienza da ripetere!

Anche quest’anno si è tenuto a Bologna, presso l’università, l’evento denominato IISFA Forum. Tre giorni intensi e frenetici, che hanno lasciato in me un segno indelebile. Posso dire senza timore di esagerare di star ancora elaborando ricordi, sensazioni e discorsi.

Il primo giorno è stato interamente dedicato alla presentazione di software ed hardware di supporto alla computer forensic, con particolare attenzione alla mobile forensic (quella dei cellulari, per capirci). Tutti molto disponibili i rappresentanti delle ditte intervenute. Nonostante qualche intoppo, dovuto soltanto alla densità elevatissima di cose interessanti, ho trovato estremamente utile la panoramica che ne ho ricavato, sia dal punto di vista di cosa offre il mercato, sia per quello che nelle brochures non c’è scritto.

Il giorno successivo è stato dedicato invece alla gara denominata “CyberCop”, in parallelo ai seminari, che purtroppo non ho potuto seguire, dato che ho partecipato con la mia squadra, composta quasi all’ultimo momento, e peraltro ci siamo conosciuti sul posto, visto che una metà non conosceva l’altra metà. Ma l’affiatamento è stato immediato, e ci siamo battuti con tenacia fino alla fine, anche se ha vinto la squadra con più esperienza, come era anche atteso che fosse.
L’intreccio informatico-giuridico era degno dei più intricati casi mai scritti dai migliori giallisti, con un criminale virtuale che dimostrava una grande competenza sia in campo informatico che nelle tecniche e metodi di indagine delle Forze dell’Ordine.
Alla fine siamo riusciti a mettergli le mani addosso, in senso virtuale, ma il tempo per risolvere l’enigma è scaduto senza che riuscissimo a dimostrare, con prove in grado di reggere un processo, che il criminale fosse proprio quello.

L’ultimo giorno si è svolta la simulazione del dibattimento in aula, con tanto di Pubblico Ministero, Difensore e Giudice, e non si sono fatti mancare nulla: prove non ammesse, eccezioni del difensore, imbarazzo del Pubblico Ministero e colpo di scena finale. Insomma, una sceneggiatura perfetta per una puntata di Law&Order.

Se da un lato mi viene da dire “Pazienza, andrà meglio la prossima volta”, dall’altra devo ammettere di aver “rosicato” un poco, lo confesso. Ero convinto di aver inquadrato perfettamente il modus operandi del criminale virtuale, ma i fatti mi hanno dato torto, e sulle prime ci sono rimasto parecchio male.
Poi, dopo qualche giorno, a mente fredda, mentre scrivevo un qualcosa legato alla sfida (e che per ora non posso dire), ho capito parecchie cose su come sono andati i fatti.

Riassumendo brevemente, a parte quello che mi ripeto spesso, ossia che c’è veramente tanto da imparare, forse troppo, il problema è stato proprio l’essere convinto di aver inquadrato la situazione. Due parole: presunzione e pregiudizio.

Il presumere di aver compreso tutto di una situazione, quando se ne ha un punto di vista ristretto e limitato, porta a sottovalutare la realtà e sopravvalutare l’immagine che ce ne siamo fatta. arrivando a scartare elementi che ad un osservatore esterno e non coinvolto appaiono palesi. Per fare un esempio: in una certa fase vi era un file ZIP protetto da password. Ero talmente convinto che il criminale virtuale fosse troppo furbo per usare una password debole, che non ci ho neanche provato a fare un attacco a dizionario. Invece la password era banale, di quattro lettere e senso compiuto, in un attacco a dizionario l’avrei trovata in pochi secondi.

Il pregiudizio di avere di fronte qualcuno “che ci capisce”, ma non così tanto, visto che usa software comuni e strategie note, mi ha fatto di nuovo sottovalutare la situazione. Ho subito associato al criminale virtuale la figura di quello che conosce tutti i programmini del mondo, ma in fondo non sa come funzionano e soprattutto perché. Un esempio: il criminale virtuale aveva un campionario estesissimo di software per crittografia e steganografia, e c’era una immagine che risultava differente da una copia presente in Rete. Le ho provate tutte: analisi del contrasto, mappatura, confronto per sottrazione, istogrammi RGB, ma ho mancato la prova più ovvia: l’immagine conteneva dati nascosti da steganografia, appunto.

Errori banali, dettati appunto da presunzione e pregiudizio. Le mie convinzioni personali mi hanno impedito di accettare ed accertare i fatti come erano. Era un gioco, ma se fosse stata una indagine reale il danno sarebbe stato tutt’altro che trascurabile.

Sul treno del ritorno, con il mio amico Lorenzo, stavamo ricapitolando gli errori e le sviste commesse, ripetendoci ad ogni passo: “Manco le basi!“.

Oltre questo, la lezione ha avuto per me un valore incalcolabile, a parte la constatazione di avere ancora molto da imparare: si può essere buoni tecnici, ma fare l’investigatore è tutto un altro paio di maniche.

Per il resto, ho ancora parecchio materiale da elaborare, contatti da perfezionare e qualche nuovo amico, che male non fa.

Conto di partecipare anche l’anno prossimo, ma così faranno le altre squadre, e la battaglia sarà dura. Ma il divertimento sarà maggiore, ne sono certo.

Tags: , , ,

Un pen drive “multistrato”: la soluzione

Eccoci finalmente al momento di rivelare tutti i segreti del game di data hiding. Come prima cosa voglio ringraziare tutti i partecipanti per il tempo speso e soprattutto per essere “stati al gioco”. Andiamo al sodo.

Le bandierine

Il pen drive contiene due filesystem nascosti, oltre a quello “visibile”. Entrambi sono di tipo FAT, creati con l’ausilio dei loop device in Linux. Il primo, in FAT32 con etichetta di volume nascosto1, ha questi dati di dimensione ed utilizzo:

  • Totale: 1.009.729.536 byte
  • Usati: 11.706.368 byte
  • Liberi: 998.023.168 byte

Per poterlo montare senza lamentele da parte del sistema operativo, basta creare un loop device con questo comando:

# losetup -o 1009935360 /dev/loop1 pen-drive.dd

e di seguito usare il comando mount sul device appena assegnato, ossia loop1, in questo modo:

# mount -t vfat /dev/loop1 /media/loop1 -o ro,noatime

Le opzioni usate sono per essere proprio sicuri che niente venga toccato. I file sono quattro, tutte immagini. Lavorando con i comandi ls e stat si ottengono tutte le informazioni richieste:

# ls -l
-rwxr-xr-x 1 root root 3256972 21 ott 13:26 img_0154.jpg
-rwxr-xr-x 1 root root 2882079 21 ott 13:26 img_0155.jpg
-rwxr-xr-x 1 root root 3447899 21 ott 13:26 img_0156.jpg
-rwxr-xr-x 1 root root 2107408 21 ott 13:26 img_0477.jpg
# stat *
  File: `img_0154.jpg'
  Size: 3256972   	Blocks: 6368       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 6           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:34.000000000 +0200
Change: 2008-10-21 13:26:56.000000000 +0200
  File: `img_0155.jpg'
  Size: 2882079   	Blocks: 5632       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 7           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:38.000000000 +0200
Change: 2008-10-21 13:26:56.000000000 +0200
  File: `img_0156.jpg'
  Size: 3447899   	Blocks: 6736       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 8           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:40.000000000 +0200
Change: 2008-10-21 13:26:57.000000000 +0200
  File: `img_0477.jpg'
  Size: 2107408   	Blocks: 4120       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 9           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:46.000000000 +0200
Change: 2008-10-21 13:26:57.000000000 +0200

Il conteggio delle bandierine è presto fatto:

  • 4 per il filesystem (tipo, dimensione, libero/occupato)
  • 4 per i file trovati
  • Per ogni file sono 5 bandierine: nome, dimensione ed i tre orari, accesso, modifica, creazione.

In totale fanno 28 punti per questo filesystem.

Passiamo ora a quello che si è rivelato più difficile da trovare. E’ “contenuto” all’interno di quello normalmente visibile, è in FAT16 ed ha etichetta nascosto2. Questi i suoi dati dimensionali:

  • Totale: 409.378.816 byte
  • Usati: 516.096 byte
  • Liberi: 408.862.720 byte

Per poterlo montare senza lamentele, prima si crea il loop device così:

# losetup -o 512000000 /dev/loop2 pen-drive.dd

poi si procede al mount:

# mount -t vfat /dev/loop2 /media/loop2 -o ro,noatime

Et-voilà. Ora passiamo ai file, solo due, entrambi PDF, datasheet di componenti elettronici: una memoria RAM ed un controller per porte seriali.
Come sopra, lavorando di ls e stat abbiamo tutto quello che ci serve:

# ls -l
-rwxr-xr-x 1 root root 364643 21 ott 13:32 16c450.pdf
-rwxr-xr-x 1 root root 146960 21 ott 13:33 62256.pdf
# stat *
  File: `16c450.pdf'
  Size: 364643    	Blocks: 720        IO Block: 8192   regular file
Device: 702h/1794d	Inode: 12          Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:32:46.000000000 +0200
Change: 2008-10-21 13:32:46.000000000 +0200
  File: `62256.pdf'
  Size: 146960    	Blocks: 288        IO Block: 8192   regular file
Device: 702h/1794d	Inode: 13          Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:33:18.000000000 +0200
Change: 2008-10-21 13:33:18.000000000 +0200

Il conteggio delle bandierine in questo caso è di 16, 4 per il filesystem, 2 i file, 5 per file per i metadati.

In totale è possibile totalizzare 44 punti. Andando di solo carving al massimo si ottengono 12 punti (6 per i file e per ogni file l’unico metadato disponibile è la dimensione).

La classifica

A pieni punti abbiamo:

  • Denis Frati, veloce, accurato e preciso (e su di lui non avevo alcun dubbio, bravo Denis!)
  • Daniele Murrau, sintetico e preciso
  • Davide Paltrinieri, una giovane promessa che ha dimostrato tenacia e intuito, a cui va un plauso aggiuntivo per il fatto di essere da poco utente Linux, e quindi con la difficoltà ulteriore di trovarsi a “domare” un sistema operativo poco conosciuto (…non oso pensare a cosa potrà fare fra qualche anno. E’ meglio tenerselo come amico, ecco)

Seguono le menzioni d’onore:

che pur impegnandosi hanno “mancato” il secondo filesystem nascosto, quello con etichetta nascosto2. Bravi comunque.
Se lo desiderate potete pubblicare nei vostri siti/blog un post con la procedura seguita per trovare le vostre bandierine, e se me lo notificate aggiungo il link alla vostra spiegazione.

La procedura per creare il pen drive

Non è molto lunga, né complicata, una volta capito l’uso dei loop device. Il pen drive conteneva una unica partizione da due gigabyte, al momento dell’acquisto. Ho provveduto a cancellarla ed a crearne una che occupasse circa la metà dello spazio disponibile, formattandola in FAT32.

Ho poi creato un loop device che puntasse esattamente al primo settore dopo la partizione visibile, usando il comando visto sopra. In questo modo ho potuto lavorare su nascosto1 senza creare partizioni, formattandolo in FAT32 e copiandoci sopra i file delle quattro immagini.

A questo punto ho messo mano al terzo filesystem, il secondo nascosto. Ho creato un loop device che partiva dal byte 512.000.000 del pen drive, in modo da avere un numero facile da ricordare (come hanno correttamente ipotizzato Denis e Davide). Il problema è che il loop device “termina” alla fine fisica del pen drive, ossia dopo 1,5 gigabyte, quindi se si va a formattare il loop device si corre il rischio di cancellare il filesystem nascosto creato in precedenza. Viene in aiuto il comando mkdosfs di Linux che consente di specificare di quanti blocchi da 1 kilobyte è composto il filesystem. Ho assegnato 400 megabyte per questo secondo filesystem, in modo da poter preservare l’altro nascosto. Qui sotto una figura che riassume la geometria dei tre filesystem.

La struttura dei filesystem nel pen drive

La struttura dei filesystem nel pen drive

Ecco tutto. Quindi niente di esoterico, né da guru, solo un po’ di fantasia e di conoscenze dei vari filesystem.

Considerazioni finali

Finalità del game era appunto di offrire un momento di svago utile, con lo scopo neanche tanto nascosto di fornire un minimo di spunti di approfondimento. Loop device, filesystem, partizioni, geometrie, tutti concetti abbastanza basilari, ma troppo spesso dimenticati, nascosti da troppe “finestre e pulsanti”.

Altro intento era di mostrare che il solo carving non risolve tutto. Foremost in pochi secondi estrae tutti i file dall’immagine del pen drive, ma non offre informazioni su tempi e modi in cui i file sono giunti sul supporto. In un caso reale probabilmente la ricostruzione della timeline può essere fondamentale. Come fondamentale può essere la dimostrazione dell’intento, ossia che la struttura dei filesystem contenuti sul supporto è intenzionalmente mirata a nasconderne parte del contenuto.

La sofisticazione nei metodi usati è stata volutamente tenuta ad un livello basso, senza stratificare altri tipi di data hiding. Nella vita reale un tale metodo non resisterebbe a lungo all’analisi di una persona competente. Inoltre vi sono forti controindicazioni per la integrità dei dati nel tempo: un errore di manovra e dati scritti nella partizione visibile possono andare a sovrascrivere porzioni vitali dei dati o della struttura del filesystem della partizione da 400 Mbyte, quella col nome nascosto2.

Ecco anche il motivo per scegliere FAT come filesystem: le strutture di lavoro sono tutte concentrate all’inizio della partizione, per cui si può essere ragionevolmente certi che da un certo punto in poi niente viene scritto o letto durante il normale accesso al filesystem, rendendo possibile “includere” un altro filesystem al suo interno. Questo ad esempio con ext2/3 non è possibile, perché le strutture di supporto e di lavoro del filesystem sono sparse per tutta la partizione, per ragioni di efficienza e prestazioni. Quindi includere un altro filesystem in esso, completamente invisibile, è quasi impossibile.

E’ tutto. Ancora grazie a tutti i partecipanti. Al prossimo gioco.

Tags: ,

Data hiding: un pen drive “multistrato”

Avevo approntato un particolare pen drive per una presentazione riguardante tecniche di data hiding. Se non avete altro da fare e vi piace giocare, vi propongo un semplice capture the flag.

Antefatto

Un normalissimo pen drive, acquistato in un centro commerciale per pochi euro. Dentro vi ho nascosto dei dati sotto forma di normali file (immagini e testi).
Usando foremost o photorec (due applicazioni tipicamente di uso forense) potreste trovare immediatamente i dati ed i file, ma… Dove sarebbe il gusto del gioco?

Le bandierine da conquistare

  • Una bandierina per ogni filesystem che riuscirete a montare senza errori (ossia senza che il sistema operativo lamenti errori), a parte quello non nascosto.
  • Una bandierina per ogni informazione che riuscirete ad estrarre dal singolo filesystem, in particolare: etichetta del volume, tipo di filesystem, dimensione totale, spazio occupato/libero.
  • Una bandierina per ogni file che riuscirete a trovare.
  • Una bandierina per ogni informazione trovata sul singolo file nascosto, ossia: nome originale, date di modifica/accesso/creazione.

Il “reperto”

L’immagine dell’intero pen drive, ottenuta con “dd”, è in un file zip da 26 megabyte, attenzione che una volta esploso occuperà 2 gigabyte, quindi procurate di avere spazio disco a sufficienza.
Il reperto è prelevabile qui:
Pen drive data hiding game (novembre 2008)

Le regole

  • Prima regola: NON SI VINCE NIENTE. Ma proprio niente, neanche un misero link nel blogroll.
  • Seconda regola: le risposte solo per e-mail, usando uno dei miei contatti. Qualsiasi altra forma di comunicazione semplicemente verrà ignorata.
  • Terza regola: messaggi/post/annunci in mailing list tipo “è una scemenza” “è facile” “non mi ci spreco nemmeno” non fanno comunque vincere niente, ma si fa una figura peggiore. Se non interessa partecipare, non si partecipa e punto, nessuno ne sentirà la mancanza.
  • Quarta regola: usate quello che vi pare, le procedure che volete, gli strumenti che preferite. Se volete potete citarli nel messaggio-soluzione, ma non è importante.
  • La regola della vittoria: vince chi trova più bandierine, documentandole. Dato che decido io cosa è giusto e cosa non lo è, dovete essere convincenti.

Livello di competenza richiesto

Non è un game particolarmente difficile, anche se occorre avere un po’ di esperienza. Il tipo di data hiding utilizzato è piuttosto semplice, anzi, quasi banale. Però, dato che stiamo parlando di didattica, è una buona palestra.

La soluzione

Verrà pubblicata più avanti, anche se nessuno parteciperà.

E’ tutto. Buona esplorazione.

Tags: ,

Compiti per le vacanze

Regole:

  • Non si vince niente
  • Non dovete linkarmi
  • Vince chi mette più dettagli: dove come perché quando cosa
  • Perde chi non partecipa

Cos’è questo:

Risposte solo via mail.

Sarò meno presente nei prossimi giorni. Vado in modalità “risparmio energetico”, sperando di ricaricarmi un po’. Quanfo ritorno a piena potenza avrete risposte risposte e spiegazioni.

Volete un aiuto? Per intanto la categoria assegnata dovrebbe suggerire qualcosa.

Per il resto, you’re on your own (sempre gradito Alan Parsons).

Tags:

Test di Computer Forensics #2: strumenti o competenza?

Massimiliano mi autorizza a pubblicare un test di Informatica Forense (traduzione di Computer Forensics) che ci ha sottoposto qualche tempo fa. Da questo test ne è poi scaturita una discussione ricca di considerazioni sulla priorità tra strumenti e competenza (o intuito professionale, se vogliamo dare un altro nome).

Il test viene con la soluzione, quindi non si vince nulla, è solo un utile esercizio. La soluzione, che ho trovato per primo (fatemi vantare un po’ ogni tanto…) mi ha fruttato un piccolo dispositivo per l’analisi delle sim card offerto da IISFA.

Questa la storia, al solito totalmente inventata:
Il file da analizzare è questo, l’unica digital evidence disponibile per le indagini: è una e-mail intercettata, si teme possa nascondere un messaggio in codice relativo ad un imminente attacco terroristico. I sospettati usano un metodo non convenzionale per nascondere i dati. Il file cifrato con 256 AES e non c’e’ il tempo di forzare la password con un attacco brute force!

Lo scopo è rilevare il messaggio nel più breve tempo possibile, ed ovviamente la procedura deve essere documentata e ripetibile.

Per la soluzione e le considerazioni basta continuare a leggere il resto.

Prosegui la lettura »

Tags:

Test di Computer Forensics: i risultati

Ecco la soluzione ed il vincitore del test proposto qualche giorno fa.

Per prima cosa la soluzione: lo schema elettronico c’era, nascosto nel file dict nella directory src/fcrackzip-0.3. Era in formato PDF, codificato in BASE64, il sistema utilizzato per trasmettere allegati nella e-mail.

Di seguito passo a presentare il solutore: il bravissimo Denis Frati, che ha risolto il rompicapo in meno di mezza giornata. Menzione d’onore a Nanni Bassetti, che ci è arrivato poco dopo.

Lascio la parola a loro, nelle rispettive relazioni sull’attività svolta per trovare il file occultato:

Grazie a tutti per aver partecipato, ed alla prossima sfida.

Tags: ,

Computer Forensic: un piccolo test

La disciplina detta Computer Forensic è di questi tempi piuttosto in voga, per via anche di alcuni fatti di cronaca.
In sostanza si occupa del recupero delle evidenze (“prove”) di origine informatica destinate ad essere utilizzate in sede legale.

E’ strettamente legata alla information security, ma il punto di vista è quasi totalmente differente. Spesso per ottenere prove valide e decisive si deve sfruttare una qualche debolezza nelle difese di un sistema informatico. O si devono adottare strumenti più da criminale informatico che da esperto di sicurezza. Non è raro il caso in cui si ricorra a programmi per spezzare cifrature o rivelare password per accedere al contenuto di un supporto.

Per chi vuole avere un “assaggio” di come funzioni il tutto, ho creato una simulazione di caso reale. Se volete cimentarvi e mettere alla prova le vostre abilità di Sherlock digitali, continuate a leggere

Prosegui la lettura »

Tags: ,

Analisi di un Malware

Il progetto Honeynet pubblica ogni tanto una sfida con cui cimentarsi e su cui provare le proprie capacità di indagine in questioni di sicurezza dell’informazione.

Nel settembre 2004 ho partecipato ad una delle loro sfide, dette Scan of the Month, e mi sono classificato fra i primi dieci.

Il testo con il quale ho partecipato è qui.

English version.

Tags: , , , ,