CFI - Computer Forensics Italy

Il game si è concluso il primo maggio, con oltre 900 download dell'immagine forense in 15 giorni.
La discussione nata dopo il termine per la presentazione delle soluzioni, avviata sia internamente a CFI ML, che esternamente, ha permesso di fare alcune valutazioni di cui terremo conto nell'organizzazione della prossima sfida.
In particolare la richiesta del report ha rappresentato un grande freno, sia internamente alla lista, che per i non appartenenti ad essa. Questi ultimi, spesso non interessati alle problematiche proprie della forensics, non vedevano alcuna finalità nel report, avendo cercato di risolvere il game per il solo gusto della sfida.

Il report rappresentava ad avviso degli organizzatori una interessante opportunità formativa, in quanto se per il funzionamento di tools e la risoluzione di problematiche tecniche si può trovare abbondante materiale online, lo stesso non si può dire per la stesura di documentazione da presentare ai magistrati, o agli avvocati, documentazione che può avere il suo peso nel far pendere la bilancia della giustizia a favore o a sfavore di un imputato.
Ci è stato, tuttavia, fatto notare, da professionisti di fama della forensics, che presentare dei report, per quanto ben fatti, avrebbe potuto portare gli utenti meno preparati ad adottare schemi per la stesura di relazioni tecniche da presentarsi in dibattimento non idonei per lo specifico caso.
Si deve sempre considerare che errori nello svolgimento di una consulenza tecnica da discutersi in tribunale potrebbero avere importanti conseguenze, sia in positivo che in negativo, nella vita di è coinvolto nel procedimento.
Come realizzatori del game teniamo conto di questo pensiero, rimaniamo tuttavia dell'idea che sarebbe comunque utile fare formazione su questo importante aspetto della forensics.

Ad ogni modo per i prossimi game cercheremo altre soluzioni, quali ad esempio la realizzazione di due classifiche separate per gli appartenenti alla mailing list, o comunque per i "forensers" (operanti e apprendisti), e per i non appartenenti, considerando il report un di più che dia punti.

Un elemento che ha invece fuorviato molti, è stata la mancata indicazione degli obiettivi da raggiungere. Ci sembrava, in tal modo, di rendere il game maggiormente realistico, si è mai visto un cattivo che indichi il numero di prove a suo carico da recuperare in un'indagine?
Questo, tuttavia, ha portato molti a pensare di aver risolto il game dopo aver scoperto solo poche informazioni, ritenendolo quindi semplice, se non addirittura banale.
Illustriamo quindi i diversi obiettivi del game:

1. Mappe indicanti l'ubicazione del nascondiglio di armi (file 7zip concatenato ad una jpg) ;
2. Data-base di un password manager (password da scoprire con metodo induttivo);
3. Mappe indicanti l'obiettivo del terrorista (allegato base64 di email sovrascritta + induzione logica) ;
4. Due messaggi nascosti in Wikipedia indicanti gli ordini relativi all'obiettivo ed un elenco di fiancheggiatori (codificati base64).

Chi avesse voluto poteva poi dare indicazioni sugli atti necessari ad individuare gli autori dei messaggi su Wikipedia (rogatoria per la richiesta dei log) e sulle modalità con cui i personaggi coinvolti probabilmente comunicavano, desunte dal testo delle mail, dagli ip coinvolti negli headers, dalla presenza di un programma specifico.

Ma facciamo un passo indietro e vediamo come inizia il game: lo story board (potete leggerlo qui ), che speriamo si sia rivelato sufficientemente accattivante, racconta dell'individuazione del Barbuto Andrea atterrato presso l'aeroporto di Trantor, sul quale pendono sospetti di terrorismo. Nello zaino del soggetto viene individuata, celata nell'imbottitura dello schienale, una penna usb.

Le autorità giudiziarie e di polizia optano per l'analisi del supporto alla ricerca di informazioni relative all'attività del Barbuto eventualmente posta in essere, o progettata.
Dopo aver acquisito l'immagine forense del supporto gli investigatori si apprestano ad analizzarla, cosa troveranno?

---

Se avessimo potuto essere la fianco del Barbuto nelle settimane precedenti al suo fermo, gli avremmo visto compiere con la chiave usb le seguenti operazioni (probabilmente ci sarà di aiuto nel comprendere il successivo operato degli investigatori):

il 27 marzo 2008 sulla chiave usb sono presenti:

• pagine web relative al corano;
• corano in pdf e lo zip da cui è stato estratto;
• xdeviw.exe;
• setup.exe (7zip);
• magazzino.exe (keepass.exe) + db password + file impostazioni (la password è "sharktale").

Il 1° aprile il Barbuto riceve da Mustafa la mail con in allegato l'immagine contenente la password; salva la mail sulla chiave e apre l'allegato, senza salvarlo, leggendo la password (glenco).

Il 3 aprile h.10.20 il Barbuto formatta la chiave da MS Windows, con l'utility di sistema.

Il 4 aprile il Barbuto riceve una e-mail che legge attraverso il browser, salva sulla chiave il solo allegato, costituito dall'immagine di un Ak-47 con attaccato un archivio 7zip contenente mappe indicanti la posizione delle armi, quindi salva sulla chiave:

• pagine web relative ad anarchia, hotspot ed internet point;
• 3 manuali militari in formato pdf;
• 2 email inviategli dall'amico Oscar, con immagini allegate.

Il 5 aprile apre i manuali 21777 e 2056840

Il 7 aprile il Barbuto salva sulla chiave usb:

• video di youtube con un player e visiona uno dei filmati;
• l'eseguibile di setup di Netstumbler;
• l'eseguibile magazzino.exe e il db delle passwd;
• apre le mail di oscar e salva due immagini contenute in una delle mai.

Il 9 aprile il soggetto apre il db delle passwd usando l'eseguibile "magazzino", viene quindi generato il file di impostazioni/configurazione che lui cancella.

L'11 aprile Barbuto:

• cancella l'eseguibile di netstumbler, le due fotografie (i comilitoni) estratte dalle e-mail ricevute da Oscard;
• apre la lista degli hotspot e degli internet point;
• riceve via mail gli indirizzi di due pagine di wikipedia, e due gruppi data/orario, salva tutto sul file 4u.txt (la mail non viene salvata sulla chiave);

Il 14 aprile Barbuto riceve la mail con il file 7zip protetto da password, in cui sono contenute le foto di Aviano (italy), apre lo zip e visiona le immagini senza estrarle, quindi cancella l'archivio;

Il 16 aprile il soggetto atterra all'aeroporto di Trantor, cerca di passare i controlli di frontiera con una carta di identità contraffatta e viene fermato dalle autorità.

 

---

 

Dopo questo breve salto nel tempo e nel passato del terrorista dobbiamo domandarci quanto di tutto ciò sarà ricostruibile dagli investigatori, quante informazioni saranno recuperabili.

La spiegazione che segue non deve essere in alcun modo ritenuta una metodica da noi suggerita quale metodo di analisi da applicarsi alle indagini informatiche, o allo svolgimento di consulenze tecniche e/o perizie, nè una forma di report, o relazione tecnica idonea ad essere presentata in controversie civili o giudiziarie. Si tratta della semplice spiegazione dei passi tecnici adottabili per l'individuazione degli obiettivi presenti nel game.
Nelle righe seguenti non si fa riferimento ad ogni singolo passo, al calcolo degli hash, alla copia dei report generati dai software da raccogliersi a fini documentali, ecc...tutte partiche che dovrebbero fare parte del bagaglio culturale, del metodo del forenser, come appreso dalle best practices di base.

L'investigatore farà copia dell'immagine dd, in modo da non rischiare in alcun modo di danneggiare la prima copia, quindi, verificata la coincidenza degli hash e quindi l'identicità delle immagini stesse con il device originale, si metterà all'opera.

Vista la ridotta dimensione dell'immagine, l'investigatore decide di fare un overview del contenuto utilizzando Autopsy Forensic Browser. Inizia quindi a creare il caso,

per poi passare alla "file analysis"

In questa fase appare da subito la presenza di alcuni file cancellati:

• _bj.7z;
• KeePass.ini;
• netstumblerinstaller_0_4_0.exe;
• teamA.jpg;
• teamB.jpg.

L'investigatore inizia dedicandosi a questi file.

_bj.7z sembrerebbe, dall'estensione, essere un archivio compresso nel formato 7zip. Si procede quindi ad esportare il file in questione. L'utility "file" ci confermerà trattarsi di un archivio 7zip

nemo@nexus:~/barbuto/autopsy_dump$ file vol2-C.._bj.7z
vol2-C.._bj.7z: 7-zip archive data, version 0.2

tentando di estrarne il contenuto l'investigatore si scontra con un primo problema: è richiesta la password!

Prima di provare ad attaccare l'archivio è necessario raccogliere altre informazioni, magari la chiave spunterà analizzando il resto dei dati.

L'investigatore si dedica quindi la file KeePass.ini, un file di testo che sembra contenere le configurazioni d'uso di un programma. Cercando informazioni in rete trova conferma di queste ipotesi individuando anche il software a cui il file di configurazione appartiene, KeePass, un password manager. La presenza del file di configurazione, come mostrato anche dalle prove eseguite sul medesimo tool scaricato dall'investigatore, permette di capire che il file è stato creato a seguito di un utilizzo, è quindi probabile che esista un data-base di password.
Questo viene individuato nel file attivo Database.kdb. L'investigatore rivolge la sua attenzione su di esso, incuriosito dall'estensione .kdb e dal nome, che sembrano far riferimento ad un db (data-base). Una rapida ricerca in rete, condotta sull'estensione, permette di individuare informazioni che lo riconducono al password manager sopra indicato,

L'investigatore trova conferma di ciò verificando l'header esadecimale del file, corrispondente a 0x03D9A265FB4BB5, come indicato nella pagine web. L'investigatore estrae il db ed anche in questo caso rimanda ad un secondo tempo il tentativo di aprirlo, vuole raccogliere altre informazioni che gli consentano di crearsi un elenco di possibili password.

Il file netstumblerinstaller_0_4_0.exe non risulta recuperabile, ma l'investigatore non ha motivo di dubitare si tratti realmente dell'eseguibile per l'installazione del noto tool per l'individuazione delle reti wi-fi.

I file teamA.jpg e teamB.jpg risultano essere immagini file immagine, riproduzioni di fotografie ritraenti due team di soldati o guerriglieri. L'investigatore esporta i file per ulteriori successive investigazioni.

Dopo questa prima analisi dei file cancellati, rimanendo nell'ambiente di Autopsy, l'investigatore si dedica ai files attivi.

La sua attenzione è immediatamente catturata dal file 4u.txt, il cui contenuto è il seguente:

le prime due righe portano a pagine di Wikipedia, le ultime due rappresentano due gruppi data/orario. L'investigatore ricorda di aver letto un articolo sul blog di Didier Stevens riguardante le modalità di occultamento di informazioni sulle pagine dell'enciclopedia del web.
L'articolo spiega come sia possibile editare la pagina di Wikipedia con un contenuto nascosto dai tag per l'inserimento di commenti nascosti. Ricorrendo poi all'opzione "undo" il commento viene rimosso dalla versione pubblica, ma rimane consultabile confrontando la versione con contenuto nascosto con una successiva. Tale escamotage mantiene il messaggio rintracciabile, senza il pericolo che i moderatori di Wikipedia, o i curatori della pagina, lo cancellino.

Nel nostro caso, alla prima pagina indicata dal file 4u.txt (http://en.wikipedia.org/wiki/M16_rifle), cercando nel sheet "history" il primo gruppo data/orario si individuava una specifica versione editata dall'utente "Sliver of silicon".

Dal confronto con la versione più recente risultano essere state inserite nella pagina, come commento nascosto, delle informazioni codificate in base64

 

 

Il codice in base64 viene copiato in un file di testo e decodificato usando il tool Xdeview, ottenendo il seguente contenuto:

"inserisciti tra i movimenti contro la base, porta all'organizzazione di manifestazioni a ridosso della base, realizzando atti tali da produrre una reazione violenta nel sistema difensivo con vittime tra i civili, al fine di portare ad un incremento del dissenso nei confronti degli USA.
se ciò non è possibile decapita i vertici della base
se ciò non è possibile attacca corpo di guarda della base
se ciò non è possibile colpisci il personale della base nei luoghi di ritrovo all'esterno della stessa"

Per l'investigatore qualcosa comincia a dipanarsi!
Lo stesso procedimento applicato al secondo url di Wikipedia ed al secondo gruppo data/orario, porta all'individuazione di una serie di contatti:

"abdella abubaka +39 354-1234567
mohammed aamar +39 372-0987654
ouakkass bendaoud +39 372-56789012"

presumibilmente fiancheggiatori dell'organizzazione terroristica a cui il Barbuto ha aderito.

L'investigatore avrebbe anche potuto decodificare le informazioni codificate in base64 utilizzando "Reverse Calculator " una comoda estensione per il browser Mozilla Firefox sviluppata da Gianni Amato .

L'investigatore prospetterà al magistrato la possibilità di addivenire ad ulteriori informazioni sull'organizzazione terroristica, richiedendo alla Wikimedia Foundation, tramite rogatoria internazionale, i log relative alle connessioni avvenute nei giorni ed ore in cui sono state editate le versioni delle pagine con i messaggi nascosti e informazioni relative alla registrazione dell'utente "Sliver of silicon".
Si tratta probabilmente di accertamenti destinati a cadere nel vuoto, essendo assai probabile che chi ha lasciato i messaggi nascosti si sia nascosto dietro ad un proxy. Wikipedia, se identifica la connessione come proveniente da un proxy, consente di editare i documenti solo nel caso esista un account, che non può essere creato da proxy.
Questa difesa è tuttavia aggirabile con facilità, facendo creare l'account da un fiancheggiatore che possa sfruttare la connessione wi-fi aperta di persone estranee, o utilizzando proxy non ancora noti.

Il nostro investigatore si sofferma quindi sul file immagine ak-47.jpg rilevando una dimensione superiore a quella che ci si potrebbe aspettare. Il file viene estratto per analisi successive.

L'investigatore dedica ora la propria attenzione a due e-mail:

• "come butta.eml" del 24 arile 2007;
• "che combini.eml" del 9 ottobre 2007;

Nella prima sono narrati fatti che possono forse far luce su quanto abbia portato il Barbuto ad avvicinarsi all'estremismo islamico.
L'e-mail inviata da tale Oscar (omar_sas@tiscali.it) a Shark (shark@email.it), presumibilmente il Barbuto, contiene in allegato le due foto già rinvenute tra i file cancellati e denominate teamB.jpg (composto da Skotos, Aviland e mister Alfa) e teamA.jpg (composto da Oscar, Shark e Sykes).

Ricercando dei riferimenti in rete per tali nomi, l'investigatore scopre che i componenti del teamB usano nomi di personaggi del fumetto Nathan Never, mentre il teamA usa nomi riferiti al cartone animato Shark Tale.
L'analisi dell'header della mail permette di identificare il mittente in colui che alle ore 17:30:17 del 24 aprile 2007 (+0200 indica il fuso dell'Italia con l'ora locale) possedeva l'indirizzo Ip 213.156.55.138 che, come un semplice whois mostra, fa capo a FastWeb.

La seconda e-mail, inviata dallo stesso mittente allo stesso destinatario della precedente, contiene un messaggio di avvertimento per Shark, che dai contenuti appare essere il Barbuto.
L'immagine allegata mostra alcuni personaggi del cartone animato Shark Tale, avvalorando l'idea che questi possano fornire parole chiave per l'attacco alle password.

L'analisi degli header della mail permettono di identificare il mittente del messaggio in colui che alle 17:34:14 del 9 ottobre 2007 (ora del fuso italiano) possedeva l'indirizzo Ip 213.156.55.143, anch'esso assegnato all'ISP FatsWeb.

Per avere maggiori informazioni riguardo al mittente di queste mail, si potrà interpellare l'ISP FastWeb per sapere a quali utenti fossero assegnati gli IP rilevati nei tempi indicati, l'ISP Tiscali per avere il maggior numero di informazioni riguardo all'utente omar_sas@tiscali.it e il provider Email.it per acquisire informazioni sull'utente shark@email.it. Il magistrato valuterà se sussistano i presupposti per acquisire anche i contenuti delle mail box.
Sulle informazioni fornite dai provider si potrà lavorare con successivi accertamenti ed indagini.

L'investigatore realizza un primo elenco di parole chiave , raccogliendo i nomi di rilievo presenti nella documentazione fornitagli dalle autorità e quelli rinvenuti nell'immagine della chiave usb, aggiungendo ad essi quelli di altri personaggi del cartone animato Shark Tale e della serie fumetti Nathan Never. Gli attacchi alle password di KeePass e dell'archivio 7zip vengono fatti inizialmente usando caratteri lower case, senza spazi tre le parole ed invertendo l'ordine delle parole.
Con l'archivio 7zip i tentativi non danno alcun risultato, mentre con il password manager KeepPass utilizzato da Linux con Wine (ma avrebbe potuto utilizzarlo nel proprio ambiente MS Windows) la parola chiave "sharktale" riesce ad aprire il data base. All'interno di questo l'investigatore rinverrà le credenziali di accesso a tre mail box e dell'account di Wikipedia utilizzato dai terroristi per scambiarsi i messaggi.

L'investigatore decide di rinviare l'attacco all'archivio compresso 7zip e di cercare altre informazioni che potrebbero permettergli di individuare la password corretta.
Il passo successivo è la ricerca per keyword, condotta sui nomi individuati nelle documentazione e nell'immagine della chiave usb.
L'unica keyword che restituisce un risultato interessante è "Mustafa". Autopsy individua un occorrenza nel settore 222462

Analizzando il settore e quelli successivi si nota che la keyword era probabilmente inserita in una e-mail (inviata attraverso il servizio del provider IndiaInfo) sovrascritta, sia nella parte iniziale, mancano infatti gli headers e la prima parte del messaggio, sia in quella centrale, contenente l'allegato "shark.jpg", come si nota dai bytes seguenti, estratti dai settori 222462 e 222463

L'investigatore opta per l'utilizzo di un editor esadecimale, decisamente più comodo per verificare il contenuto dell'immagine, rispetto alla visualizzazione settore per settore fornita da Autopsy.
Analizzando l'immagine con KHexEdit si individua, come già scritto, quel che resta della e-mail dal bytes 113916928, la keyword "Mustafa" che impegna 7 bytes dall'113917023 e l'allegato, il già citato "shark.jpg" codificato in base64, che comincia dal bytes 113917463

All'offset 113926144 si individuano dati estranei alla codifica base64 dell'allegato

un esame più attento permette di comprendere che si tratta del file KeePass.ini, andatosi a sovrascrivere all'allegato, ed il cui contenuto giunge fino all'offset 113928204

Si nota quindi un pattern 0x00 che completa il settore assegnato al file KeePass.ini sino al byte 113928703.
Dal byte seguente riparte il codice in bas64 che termina all'offset 115970355.

Si può a questo punto estrarre dall'immagine dd l'allegato codificato in base64, copiando 2052892 ((115970356+1)-113917463) bytes dall'offset 113917463

nemo@nexus:~$ dd if=/media/disk/usb_key_barbuto.dd of=barbuto/allegato_base64 skip=113917463 count=2052893 bs=1
2052893+0 registrazioni dentro
2052893+0 registrazioni fuori
2052893 byte (2,1 MB) copiati, 9,9641 secondi, 206 kB/s

Si procede quindi alla decodifica dei dati in base64 utilizzando nuovamente Xdeviw

Il file risultante, la jpg denominata in origine "shark.jpg", è danneggiato dalla presenza di codice estraneo, il file KeePass.ini, che ha sovrascritto parte delle informazioni presenti nella codifica dell'algoritmo jpg.
Sebbene vi sia solo una strisce superiore di pochi pixel ben visualizzabile, il resto dell'immagine, per quanto compromesso, è comunque visibile.

L'investigatore fa una copia dell'immagine, la apre con l'editor per immagini GIMP e modifica dapprima i colori

e successivamente agisce su luminosità e contrasto

riuscendo ad ottenere qualche dettaglio in più.

In particolare è ora possibile distinguere la figura di un uomo in piedi davanti ad un cartello. Le modifiche apportate alla copia dell'immagine jpg, consentono all'investigatore di leggere quanto scritto sul cartello "GLENCO YOUTH HOSTEL" e di distinguere il logo presente sullo stesso.

L'investigatore decide di provare ad utilizzare le parole scritte sul cartello alle spalle dell'uomo per aprire il file 7zip protetto da password. I suoi tentativi hanno immediatamente successo usando la prima parola (GLENCO) scritta in minuscolo, ossia in caratteri lower case.

Se l'investigatore non avesse avuto questa intuizione avrebbe potuto provare a raccogliere maggiori informazioni su quanto rappresentato dalla fotografia. Cercando su Google "youth hostel" glenco avrebbe ricevuto il suggerimento a cercare "youth hostel" glencoe , con la lettera "e" finale.

Seguendo il suggerimento, con la prima pagina proposta dal motore di ricerca sarebbe approdato al sito della Scottish Youth Hostels, nella pagina relativa all'ostello di Glencoe (bellissima località).

In essa avrebbe immediatamente riconosciuto il logo (in alto a destra) come quello presente sul pannello presente nella jpg danneggiata, mentre tra le fotografie riportate nella pagina web dell'ostello una mostra un cartello assai simile a quello di cui si discute. Cliccando sull'immagine il browser l'avrebbe ricaricata ingrandita

Sarebbe stato in tal modo possibile rilevare che, a parte la struttura posta superiormente, il pannello sembra essere identico a quello presente nella jpg danneggiata, dove tuttavia si può notare una differenza: l'assenza della lettera "e" al termine del nome "GLENCO". L'investigatore avrebbe potuto quindi pensare ad una modifica apportata all'immagine, immagine nota al Barbuto, al fine di indicargli la password del file 7zip.

Prima di fare un primo report ai suoi superiori ed al magistrato l'investigatore, vista la presenza di un file in formato 7zip, decide di cercarne altri, magari non allocati, o allocati ma rinominati.
Per far ciò decide di utilizzare Sfdumper , un bash script che implementa alcuni tools dello Sleuthkit e Foremost, forse il più noto tool open source di data-carving.
Tuttavia Foremost non possiede headers e footers del formato 7zip nè nel file di configurazione, nè nel built-in. L'investigatore crea quindi alcuni archivi compressi nel formato di suo interesse e visionandone il contenuto con un editor esadecimale individua i bytes comuni, identificandoli quali header e footer. A questo punto mette mano al codice di Sfdumper aggiungendo al termine le righe necessarie allo script affinchè crei un proprio file di configurazione ad-hoc per Foremost

Apporta inoltre alcune modifiche nella procedura del carving per far si che il flusso dello script prosegua nel modo corretto.
Sfdumper estrae tre file:

• il file "_bj.7z" cancellato e referenziato all'inode 60, si tratta dell'archivio protetto da password;
• gli altri due sono recuperati con il carving.

------------------Dal file "Audit" di Foremost----------------------
File: stdin
Start: Tue May 13 18:21:41 2008
Length: Unknown

Num Name (bs=512) Size File Offset Comment

0: 00065003.7z 68 MB 33281965
1: 00067248.7z 67 MB 34430976

2 FILES EXTRACTED

7z:= 2
------------------------------------------------------------------

Analizzando il file di report di Foremost scopriamo che il file "65003.7z" presente nel settore 65003 non è in alcun modo referenziato, mentre il file "67248.7z", presente nel settore 67248, risulta essere sempre "_bj.7z", il cui hash sha256 risultano tuttavia differenti e per questo Sfdumper non ha cancellato il doppione.

nemo@nexus:~$ ifind -f fat -o 32 -d 67248 /media/disk/usb_key_barbuto.dd
60
(verifichiamo che il file presente nel settore 67248 è identificato dal'inode 60)
nemo@nexus:~$ ffind -f fat -a -o 32 -i raw /media/disk/usb_key_barbuto.dd 60
* /_bj.7z
(verifichiamo che il nome del file identificato dall'inode 60 è _bj.7z)

Il file "65003.7z" contiene due file jpg riproducenti due mappe di GoogleMap, denominati "akposition_1.jpg" e "akposition_2.jpg". Ma dove è posizionato questo file? Come è utilizzabile?

nemo@nexus:~$ ifind -f fat -o 32 -d 65003 /media/disk/usb_key_barbuto.dd
39
(verifichiamo che il file presente nel settore 65003 è identificato dal'inode 39)
nemo@nexus:~$ ffind -f fat -a -o 32 -i raw /media/disk/usb_key_barbuto.dd 39
/ak-47.jpg
(verifichiamo che il nome del file identificato dall'inode 39 è ak-47.jpg)

(verifichiamo [sotto] i settori allocati al file)
nemo@nexus:~$ istat -f fat -o 32 /media/disk/usb_key_barbuto.dd 39
Directory Entry: 39
Allocated
File Attributes: File, Archive
Size: 1639160
Name: ak-47.jpg

Directory Entry Times:
Written: Wed Apr 9 07:06:26 2008
Accessed: Mon Apr 14 00:00:00 2008
Created: Fri Apr 4 12:49:30 2008

Sectors:
63984 63985 63986 63987 63988 63989 63990 63991
63992 63993 63994 63995 63996 63997 63998 63999
(....continua...)

Quindi, l'investigatore fa questo calcolo ((63984+32)*512) =32776192 individuando l'offset a cui comincia il file "ak-47.jpg",

individuati i bytes iniziali del file si porta al termine dello stesso ricercando il footer del jpg, ossia 0xFFD9,

individuato all'offset 33298347, a seguito del quale l'investigatore nota la presenza dell'header del formato 7zip. L'investigatore comprende quindi che il file 7zip è stato semplicemente attaccato in coda al file jpg

Il trucco non consente all'utente ordinario di individuare il file compresso, aprendo il file immagine questa verrà visualizzata normalmente, ma consente all'utente a cui è nota la presenza del file nascosto di estrarne il contenuto agendo con il gestore di archivi/file_compressi appropriato direttamente sul file immagine.

A questo punto l'investigatore, avendo individuato:

• l'obiettivo del Barbuto, la base militare di Aviano in Italia, le cui mappe sono nascoste in un archivio in formato 7zip protetto da password;
• ordini e contatti per il compimento dell'atto terroristico, nascosti nelle pagine di Wikipedia;
• l'ubicazione di armi utilizzabili per l'attentato;
• un archivio di password per l'accesso ad account su Internet, con i quali proseguire le indagini;

può fare un primo report ai suoi superiori ed al magistrato confermando al pericolosità del barbuto e la sua intenzione di mettere in atto azioni ostili.

 

---

Con ciò si conclude la nostra "romanzata" discussione sulle possibili modalità di individuazione delle informazioni nascoste.
Ad esse avevamo assegnato i seguenti punteggi:

 

• 2 punti >> mappe nascoste nell'immagine dell'AK-47;
• 2 punti >> apertura db password;
• 2 punti >> ordini su wikipedia (1 punto per ogni messaggio);
• 0.5 punti >> valutazione sulla necessità di richiedere i log per i server di wikipedia per recuperare gli ip e poter provare ad identificare localizzare gli autori;
• 0.5 punti >> considerazioni derivanti dagli ip delle mail di oscar, da quanto scrive e dal recupero di netstumbler.exe che usano access point free a scrocco per comunicare e non farsi beccare;
• 3 punti >> immagini di Aviano nello zip con password (3 punti (perchè prima devono comunque recuperare e ricostruire l'immagine e capire che c'è la passwd).

In tal modo si totalizzavano 10 punti.
Vediamo ora i partecipanti ed i loro risultati:

• La prima soluzione ci è stata inviata da Michele Asciutti (visionabile qui ) dopo neanche 48 ore dalla pubblicazione del game. Asciutti ha individuato i messaggi nascosti su Wikipedia, totalizzando due punti, senza fare uso di tools specificamente pensati per la computer forensics.
• La seconda soluzione ci è stata dopo circa cinque giorni dalla pubblicazione. Gli autori sono questa volta il trio composto da Calogero Bonasia, Fabrizio Alampi e Gianni Amato. Come si legge dalla loro relazione (visionabile qui ) è stato fatto uso di tool per la computer forensics. Il team ha individuano solo le immagini relative all'obiettivo ed uno dei messaggi nascosti nelle pagine di Wikipedia (si tratta solo di una distrazione, come si comprende dal report avevano individuato anche il secondo), totalizzando quattro punti. Il team individa altresì il data-base di KeePass, ma non riesce ad aprirlo.

Va notato che il team Bonasia-Alampi-Amato ha proceduto ad una differente lavorazione del file "shark.jpg" allegato alla e-mail sovrascritta, ed individuato ricercando la keyword "Mustafa". I tre, dopo aver estratto tutto l'allegato, hanno proceduto alla pulizia del codice base64 dai bytes spurii. Il procedimento a comportato un paio di prove, perchè come si può vedere analizzando il base64 "ripulito" sono stati in realtà tolti 2 caratteri in più, appartenenti cioè al base64.

Come si può vedere dall'immagine precedente, le righe del base64 sono composte da 60 caratteri. Eliminando i caratteri e gli spazi dovuti al file KeePass.ini, si otteneva una riga di 62 caratteri (19 righa superiore + 43 riga inferiore)
0zSSN3ccl8cq+3twH+P a cui si aggiungeva vjAlWAOxKkA/tsSPg7j5Gx/q9ffQL5Jpa6ymya7CU05
Il trio ha operato al fine di ottenere comunque la riga da 60 caratteri, eliminando da quella superiore anche i caratteri +P.
In questo modo sono riusciti a convertire il base64, ottenendo una jpg molto più utilizzabile della nostra!!

Complimenti a loro!! Non si finisce mai di imparare!!

Note a margine:

• se qualcuno pensa che l'individuazione della password per aprire il db di KeePass, attraverso un lavoro di profiling svolto sull'indagato basandosi sulle informazioni ottenute dall'analisi delle mail, fosse irrealizzabile si ricreda!
  Nelle discussioni post game è emerso che NAlaki (utente di CFI ML) vi è riuscito, come risulta dalle sue parole in lista " ..per la cronaca...nel mio piccolo comunque ero riuscito a trovare la password per aprire il db di password..".
  Se nei prossimi giorni troverà il tempo di scrivere due righe con cui spiega il suo operato non mancheremo di aggiungerle.
• possibili errori:
  • qualcuno a perso molto tempo cercando di analizzare i caratteri evidenziati in rosso nell'immagine sottostante, presenti tra l'altro nei settori dall'1 al 62 e nell'ultimo, al di fuori della partizione (ma non solo), pensando
    
    
    

    di trovarsi davanti a qualche informazione codificata, mentre in realtà si stava scontrando con un pattern "di fabbrica" presente sui device nuovi.
  • diversi utenti hanno proceduto a clonare l'immagine su una chiave usb, operazione in realtà non necessaria.
    Uno di questi, dopo alcuni giorni, ci ha messo in allarme informandoci di aver recuperato immagini estranee al game, che noi autori non avevamo inserito.
    La possibilità che l'immagine dd fosse stata sostituita, o alterata, ci sembrava piuttosto improbabile. Dopo avergli fatto verificare l'hash dell'immagine dd per essere certi della sua integrità ed aver, per scrupolo, svolto ulteriori controlli sull'immagine da noi realizzata, non individuando le immagini estranee, abbiamo quindi pensato a una non perfetta sterilizzazione del dispositivo di destinazione ed è quanto ci ha confermato nei giorni successivi l'interlocutore.
    In realtà non vi è stata mancanza nell'operatore, che aveva svolto la prevista (dalle best practices) opera di wiping utilizzando "Darik's Boot and Nuke" v.1.0.7, un live-cd destinato alla sanitificazione dei drive, ma che evidentemente non aveva operato a dovere, non andando a sovrascrivere con il pattern impostatogli tutto lo spazio disponibile, permettendo così la "sopravvivenza" di files di precedenti esercizi nello spazio non allocato.
    Fortunatamente stavamo affrontando solo un game!!

 

---

Conclusioni ed inviti:

 

È possibile che alcune scelte da noi fatte (non comunicare il numero di obiettivi da individuare, richiedere il report) abbiano demotivato qualcuno e fatto pensare ad altri, dopo aver trovato le prime informazioni nascoste, che il game fosse già terminato. Terremo in considerazione questi aspetti nell'organizzazione del prossimo CFI game, speriamo in autunno.
Ci auguriamo che la soporifera () lettura da voi affrontata per giungere sin qui, dimostri che il game non era banale e vi stimoli a ripetere i passi qui descritti, o a provarne di diversi per raggiungere gli stessi risultati.
Le vostre opinioni, le problematiche che affronterete, le diverse soluzioni che individuerete, o gli errori che commetterete ci interessano assolutamente!!

Se le spiegazioni riportate sopra non vi sono di aiuto...scriveteci ugualmente, compatibilmente con il nostro poco tempo libero cercheremo di aiutarvi.

 

---

Licenza:

 

CFI game 2008 spring è pubblicato sotto licenza Creative Commons Attribuzione-Non commerciale-Non opere derivate 2.5 Italia License.

 

CFI game 2008 spring by Denis Frati & Nanni Bassetti is licensed under a Creative Commons Attribuzione-Non commerciale-Non opere derivate 2.5 Italia License.