Indagini digitali. Vademecum di uno Sherlock Holmes informatico.

Citation preview

INDAGINI DIGITALI VADEMECUM DI UNO SHERLOCK HOLMES INFORMATICO

- 2011 di

NANNI BASSETTI

Questo testo è rivolto agli operatori del settore ed è pensato come ad un vademecum utile a fini formativi, di guidelines e di checklist.

DEFINIZIONE ........................................................................................... 4 L’INIZIO ..................................................................................................... 8 L’IDENTIFICAZIONE ........................................................................... 9 CHECKLIST...................................................................................... 13 L’ACQUISIZIONE................................................................................ 16 NON ALTERARE LA SORGENTE DEI DATI................................... 16 ANNOTARE TUTTE LE CARATTERISTICHE DEL DISPOSITIVO IN ESAME .............................................................................................. 17 DIFFERENZA TRA DOCUMENTO ELETTRONICO E QUELLO CARTACEO ...................................................................................... 24 OVERVIEW SUGLI STRUMENTI SW E HW ................................... 24 OPERAZIONI INIZIALI.................................................................... 25 ESEMPI D’USO................................................................................ 30 L’ANALISI E LA VALUTAZIONE ..................................................... 31 L’ANALISI FISICA .............................................................................. 37 FOREMOST ED I SUOI SEGRETI…. .............................................. 39 RECUPERARE UN FILE CANCELLATO ........................................ 42 FUNDL – File UNDeleter................................................................. 42 AIR 2.0.0 (Automated Image and Restore)........................................ 45 L’ANALISI LOGICA............................................................................ 47 L’ANALISI LIVE - INCIDENT RESPONSE...................................... 47 PROFILING ...................................................................................... 49 LA RICERCA..................................................................................... 52 VALUTAZIONE ................................................................................... 54 REPORTING E PRESENTAZIONE ..................................................... 55 CASE HISTORY ...................................................................................... 55 ANCORA UN’INDAGINE FORENSE................................................... 63 SELECTIVE FILE DUMPER................................................................. 70 ALTRI CASI REALI ............................................................................... 72 PROBLEMI INSOLUTI .......................................................................... 74 ANTI-FORENSICS ALCUNE TECNICHE DI BASE ......................... 81 ALTRI SISTEMI ANTI FORENSICS ................................................... 86

2

THE SLEUTHKIT MINI GUIDA OPERATIVA.................................. 87 RAW2FS E SCRIPTS4CF SCRIPTS AND TOOLS... .......................... 93 XMOUNT FINALMENTE LIBERI DI VIRTUALIZZARE! .............. 96 IL SETTORE DANNEGGIATO E L'ACQUISIZIONE FORENSE... 98 IL MISTERO DI $LOGFILE NELL'MFT.......................................... 102 PILLOLE DI SAGGEZZA .................................................................... 105 COME SI FA A SAPERE QUANDO IL COMPUTER È STATO ACCESO/SPENTO? ............................................................................................................. 105 ACQUISIZIONE VIA RETE............................................................... 106 HASH DISCO CLONATO SU DISCO PIÙ GRANDE ....................... 106 STERILIZZARE E CONTROLLARE: ............................................... 107 PROCEDURA DI ACQUISIZIONE DA LIVE CD (ES. CAINE) ....................... 108 VIRTUALIZZARE IL FILE IMMAGINE CON VIRTUALBOX ........... 108 HASHBOT - CONGELIAMO IL WEB! ........................................................ 109 CREARE UN TIMELINE CON SLEUTHKIT ................................................. 110 I FUNDAMENTALS LEGALI.............................................................. 111 RIFERIMENTI STORICI E LINEE GUIDA...................................... 112 CONCLUSIONI...................................................................................... 114 LINKS INTERESSANTI:...................................................................... 115

3

Definizione La Digital Forensics è la disciplina scientifica che serve per identificare, acquisire ed analizzare una prova digitale, preservandola da eventuali alterazioni. Scientifica: ripetibile (Galileo Galilei) Prova: deve garantire il suo uso in tribunale. Viviamo in un’epoca digitale, siamo immersi nei dispositivi elettronici e portiamo addosso svariati Gigabyte di memoria, USB Flash memory, Memory cards per telefonino e per macchina fotografica, palmari, computer portatili, IPod, IPhone, ecc. ecc. Tutta questa memoria digitale è molto utile per tante applicazioni, però è anche un deposito di informazioni, non sempre “innocenti”. Quando si pensa alle perizie informatiche, si associano spesso a reati informatici, i cosiddetti CyberCrimes, le truffe su internet, il phishing, ecc. Questa percezione è errata, perché ogni reato oggi ha a che fare con i dispositivi digitali, dal falso in bilancio all’omicidio, dalle minacce alle truffe, dalla pedofilia al terrorismo. Non bisogna credere che la perizia su un computer o su una sim card vada compiuta solo a seguito di un crimine “prettamente” informatico, perché nel momento in cui qualcuno commette un reato, c’è l’alta probabilità che abbia pianificato, ricercato, scritto e conservato qualcosa su una memoria digitale, sia esso un hard disk, dei DVD o CD-ROM, una memoria flash, la sim card del telefonino, fino a giungere addirittura al nastro digitale di una videocamera casalinga. Spesso s’ignora la repertazione dei media informatici/elettronici e si tende a carpire la verità con i sistemi classici, con l’analisi di carte , fascicoli e testimonianze (a volte inattendibili), quando magari si potrebbe risparmiare tempo ed 4

avere prove “schiaccianti” individuando un documento elettronico in cui l’indagato pianificava l’omicidio della moglie o si documentava per costruire una pipe-bomb. A volte, se si trova un computer in casa dell’indagato, si procede al sequestro, servirebbe tuttavia ragionare in senso più ampio procedendo al sequestro e all'analisi d’ogni singola memoria presente nei luoghi frequentati dall’indagato (l’ufficio per esempio), perché magari non c’è alcunché sul computer, mentre nella chiavettina usb che questi porta nella tasca dei jeans sono memorizzati documenti o files compromettenti. È solo una questione di mentalità ed abitudine, riuscire a dissociare l’indagine informatica dal concetto di crimine informatico e legarla alla commistione dei crimini comuni. Qualcuno potrebbe obbiettare che in TV e sui giornali si sente spesso parlare di sequestri ed analisi sui computer degli indagati, (il caso del piccolo Tommy Onofri, del palmare della Lioce, il caso di Garlasco o di Meredith di Perugia, di BrendaMarrazzo), sorge però il sospetto che queste repertazioni informatiche avvengano solo in presenza di “casi importanti”, lasciando il dubbio che tali metodiche non vengano messe in atto per far fronte a casi di divorzio, minacce, molestie, mobbing . La casistica giurisprudenziale italiana non c’è d’aiuto per comprendere se le metodiche e procedure d’indagine digitale trovino spazio anche per investigazioni minori. Lo scopo di questa riflessione è di porre all'attenzione del lettore sulle possibilità investigative che l'informatica forense offre, portandolo a considerare l’indagine informatica quale valida, inscindibile ausilio dell'indagine tradizionale, strumento da non scordare e da non relegare ai soli casi di criminalità informatica. La scienza forense applicata all’informatica è ancora una materia giovane ed in via di sviluppo, ma in particolar modo 5

una scienza in divenire, al costante inseguimento della tecnologia. L’autorità Giudiziaria, spesso non riesce a star dietro a tutto questo, non sapendo inoltre come comportarsi di fronte a dati così facilmente alterabili e, a volte, deperibili. È quindi compito degli investigatori del futuro adottare un protocollo comune di repertazione, custodia ed analisi dei dati. È a tal fine necessario seguire un protocollo, d’acquisizione ed analisi, preciso e stringente in modo da evitare di invalidare le prove. Se si acquisisce l’arma del delitto a mani nude o si esegue un’analisi distruttiva su di un indizio di prova repertato, con la conseguente impossibilità di effettuare una controperizia, si rischia di invalidare il procedimento, stessa cosa dicasi per gli elementi informatici. Tra i giuristi italiani si può riscontrare una mancanza culturale riguardo alla fragilità delle “evidence” digitali, che può portare a non valutare correttamente le conseguenze e le implicazioni legali di una perizia effettuata nel mancato rispetto delle “best practices”. Questo può portare a grossolani errori sia in accusa sia in difesa. Portiamo un esempio per comprendere meglio la problematica: Ipotizzando di avere un accusato di mobbing, che usava l’email per svilire il lavoro di un proprio dipendente, se la perizia sul computer dell’indagato è fatta in modo scorretto, potrà risultare che non vi era stato alcun carteggio elettronico offensivo tra il capo ed il dipendente, l’avvocato difensore tenterà in tal caso la strada delle testimonianze, non valutando l'utilità di una controperizia, che se fatta bene avrebbe svelato le e-mail probatorie, magari cancellate dall'accusato. Uno scenario ben peggiore può essere disegnato nel caso di una perizia che poggia sull'esecuzione di procedure errate già nelle 6

primissime fasi, magari accendendo il computer. Quanti sanno che in tali casi quella perizia può essere invalidata? Quindi prima di tutto il PROTOCOLLO. Esso si basa, per ora, su una serie di regole ereditate dal mondo anglosassone, che ci guida nella repertazione corretta, nella creazione di una catena di custodia dei reperti e nel reporting finale delle analisi effettuate, creando un processo non distruttivo ma ripetibile. Scopo di questo testo è quello di fornire un protocollo procedurale, sicuramente non il migliore ed esaustivo in assoluto, finalizzato all'esecuzione delle operazioni d’acquisizione ed analisi nel rispetto delle norme vigenti e del mantenimento della prova inalterata. Sarà inoltre preso in esame il targeting dell’indagine, ossia capire cosa cercare, dove cercarlo, realizzando nel caso un profiling del possessore del mezzo informatico, poiché un tecnocrate appassionato avrà modo di conservare e cancellare le proprie tracce in maniera totalmente diversa da un utente normale di computer. I campi d’azione della Digital Forensics sono: 1) Indagini interne ad un’azienda 2) Supporto alla Polizia Giudiziaria ed ai PM (CTU) 3) Supporto ai privati indagati (CTP) 4) Valutazione danni 5) Spionaggio 6) Frode 7) Pedopornografia 8) Violazione policy 9) Ricatto 10) Terrorismo 7

11) Ecc.

L’INIZIO La Digital Forensics si snoda attraverso quattro fasi principali:

1) Identificazione

2) Acquisizione

3) Analisi e valutazione

4) Presentazione

8

L’IDENTIFICAZIONE Sulla scena del crimine bisogna, innanzi tutto, identificare ogni dispositivo che può contenere prove (digital evidences),per poi acquisirlo. EVITARE di: • Aver fretta. • Improvvisarsi esperti su sistemi sconosciuti. • Usare strumenti non collaudati e/o improvvisati. • Esprimere pareri personali, NOI siamo TECNICI non Avvocati o Psicologi. • Rilevare sempre il tempo e la data usando strumenti affidabili e attenzione al formato (GMT o UTC). Attualmente, i dispositivi digitali che possono contenere le prove sono tantissimi e spesso sono così, inseriti nel nostro habitat da non farci più caso. 9

Esempi: 1) Computers 2) Memory cards 3) Nastri digitali 5) SIM cards 6) Cd-DVD rom 7) Smart printers 8) Smart Fax 9) Lettori MP3/AVI 10) Playstation et similia 11) ecc.

10

Al momento dell’analisi della scena si dovrà capire cosa prendere per poi analizzarlo. Spesso durante i sequestri s’ignorano o tralasciano alcuni dispositivi che potrebbero contenere informazioni preziose.

11

Non è detto che la prova, la cosiddetta “smoking gun” sia sul computer di casa….anzi potrebbe essere su un DVD con la copertina degli “Aristogatti” di Walt Disney. Nella fase di sequestro si commettono spesso degli errori. • • • • •

Questo perché la D.F. è ancora una scienza senza protocollo comune. Molte polizie usano diversi sistemi, così come molte magistrature. Non ci si preoccupa della ripetibilità del metodo utilizzato. Non ci si preoccupa della preservazione della prova. Non ci si preoccupa della catena di custodia e del corretto modo di presentare i risultati delle indagini informatiche (reporting).

Ecco una checklist, che potrebbe tornare utile nel caso si dovesse partecipare ad un sequestro e non si hanno informazioni su cosa si troverà sul posto:

12

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. 13

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) Erichettare ogni cosa ed 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.

14

In sintesi:
Usare i guanti elettrostatici.
Fotografare e documentare tutte le fasi di acquisizione
Utilizzare dischi affidabili.
Consigliabile l’utilizzare del write blocker hardware per proteggere i dischi sorgente
Calcolare sempre il codice hash del disco sorgente e dei file interessanti
Utilizzare buste elettrostatiche e impacchettare i dischi in contenitori anticaduta
Analizzare i dispositivi in ambiente sicuro.
Garantire la riservatezza, integrità e disponibilità dei dati trattati
A fine incarico, ove possibile, non conservare i dati acquisiti.
Di fronte ad un sistema non conosciuto non improvvisare ma prendere le opportune precauzioni con i giusti tempi. E con i Mobile Devices?
PDA, Cell Phone & Digital Camera
Personal digital assistants, cell phones e le digital cameras possono conservare dati direttamente nella memoria interna o possono contenere memorie rimovibili.
•Se il dispositivo è “off”, non metterlo in “on”. (in pratica non accenderlo!)

15

L’ACQUISIZIONE Definizione di copia conforme e perché debba essere fatta in un certo modo…. Al momento di acquisire un dispositivo, bisognerà essere attenti a parecchi fattori: 1) Non alterare la sorgente dei dati. 2) Annotare tutte le caratteristiche del dispositivo in esame. 3) Annotare tutti i dati del bios. 4) Non inquinare il dispositivo, alterando eventuali tracce classiche (polvere, insetti morti, impronte, ecc.). 5) Registrare tutto con videocamera e/o registratore vocale. 6) Creare una “copia” conforme bit a bit. 7) Hash.

NON ALTERARE LA SORGENTE DEI DATI Significa evitare manomissioni di qualsiasi genere, specialmente operazioni di scrittura sulle memorie del dispositivi. Le operazioni di scrittura possono essere eseguite anche con il semplice spegnimento della macchina oppure con l’uso di software sulla macchina in azione, quindi la regola d’oro è: 1) Se la macchina è spenta la lasciamo spenta 2) Se è accesa la lasciamo accesa e registriamo tutto con videocamera, chiamiamo un esperto del dispositivo in oggetto per capire come preservare tutti i dati e processi in modo da poterli analizzare in seguito. 3) Nel caso siamo sicuri, è meglio staccare la spina brutalmente, in modo da non far eseguire le operazioni 16

di shutdown al sistema operativo, perché quell’operazione compie delle scritture che alterebbero lo stato originale della macchina al momento. 4) Non spegnere il computer se si sospetta la presenza di file system criptato, altrimenti se l'indagato non collabora, non rilasciando la password, potrebbe essere molto difficile accedervi.

ANNOTARE TUTTE LE CARATTERISTICHE DEL DISPOSITIVO IN ESAME Conviene sempre scrivere e/o registrare tutto circa il dispositivo in esame: marca, modello, numeri seriali, capacità delle memorie, BIOS, ecc. Questo per evitare possibili contestazioni future. ANNOTARE I DATI DEL BIOS Il BIOS (Basic Input Output System) è quel firmware che conserva tutte le caratteristiche del computer in esame, come la data, l’ora, la geometria degli hard disk, la sequenza di boot. È importante segnare l’orario e la data in modo da sincronizzarsi col sistema quando andremo a fare l’analisi dei files. NON INQUINARE IL DISPOSITIVO, ALTERANDO EVENTUALI TRACCE CLASSICHE Nel maneggiare il dispositivo, accertiamoci di non cancellare eventuali tracce utili alla squadra scientifica delle forze dell’ordine, quindi magari facciamo repertare prima le possibili evidenze classiche come macchie di sangue, polvere, impronte digitali, ecc.

17

REGISTRARE TUTTO CON VIDEOCAMERA E/O REGISTRATORE VOCALE Sarebbe buona norma videoregistrare ogni azione intrapresa, anche se potrebbe bastare anche la testimonianza del tecnico della controparte o di un membro delle forze dell’ordine. La videoregistrazione è particolarmente consigliata nel caso di una Live Analisys, ossia un’analisi dal vivo, su un sistema accesso, su un flusso di rete oppure in quei casi in cui l’acquisizione non sia ripetibile o non conforme, come ad esempio un hard disk o CD/DVD-ROM, rovinato. Nel caso in cui incontriamo un hard disk rovinato, potremo acquisire con degli strumenti come il dd_rescue o ddrescue (versione modificata del noto dd), che riempie i bad cluster con degli zeri e adatta il padding dinamicamente alla dimensione del disco e non ai multipli del BS (byte size) prescelto sulla riga di comando, ma così facendo avremo, inevitabilmente, una copia diversa dall’originale, quindi dovremo documentare tutto con testimonianze firmate e/o videoregistrazioni dell’acquisizione, nelle quali spieghiamo il perché non possiamo avere la copia esatta della sorgente dei dati. CREARE UNA COPIA CONFORME BIT A BIT Per acquisire una memoria digitale, le best practices della digital forensics, ci obbligano ad usare strumenti di acquisizione bit a bit, il che significa che la nostra copia non sarà più una copia, ma sarà esattamente uguale all’originale, perché bits non olent ossia essendo i bit immateriali, una volta che tutta la memoria viene riprodotto in ogni sua caratteristica, compreso lo slack space, i files cancellati, i files frammentati, insomma ogni bit presente sulla memoria in oggetto.

18

E con i mobile devices? •Lasciare accesi i mobile device serve ad evitare che all’accensione si presentino password o altri blocchi. • Se possibile, fotografare il display e le schermate. • Etichettare e acquisire tutti i cavi (compresi quelli di alimentazione) e portarli insieme al dispositivo. • Mantenere il dispositivo in carica. • Se il dispositivo non può essere mantenuto in carica, l’analisi deve essere fatta prima che si scarichi la batteria per collezzionare più dati possibili, che potrebbero andar persi dopo lo spegnimento e la riaccensione. • Sequestrare media aggiuntivi (memory sticks, compact flash, etc) e tenerle lontano da fonti magnetiche o radio. • Documentare ogni passo fatto. Live Analisys
Se sulla scena criminis l’informazione si trova su un sistema acceso?
Se il computer non può essere spento per motivi di sicurezza? (es. computer medicali, militari, videosorveglianza, ecc.)
Se lo spegnimento del computer creasse danno anche a terzi? (es. server di posta elettronica, database server, ecc,)
Il disco è criptato
Ciò che si cerca è in RAM
L’accesso al sistema è biometrico (impronta, retina, ecc.) 19







Allora si esegue un’analisi “live” del sistema: Uso di determinati tool Reporting di tutte le operazioni svolte Si procede seguendo l’ordine di volatilità

Ordine di Volatilità: • • • • • • • • • •

Registri di sistema Memoria cache Memoria delle periferiche (es. tabelle di routing) Processi in esecuzione Dischi Dati di log remoto e dati di controllo rilevanti per il sistema in esame Configurazione fisica del sistema informatico Topologia della rete Floppy CD/DVD e supporti ottici

RAM dump (win32dd, mdd, memimage, FTK Imager) Acquisition of volatile system information (processes, sysinternals, nirsoft, wft, ecc.) Logical copying of files Live acquisition of the entire system (FTK Imager, dd, ecc.) Si ricordino dei semplici principi: 1) Non spegnere il sistema con la procedura di spegnimento 2) Non usare programmi della macchina sospetta 3) Dump della RAM (quando e se possibile) 4) Cercare di copiare i media bit a bit 5) Lanciare un programma di listing dei processi, utenti, insomma salvare tutte le informazioni di runtime 20

6) Scollegarlo dalla rete se non serve essere connessi 7) Documentare tutto quello che si sta facendo 8) Eseguire tutti i tools (esterni) di Live Analisys

HASH Fonte: Wikipedia Nel linguaggio scientifico, l'hash è una funzioneunivoca operante in un solo senso (ossia, che nonpuò essere invertita), atta alla trasformazione di un testo di lunghezza arbitraria in una stringa dilunghezza fissa, relativamente limitata. Tale stringa rappresenta una sorta di "impronta digitale" del testo in chiaro, e viene detta valore di hash, checksum crittografico o message digest. L(lenght)= X bits , 4 bits (nibble) sono una cifra Hex quindi X/4=numero cifrehex generate da un algoritmo di hash. Es. MD5: L=128bits genera una stringa di 128/4=32 hex caratteri.

Fonte Wikipedia 21

Un codice hash viene generato da una funzione univoca che mappa un alfabeto infinito su di un alfabeto finito. Che significa quest’affermazione criptica? Niente di difficile, proviamo ad immaginare tutti i libri scritti e che si scriveranno, prodotti dall’uomo, questo è un alfabeto infinito (consideriamo ogni libro come una singola lettera), l’alfabeto di hash ha una lunghezza finita di un numero X di bit (secondo l’algoritmo usato), quindi è impossibile che per ogni libro ci sia un codice univoco, perché prima o poi i codici generabili termineranno, un po’ come gli indirizzi IP della rete Internet. Però è veramente improbabile che due libri diversi generino lo stesso codice hash, un po’ come trovare due DNA uguali, quindi quando acquisiamo una memoria digitale, dobbiamo preoccuparci di applicare una funzione di hash (es. MD5 o SHA1) al supporto originale ed alla sua copia, se essi coincidono vuole dire che ogni singolo bit della copia coincide col singolo bit dell’originale, da qui capiamo che la copia non è più considerabile “copia”, ma un originale duplicato. Degli scienziati cinesi sono riusciti a costruire due files diversi che generano due MD5 uguali, però i due files sono stati studiati a tavolino, quindi si può affermare, che allo stato attuale è impossibile alterare una fonte di dati in modo da farla coincidere con la copia pre-acquisita (a livello di codifica hash), anche perché sarebbe un lavoro immane ed imprevedibile. Secondo la RFC 4270: http://tools.ietf.org/html/rfc4270 “preimaging attack that costs trillions of dollars and takes decades to preimage one desired hash value or one message is not practical; one that costs a few thousand dollars and takes a few weeks might be very practical.”

22

Ossia un pre-image attack, cioè dato un codice hash noto (quello del giorno dell’acquisizione, per esempio), devo riuscire a trovare un modo per alterare il supporto in modo da ottenere lo stesso hash, costa trilioni di dollari e richiede decenni per essere attuato. In ogni caso per ovviare ad ogni tipo di obiezione, non costa nulla applicare due funzioni di hash durante il processo di acquisizione (es. Md5 e Sha1) oppure usare un algoritmo tipo SHA256 che non ha presentato ancora collisioni.

23

DIFFERENZA TRA DOCUMENTO ELETTRONICO E QUELLO CARTACEO Come detto prima il documento elettronico di per sé non ha caratteristiche uniche, come quello cartaceo, infatti, è improprio parlare di copia digitale, anche se d’uso comune, ma si tratta di vera e propria clonazione o duplicazione dell’informazione. Se pensiamo ad un documento cartaceo, esso ha caratteristiche intrinseche, come la carta usata, l’inchiostro, eventualmente la grafia o la stampante, mentre il documento elettronico non è che una serie di bit messi in un certo ordine, quindi nel momento in cui lo duplichiamo avremo un clone indistinguibile dall’originale (chiaramente si parla di duplicazione bit a bit e non col copia ed incolla). Il documento elettronico, però è soggetto a problematiche d’alterazione, molto più facili da eseguire rispetto al cartaceo, per questo bisogna sempre cristallizzarlo con una codifica hash, come detto prima.

OVERVIEW SUGLI STRUMENTI SW E HW Gli strumenti che si utilizzano nell’acquisizione sono un mix di hardware e software. Di fronte ad un dispositivo digitale da acquisire potremmo aver bisogno di: 1) Interfacce ATA/SATA/USB/Firewire 2) Cavi elettrici/Cavi di collegamento IDE/EIDE/SATA, cavi firewire, cavi di rete crossati e non. 3) Hard disk esterni 4) Schede di rete ad alta velocità 24

5) Write Blocker 6) Videocamera/registratore vocale/macchina fotografica 7) Interfacce IR/Bluetooth/Wi-Fi 8) Buste/contenitori antistatici ed imbottiti 9) Torcia elettrica/cacciavite multiuso 10) Lettore DVD/CD rom 11) Workstation di lavoro e di backup.

OPERAZIONI INIZIALI Le operazioni di acquisizioni iniziali, per un PC, sono sintetizzabili in alcuni punti: 1) Aprire il case del PC 2) Staccare gli hard disk ed annotare tutto ciò che c’è scritto sulle targhette 3) Accendere il PC 4) Andare nel BIOS ed annotare tutto e verificare la sequenza di boot 5) Nel caso in cui non c’è già il cd-rom come dispositivo iniziale di boot: 5.a) Cambiare la sequenza di boot (non consigliabile) 5.b) Portare l’hard disk suspect sulla propria workstation di lavoro 6) Nel caso in cui c’è il cd-rom come dispositivo di boot iniziale, si potrebbe utilizzare il PC suspect stesso per far partire un Live Cd di acquisizione. Questo caso è valido solo se si sta usando un laptop come workstation di lavoro, altrimenti è sempre meglio staccare l’hard disk sospetto e montarlo sulla propria workstation di lavoro. 7) Se la propria workstation è un sistema Windows bisognerà usare un dispositivo di Write Blocking, un Write Blocker hardware, macchinetta che serve ad 25

intercettare le chiamate di scrittura sui dischi (inibendo l’INT 13h del BIOS e sostituendo l’INT 13h suo, che non effettua alcuna operazione di scrittura) se il WB è BIOS based, altrimenti ci sono anche i W.B. software e quelli hardware che “tagliano” la comunicazione fisica tra mainboard e disco (sono i più affidabili e sicuri), questo perché Windows tende a marcare i dispositivi a lui agganciati al fine di metterli nel registro di configurazione per velocizzarne gli accessi futuri. Inoltre il write blocking serve ad evitare che si alterino, anche per sbaglio, i dati sui dispositivi.

26

8) Se invece si ha una workstation con sistema Linux o Live Distro (es. CAINE, Helix, DEFT, ecc.) non c’è bisogno del write blocker (anche se è sempre più sicuro averlo), poiché, specialmente le Live Distro forensi, non montano in scrittura i dispositivi a loro agganciati, quindi è come se ci fosse un write blocking software, dato che i dispositivi non sono montati automaticamente all’avvio, quindi si può procedere all’acquisizione senza montare il disco indagato, ma solamente il disco dove alloggerà la copia. 9) Nella propria workstation di acquisizione dobbiamo avere un hard disk pulito e capiente per ospitare l’immagine dell’hard disk da acquisire. 9.a) L’hard disk può essere acquisito come file immagine, ossia un file binario di dimensioni pari alle dimensioni dell’hard disk suspect, in seguito questo file potrà essere “montato” sul filesystem o dai vari software di analisi, in modo da visualizzarlo come un dispositivo fisicamente presente. 9.b) L’hard disk può essere acquisito come “clone”, ciò significa che sull’hard disk di archiviazione (storage) avremo una copia esatta dell’hard disk suspect, visto in maniera “esplosa”, cioè sfogliabile. Questo sistema è sconsigliabile per due motivi: difficile gestione, l’hard disk di archiviazione deve avere la stessa geometria dell’hard disk originale, al fine di non alterare gli indirizzamenti fisici. 10) In ambedue i casi esposti nel punto 9, l’hard disk di storage deve essere sterilizzato, cioè formattato ed azzerato, per azzeramento si intendono le operazioni di wiping o shredding, ossia più cicli di 27

scrittura di zeri o caratteri casuali su tutta la superficie magnetica del disco, in modo da evitare, che durante le analisi, escano fuori frammenti di informazioni di ciò che c’era prima su quel disco. Queste operazioni si possono fare con strumenti software come wipe, shred o dd (ci sono le versioni sia per Windows sia per Linux e sono open source). 11) Una volta attaccato l’hard disk suspect alla propria workstation, non resta che lanciare alcuni tools di analisi delle partizioni, del filesystem ed informative sullo stato del disco per poi scegliere come e cosa acquisire. I software commerciali, in genere, hanno tutte queste operazioni integrate nelle loro GUI, mentre per chi utilizza Linux, converrebbe sempre lanciare i comandi: hdparm – comando che dà informazioni sul disco fdisk – mmls – fsstat - disk_stat – comandi (gli ultimi tre sono di Sleuthkit), che ci servono a raccogliere informazioni sulle partizioni, le HPA (Host Protected Area), i DCO (Device Configuration Overlay) ed altre amenità sul disco. HPA e DCO sono aree riservate dei dischi (ATA 4 e ATA 5 e 6) che possono contenere informazioni messe lì dai produttori, come password, diagnostici vari, ecc. (per disattivare le HPA e DCO consultare documentazione di hdparm http://www.forensicswiki.org/wiki/DCO_and_HPA e ataraw http://www.afflib.org ). 12) Infine possiamo procedere all’acquisizione del disco utilizzando programmi GUI sotto Linux come sotto Windows, oppure il buon vecchio dd e se fosse necessario il ddrescue.

28

13) Programmi GUI per Linux: AIR, GUYMAGER Programmi a linea di comando per Linux/Windows: dd, dc3dd, ddrescue, dcfldd. Programmi GUI per Windows: Encase, WinHex, UTK, ecc. 14) Acquisizione tramite rete se non si ha la possibilità di accedere ai dischi e/o non abbia lettori ottici, quindi usando, per esempio, dd con netcat. 15) Ultimo passo prima di passare all’analisi è quello di creare il file di hash per l’originale e per la “copia”. Nel caso si usino programmi GUI come AIR o GUYMAGER, allora non bisogna far alcunché, visto che il programma è predisposto a fare tutto ciò che serve, incluso un log file enorme che descrive tutta la macchina sulla quale si sta facendo l’acquisizione. Altrimenti si possono usare i programmi: md5sum, sha256sum (open source Win/Linux). Se i due codici di hash coincidono allora abbiamo terminato con successo l’acquisizione, altrimenti bisognerà capire cosa è andato storto ed a quel punto, in mancanza di soluzione (es. bad clusters) bisognerà ricorrere alla non ripetibilità dell’operazione, documentando il tutto e spiegando nei dettagli cosa è successo. 16) Si termina l’acquisizione con la compilazione dei documenti di catena di custodia e la verbalizzazione di tutte le operazioni effettuate.

29

ESEMPI D’USO Creazione file immagine con dd dd if=/dev/hda of=/mnt/sda/disco.dd bs=4K conv=noerror,sync sintassi del comando dd per copiare l’hard disk sorgente (/dev/hda) sul file immagine (disco.dd) da scrivere sul hard disk montato (/mnt/sda) leggendo blocchi di 4Kb ed impostando il noerror per non fermarsi ai bad cluster ed il sync per riempire i bad clusters con degli zeri (padding). Il problema è che se la dimensione dell’hard disk sorgente non è multipla di 4Kb, si avrà un file immagine di dimensione diversa perché il file immagine (disco.dd) sarà multiplo di 4Kb, questo in caso si siano incontrati degli errori durante la lettura del disco sorgente. Per ovviare a questo problema conviene usare ddrescue, oppure impostare il BS=512 così da rendere la dimensione del settore, evitando il problema di assorbire anche i settori NON danneggiati, per esempio, su 4Kb (8 settori da 512) magari un solo settore è danneggiato, ma gli altri 7 settori sono sani. che invece adatta dinamicamente il padding degli zeri, in ogni caso i due hash non coincideranno. Clonazione disco con dd dd if=/dev/hda of=/dev/sdb La differenza dall’esempio precedente è solamente nel parametro of=/dev/sdb invece di of=/mnt/sdb, infatti usando /dev si dice a dd di copiare un device fisico su di un altro device fisico, mentre se la destinazione è l’hard disk montato 30

(/mnt/sda) è come voler copiare un dispositivo fisico dentro una cartella (directory), cosa palesemente impossibile. Per capire meglio pensiamo ad una duplicazione di videocassetta, in questo caso si copia una videocassetta su un’altra videocassetta vergine (clonazione), mentre se volessimo copiare il film sul computer, dovremmo trasformarlo in file, ma così facendo lo svincoliamo dal supporto, infatti un file può stare dappertutto (USB flash memory, hard disk, dvd, ecc.). Azzeramento dell’hard disk con dd dd if=/dev/zero of=/dev/hda

L’ANALISI E LA VALUTAZIONE 1. L’analisi va effettuata sempre sulle copie e MAI sull’originale. 2. Si usino tools accettati de facto dalla comunità scientifica. 3. Open Source Vs Closed Source 4. L’esperienza e la fantasia 5. Il profiling Tutte le analisi e ricerche devono essere eseguite sulla copia (meglio se copia della copia) Oppure/anche In ambiente virtuale (VMWare, VirtualBox, Qemu,ecc.) Questo per il fine della ripetibilità. I tools possono essere commerciali od open source, l’importante che siano accettati dalla comunità dei forensers, al fine di fugare dubbi sull’affidabilità dello strumento usato. 31

In caso di sviluppo di strumenti nuovi, è utile fornire il codice sorgente. I tools commerciali potrebbero avere varie problematiche, come tutto ciò di cui non si conosce il sorgente: •

Bugs

•

Formati troppo proprietari

•

Fine dello sviluppo del sw

• I tools Open Source hanno dei vantaggi indiscutibili: •

Controllo dei Bugs da parte della community degli sviluppatori.

•

Formati aperti e compatibili

•

Sorgenti aperti a tutti -> Si sa cosa fanno

La scelta NON deve essere radicale, ci sono sw commerciali che fanno cose che gli open source non fanno e viceversa. ALCUNI TOOLS OPEN SOURCE Live distro Linux: •

Helix

•

CAINE

•

FCCU

•

DEFT

•

ForLex

•

GRML

32

Deft

Caine 2.0

Forlex

FCCU

Helix

33

CAINE Linux Computer Forensics Distro CAINE (Computer Aided INvestigative Environment) è una distribuzione live GNU /Linux creata come un progetto italiano di Digital Forensics

CAINE forense offre un ambiente completo organizzato per integrare strumenti software esistenti di moduli software e per fornire una interfaccia grafica amichevole. Gli obiettivi principali che il progetto CAINE mira a garantire sono i seguenti: • • •

Un ambiente interoperabile che supporta l'investigatore digitale durante le quattro fasi dell'indagine digitale. Un’amichevole interfaccia grafica per l’utente. Una compilazione semi automatica della relazione finale.

34

CAINE rappresenta pienamente lo spirito della filosofia Open Source, perché il progetto è completamente aperto, chiunque potrebbe prendere l'eredità del precedente sviluppatore o di responsabile del progetto. La distro è open source, il lato Windows (Wintaylor) è open source e, l'ultimo ma non meno importante, la distro è installabile, dando così una lunga vita a questo progetto.

Caine dispone dei Nautilus preview scripts, sviluppati ad hoc per il progetto e di tutte le patch utili a non alterare i dati dei supporti da acquisire/analizzare.

35

ALCUNI TOOLS CLOSED SOURCE •

Encase(GuidanceSoftware)

•

ForensicToolkit (Access Data)

•

X-WaysForensic(X-Ways)

•

P2 Commander(Paraben Corporation)

•

Pro Discover(TechnologyPathways)

•

Macintosh Forensic(Blackbag)

Nel momento in cui abbiamo l’immagine del disco da analizzare, possiamo realizzare tre tipologie d’analisi: 1) Analisi fisica 2) Analisi logica 3) Analisi Live

36

L’ANALISI FISICA L’analisi fisica comporta l’identificazione ed il recupero dei dati su tutto il drive fisico non considerando il file system, quindi senza alcun’organizzazione logica. I metodi applicabili sono: keyword searching, file carving ed estrazione delle tabelle di partizione e dello spazio inutilizzato sul drive fisico. Questo tipo di ricerca ed estrazione hanno delle limitazioni, perché l’informazione non è organizzata dal file system, quindi i dati allocati in settori non contigui diventano veramente difficili da trovare, se non impossibili. Dice Brian Carrier, (creatore di Sleuthkit ed Autopsy), che questa tipologia (sector by sector) di ricerca va utilizzata per casi MOLTO importanti e se pensiamo di applicarla, anche solo ad un hard disk di 10Gb, ecco i tempi che ci vorrebbero: 10 GB = 20,971,520 sectors 5 sec / sector > 3 anni (senza interruzione) Esempio di carving: Il carving è quella tecnica per estrarre dei files da una base binaria (files binari, immagini di dischi, files di cache, ecc.) utilizzando gli header ed i footer noti. Per esempio le immagini JPG JFIF hanno l’header pari FF D8 ed il footer FF D9 (codici esadecimali). Quindi se con un editor esadecimale apriamo un file che contiene delle jpg (es. Thumbs.db) e cerchiamo la prima occorrenza di FFD8 poi marchiamo il blocco, poi cerchiamo la 37

prima occorrenza, a partire da dove siamo, di FFD9 e marchiamo il blocco, avremo catturato un blocco di dati che iniziano da FFD8 e finiscono a FFD9, a questo punto basterà copiarli ed incollarli, sempre su un editor esadecimale e poi salvare il tutto come “file1.jpg”. Questa tipologia di carving è quella manuale e la più lenta in assoluto. Potremmo utilizzare foremost, scalpel o PhotoRec, per estrarre tutti i files automaticamente. Esempio di foremost per l’estrazione delle immagini JPG: foremost –t jpg –i /media/disco.dd –o /media/sda1/output Oppure utilizzare dei tools specifici open source commerciali.

o

Infine c’è sempre il buon dd, anche se è un sistema manuale e lento, però per completezza è utile descrivere un carving con dd. Cerchiamo con un editor esadecimale la prima istanza di ffd8 poi annotiamo il valore esadecimale dell'indirizzo poi cerchiamo ffd9 annotiamo valore hex dell'indirizzo poi convertiamo in decimali Otterremo inizio, fine Facciamo: fine - inizio = diff dd if=image_carve.raw count=diff

of=carv.jpg

skip=inizio

bs=1

38

dove diff rappresenta la lunghezza in bytes del file.

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 39

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 File Foremost started at Fri Mar 28 11:59:15 2008 Invocation: foremost usb.dd Output directory: /home/nemo/immagini_dd/output Configuration file: /usr/local/etc/foremost.conf -----------------------------------------------------------------File: usb.dd Start: Fri Mar 28 11:59:15 2008 Length: 962 MB (1009254400 bytes) Num Name (bs=512) Size File Offset Comment 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 file nome_file=611 >> il settore in cui si trova, il cui offset è 611*512=312832 dove 512 bytes è la misura minima del settore.

40

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 ................

Se vogliamo cercare uno o più file con header non standard dobbiamo creare un file .conf (es. foremost.conf) nel qualse scriviamo i bytes dell’header e/o del footer in questa maniera: m4a y 8000000 \x00\x00\x00\x1C\x66\x74 \x00\x00\x2C poi lanciare foremost così: foremost –c foremost.conf –i disk.dd –o ./carving

41

RECUPERARE UN FILE CANCELLATO Se conosciamo il cluster iniziale di un file cancellato e quello finale, grazie ad Autopsy o ad istat del file, la procedura per un recupero fisico è: effettuare il calcolo (numero_del_cluster + starting_sector_della_partizione) * dim_cluster = indirizzo_decimale_in_byte sia per il primo cluster sia per quello finale. diff=indirizzo_in_bytes_finale - indirizzo_in_bytes_iniziale poi estrarre il file col dd: es: dd if=disco.dd of=/home/recover/ciccio.jpg bs=1 skip=indirizzo_iniziale count=diff

FUNDL – File UNDeleter Oppure usando uno script come FUNDL, che elenca tutti i file cancellati o solo quelli di un certo tipo (es. doc, jpg, ecc.) usando fls, scrive l’i-node del file ed il suo nome in un file di testo ed infine, tramite icat, estrae il file corrispondente all’inode elencato: # /bin/bash/ # FUNDL 2.0- File Undeleter # Undelete tool by Nanni Bassetti - [email protected] http://www.nannibassetti.com - http://www.cfitaly.net # special thanks to Denis Frati http://www.denisfrati.it echo "FUNDL 2.0 - File Undeleter - by Nanni Bassetti "

42

echo "http://sfdumper.sourceforge.net/fundl.htm" echo "Insert the image file or the device: " read imm echo "Insert the output directory:" read outputdir mkdir $outputdir echo "Insert the file extension or * for all:" read c if [ "$c" = "" ] then c="*" fi ######################### if ! (mmls $imm > /dev/null ) 2>/dev/null then offs=0 echo "If mmls can't determine the partition type" echo "I try the starting sector 0" else mmls $imm echo "Insert the partition starting sector (eg. 63):" read offs fi echo "Insert the file system type:" fls -f list read fs fls -d -r -p -f $fs -o $offs $imm >$outputdir/filelist.txt htmhead="File Names and PathsFUNDL 2.0 Report
File Names and Paths found:

" htmend="" echo $htmhead > $outputdir/filenames.htm for i in $(grep "*" $outputdir/filelist.txt|sed 's/[[:space:]]//g'|sed 's/r\/r//') # inode:nomedire/filename do inode=$(echo $i | awk -F ":" '{print $1}'|sed 's/*//' | sed 's/-\/r//') name="$(echo $i | awk -F ":" '{print $2}')"

43

if [ "$c" != "*" ] then ext=${name##*.} if [ "$ext" = "$c" ] then icat -f $fs -o $offs -r $imm $inode > $outputdir/$inode"_"${name##*/} 2>/dev/null fn=$inode"_"${name##*/} echo "$name
" >> $outputdir/filenames.htm fi else icat -f $fs -o $offs -r $imm $inode > $outputdir/$inode"_"${name##*/} 2>/dev/null fn=$inode"_"${name##*/} echo "$name
" >> $outputdir/filenames.htm fi done echo $htmend >> $outputdir/filenames.htm cd $outputdir ls -ag echo "File names are composed by i-node_filename but in the filenames.htm there are their original paths and names." exit

44

AIR 2.0.0 (Automated Image and Restore) "A new version of AIR has been released. The primary change is that it now supports the dc3dd imager and doing 2 hashing algorithms. Thanks to Dr. Nanni Bassetti for his modifications and feedback that made this release possible. As always, feedback and comments appreciated." Questi sono I commenti di Steve Gibson su SourceForge.net per il lancio della nuova release della famosa GUI per le acquisizioni forensi AIR (Automated Image and Restore).

Mi ricordo quando ho usato per la prima volta questo prezioso e utile GUI per DD e DCFLDD, era il 2005. Il sottoscritto e migliaia di persone lo hanno amato e, nel 2010, sono nel team di sviluppo, perché ho modificato AIR

45

cambiando DCFLDD con DC3DD, aggiungendo il doppio hashing e l’impostazione del flag iflag.

AIR WEBSITE: http://air-imager.sourceforge.net/

46

L’ANALISI LOGICA La fase di estrazione logica identifica e recupera i files ed i dati basati sul sistema operativo installato, sul file system e/o sulle applicazioni. Questo significa che una ricerca per keywords stringhe sarà più efficiente, perché anche se il testo è spalmato su settori non contigui, il filesystem ci permette di ritrovare tutta la sequenza, come ci permetterà di trovare i files cancellati e/o orfani. Le applicazioni ci permetteranno di leggere i dati organizzati in formati proprietari, ecc. ecc. Chiaramente questo tipo di analisi si può fare nel momento in cui l’immagine dell’hard disk contiene ancora un file system.

L’ANALISI LIVE - INCIDENT RESPONSE 1) Non spegnere il sistema con la procedura di spegnimento 2) Non usare programmi della macchina sospetta. 3) Dump della RAM (quando e se possibile). 4) Cercare di copiare i media bit a bit. 5) Lanciare un programma di listing dei processi, utenti, insomma salvare tutte le informazioni di runtime (dai semplici date, time, netstat, ecc.). 6) Scollegarlo dalla rete se non serve essere connessi 7) Usare videocamere e registratore vocale per documentare tutto quello che si sta facendo

47

8) Eseguire tutti i tools (esterni) di Live Analisys (win32forensics, sysinternals, Nirsoft, WinTaylor, ecc.). Lo scopo della live analisys è quello di tracciare al volo: utenti, processi, connessioni in azione sul sistema indagato, a tal fine sono molto utili tools come: psloggedon, tcpview, pslist, ecc. Nell’ analisi LIVE c’è anche l’intercettazione, questa è usata quando si vuole analizzare i flussi di rete per capire eventuali sorgenti di attacco, spionaggio, uso illecito della rete, ricatto, ecc. ecc. A tal fine si possono usare varie tecniche: 1) Attacco man in the middle – tipologia di sniffing della rete dove un computer C si inserisce tra un computer A ed un computer B, in sostanza A crede che C sia B e B crede che C sia A, questo avviene “avvelenando la cache ARP. Questa tipologia di sniffing crea molto rumore sulla rete, dovuto alle molteplici richieste di Arp. 2) Attaccare un computer sonda (computer dotato di scheda di rete e di software di cattura pacchetti e dissector), ad una span port di uno switch. La span port è una porta di monitoraggio di alcuni switch di fascia medio-alta. 3) Attaccare un computer sonda all’HUB, che effettua un broadcast dei pacchetti su tutte le macchine collegate, fino a raggiungere la macchina target. 4) Si può attaccare un computer sonda ad una porta dello switch e poi creare sul computer sonda, un bridge virtuale, in modo da avere accesso al backplane virtuale (il circuito interno

48

degli switch sul quale viaggiano tutti i dati) e poter analizzare il traffico. 5) In caso di comunicazioni VOIP criptate, si può installare un trojan che ascolta il flusso di dati in ingresso (porta microfono) ed in uscita (porta scheda audio), converte il flusso in file audio e li invia ad un FTP creato ad hoc.

PROFILING Prima di affrontare le varie tecniche d’analisi, dobbiamo soffermarci sulla metodologia del profiling, ossia del tracciare un profilo psicologico del proprietario del dispositivo in analisi. Questo aspetto poco “tecnologico” e molto “umanistico”, serve a farci risparmiare molto tempo. Infatti, spesso con il social engineering (ingegneria sociale) e lo studio della vita dell’indagato, possiamo capire che tipo di analisi ci conviene effettuare. Se, ad esempio, sappiamo che l’indagato è un geek, quindi un maniaco della tecnologia, ha il computer partizionato con vari sistemi operativi, ha installato moltissimi tools anti-forensics, allora ci troviamo di fronte ad un bel problema e le nostre indagini ed analisi dovranno essere approfondite e non dovremo tralasciare alcunché. Diverso è il caso in cui l’indagato è un normal user che a stento naviga su internet, a quel punto, sicuramente non andremo a verificare se ha steganografato qualcosa, con notevole risparmio di tempo.

49

Nel profiling vi sono due approcci fondamentali: 1) Approccio induttivo. 2) Approccio deduttivo. Il primo approccio si basa sull’analisi fondata su basi statistiche di casi già avvenuti ed in un mondo come quello tecnologico, le statistiche sono in costante mutazione, poiché i crimini e gli attori cambiano radicalmente con l’evoluzione tecnica e con la maggior accessibilità ai mezzi ed alle conoscenze. L’approccio deduttivo invece è basato sugli elementi propri di un crimine come il modus operandi, la firma, la scena del crimine, la vittimologia e tutti gli elementi forensi per delineare un profilo comportamentale utile nei successivi passi dell'indagine, quindi con questo approccio non si usa una base dati, ma la correlazione delle evidenze della scena del crimine e degli elementi ad essa correlati per giungere, attraverso procedimenti deduttivi, al profilo criminale. Nella digital forensics è riduttivo parlare di hacker, perché costui è una figura particolare, in genere un hacker è qualcuno che commette degli illeciti informatici/tecnologici, che studia da sempre la tecnologia e l’informatica, che inizia per gioco, per sfida e può arrivare al crimine, ma adesso, ci sono varie figure che possono agire come hackers, però non lo sono, dato che i molti mezzi tecnologici sono diffusi nella popolazione, quindi non ricadrebbero nella psicologia hacker pura, ma semplicemente in un uso illecito di una tecnologia per un preciso scopo, senza poi avere una “passione” per quel genere di crimini, ma avendo solamente utilizzato un sistema ad hoc per raggiungere il loro obiettivo.

50

Esempi: Un grafico che ha bisogno di un software di fotoritocco, magari va su E-Mule a scaricare il crack e poi lo utilizza sulla copia pirata…è un hacker? Il ragazzino che scarica i film (divx) o gli mp3 è un “pirata informatico”? I clonatori di carte di credito con skimmer sono hackers? Un webmaster che entra in un’area riservata, sfruttando un baco noto di una web applications, solo al fine di scaricare un database MS Access è un hacker? In conclusione per fare un profilo potremmo pensare ad uno schema: 1) Target colpito – Scena del crimine (importanza bassa, media, alta) 2) Tipo di attacco – Modus operandi (diffusione della conoscenza bassa,media, alta) 3) Firma (rilevata, non rilevata) 4) Staging (copertura delle proprie tracce) 5) Difficoltà tecnica dell'attacco (bassa, media, alta) 6) Scopo dell'attacco - Motivazione (curiosità, gratificante, etico, fraudolento, distruttivo) 7) Effetti finali (bassi, medi, alti) 8) Tempo di ripristino (basso, medio, alto) 9) Vittimologia – (tipo di vittime coinvolte) 10) Creazione del PROFILO.

51

LA RICERCA A seconda dell’argomento sottoposto ad indagine (il “mandato” dei film), dovremo concentrare la nostra attenzione su alcuni tipi di ricerca specifica, ma se comunque non si trova ciò che stiamo cercando allora bisognerà ampliare il campo di ricerca. Nel caso di un’analisi logica possiamo subito iniziare con: 1) Una ricerca per keywords da strumenti come Autopsy o Encase 2) Una ricerca di files cancellati e orfani 3) Una ricerca per categoria con l’uso di strumenti come file (Linux/Unix), tridnet 4) Una ricerca per directory 5) Una ricerca su spazio non allocato e nello slack space 6) Una ricerca per carving (foremost, scalpel, photorec) 7) Una ricerca per immagini steganografate (stegdetect, stegbreak) 8) Una ricerca carving nei files Thumbs.db 9) Una ricerca sul registro di windows per eventuali dispositivi (usb, firewire,ecc.) che sono stati collegati alla macchina indagata. 10) Una ricerca per codici hash (http://www.nsrl.nist.gov/) dei programmi noti per capire se ci sono copie pirata 11) Una ricerca nei database hash (http://www.nsrl.nist.gov/) dei programmi noti per capire le loro reali identità 12) Una ricerca sulle navigazioni effettuate (browser cache, history, cookies), per poi eventualmente interrogare il provider 13) Una ricerca per rootkit, virus, malware in generale 14) Analisi dei software installati al fine di capire che operazioni il suspect può aver compiuto. 52

15) Carving dei file di memory swap (es. pagefile.sys, hiberfil.sys) e parsing (RegRipper) di files come ntuser.dat o SAM, esame dei file di log. 16) Parsing dei file di log (se ce ne sono) anche usando strumenti come awk e grep. 17) Verificare se ci sono macchine virtuali 18) Se ci sono CD o DVD verificare con tools per leggere le sessioni presenti ed eventualmente estrarle tutte. 19) Tecniche di cracking varie per aprire file o sistemi protetti. Nel caso le password fossero codificate con algoritmi di hash esistono le rainbow tables, dei database nei quali sono presenti le password in chiaro e la loro rispettiva codifica hash. I dictionary attacks sono deboli, perché sfruttano dei dizionari, che per quanto grandi, non potranno contenere tutte le password immaginabili (es. "fadafallummebero" ), meglio i brute force attacks, quelli che tentano tutte le combinazioni di stringhe, ma hanno tempi lunghissimi. 20) Nel caso ci fossero files o database in formati proprietari, si dovrà usare il software ad hoc per leggerli, in questi casi conviene creare una macchina virtuale (VMWare, Qemu, VirtualBox,ecc.) al fine di ricreare l’ambiente nativo e dare in pasto questi files alle loro rispettive applicazioni. Non si rischia l’irrepetibilità, poiché nella macchina virtuale non-persistent, le modifiche non vengono effettuate sui dati originali ed inoltre si cerca sempre di lavorare sulla copia della copia.

53

VALUTAZIONE Una volta trovate delle prove bisognerà valutarle e contestualizzarle, per esempio se si trovano delle immagini pedopornografiche nel pagefile.sys oppure nella cache dl browser, questo non implica che l’utente sia passibile di “detenzione e spaccio” di immagini pedopornografiche, ma che o volontariamente o involontariamente ha scaricato delle immagini in maniera automatica (caching), se invece si trovano directories piene di files cancellati o parecchie navigazioni su siti particolari o tracce di chat pedofile, si possono correlare i dati. Insomma la mole di digital evidences va valutata attentamente e correlata al caso, alla deposizione dell’indagato, al suo profilo, ma in ogni caso bisogna portarla alla luce nella relazione finale.

54

REPORTING E PRESENTAZIONE Dall’acquisizione sino alla consegna delle prove il tutto deve essere documentato con i moduli della CATENA DI CUSTODIA, in modo da avere sempre la tracciabilità della prova. Alla fine dell’analisi, bisognerà ricostruire gli eventi accaduti sul dispositivo analizzato e tutti i passi eseguiti per l’analisi, per poi spiegarli nel report finale da consegnare a chi di competenza (PM, Avvocati, P.G.,ecc.). Il report non deve essere scritto in linguaggio “stregonesco informatico”, ma deve essere il più semplice e chiaro possibile, per ovvie ragioni…. Le prove vanno registrate su supporti ottici/magnetici e codificate con hash MD5, SHA1 e poi creare un file che contiene i codici che a sua volta dovrà essere criptato al fine di non dare la possibilità di alterare le prove con rimasterizzazioni … Personalmente firmo col pennarello i supporti, ma si può anche firmare il tutto con la firma digitale a chiave pubblica. SCHEMA di massima: [Premessa (riportante i quesiti e l’incarico) – Operazioni svolte – Risposta ai quesiti – Conclusioni]

CASE HISTORY Un caso sul quale abbiamo lavorato nel lontano 2006: Fase 1 - L'acquisizione 55

Prima di acquisire dei dati da un hard disk imputato, bisogna fugare ogni dubbio, che l’investigatore abbia potuto adulterarlo, ecco che si deve bloccarlo in scrittura. Per far questo si possono usare dei meccanismi hardware, i cosiddetti "write blocker", che sono anche un tantinello costosi, oppure far partire il computer sequestrato da una distribuzione Live di Linux costruita per la Forensics and Incident Response, che "montano" gli hard disk del computer in sola lettura. Le distribuzioni più famose erano: Helix, FCCU e IrItaly Live CD. In questo caso utilizzammo Helix Ver. 1.7 (07/03/2006) Ore 10:00 Si sballa il computer sequestrato e si apre il case. Stacchiamo l’alimentazione elettrica dall’hard disk Accendiamo il computer e capiamo come si entra nel BIOS. Controlliamo com’è regolato l’orologio del BIOS e la sequenza di Boot. Impostiamo il boot da Cd-Rom. Spegniamo il computer e riavviamo, sempre l’hard disk staccato, così testiamo che il boot da cd funzioni bene. Dopo aver verificato che parte il cd, spegniamo il computer, attacchiamo l’hard disk esterno USB, che ci servirà per conservare la nostra copia dell’hard disk originale, e riavviamo (con un ditino sul tasto power...non si sa mai). Dobbiamo EVITARE assolutamente che il computer parta dall’hard disk, perchè potrebbe scrivere qualcosa (file di swap, ecc.) e cancellare/adulterare il contenuto del disco da analizzare. 56

Ore 10:30 Siamo nel sistema Helix, un ambiente grafico a finestre che ci mette a disposizione vari strumenti di acquisizione ed analisi, come il celeberrimo Autopsy, l’Adepto, il foremost e PyFlag, visualizzatori di immagini, suoni e video, un’intera suite di Open Office ecc. ecc. Subito ci segnamo il numero di serie ed il modello dell’hard disk (hdparm -I /dev/hda oppure lanciando ADEPTO e scegliere l'hd sorgente), poi, prima di iniziare le copie, montiamo in scrittura/lettura l’hard disk esterno: Lanciamo il Root Terminal e scriviamo mount -o rw /dev/sda /media/sda + Invio Adesso è il momento di iniziare l’acquisizione vera e propria...lanciamo Adepto, scriviamo il nome dell’investigatore ed il numero del caso, poi scegliamo il drive sorgente /dev/hda ed il drive destinazione, stiamo attenti a NON scegliere /dev/sda altrimenti effettueremmo una clonazione del disco, mentre noi vogliamo un file immagine, più facile da gestire. Infatti, il file immagine, image.img, può essere compresso, diviso in pezzi di varia grandezza e l'hd esterno mantiene la sua capacità, mentre in caso di clonazione, l'hd esterno sarà visto della stessa dimensione dell'hd clonato. Scegliamo il nome del file immagine (es. image.img) e poi nelle opzioni di copia scegliamo l’SDD (che è una versione più veloce del famoso DD di Linux), infine scegliamo l’hash MD5 per validare digitalmente la copia e confrontarlo con l’hash del disco originale, in modo da fugare ogni dubbio che la copia non sia uguale, bit per bit, al disco originale. Ed ora premiamo START, possiamo uscire coi nostri amici inquirenti a farci un luuuungo caffè, perchè la velocità media 57

(con USB 2) di copia è 1Gb al minuto, quindi se l’hard disk da copiare è di 80Gb ci vorranno 80 minuti. Il caffè è finito! Siamo tornati dal bar è vediamo che l’Adepto sta effettuando la verifica dell’hash, altri 80 minuti...andiamo al ristorante. Il pranzo è finito! Ore circa le 13:30 Finalmente vediamo che l’Adepto ha terminato il suo lavoro, cliccando sulla tab LOG, vediamo un file di log che dice tutto del computer inquisito (schede installate, hard disk, ecc.) ed infine le operazioni compiute e il confronto dei due codici hash, originale e copia che devono coincidere e ...per fortuna coincidono! Adesso salviamo il file di log di adepto su hd esterno e spegniamo il computer. Possiamo cominciare a compilare i documenti che sintetizzano cosa abbiamo fatto ed i documenti di "catena di custodia", chi prende la copia in consegna, chi è il testimone, a che ora viene consegnata e dove sarà ubicata (laboratorio dell’investigatore, ecc.) Poi alla riconsegna della copia scriveremo cosa ne abbiamo fatto, per esempio, masterizzata su più DVD da consegnare agli inquirenti, che devono avere la copia per uso d’ufficio e per eventualmente fornirla alla difesa. Prima di passare all’analisi proviamo ad attaccare l’hard disk esterno alla nostra forensics station, che se ha solo Windows Xp e l’hard disk esterno è stato formattato in EXT2 o EXT3 non riusciremo a leggere. E’ utile aver il software Ext2IFS che installa dei drivers in windows, che permettono di leggere gli hard disk formattati in EXT3 o EXT2 come se fossero hard disk NTFS o Fat, così da 58

poter usare tutti gli strumenti di analisi o masterizzazione, che siamo abituati ad usare sotto windows. Torniamo in laboratorio con il nostro hard disk pieno, lì dentro ci aspetta un file, image.img, di 80Gb, un mostro, che deve essere masterizzato per farne una copia di sicurezza da dare agli inquirenti. Stiamo per affrontare ancora lunghi tempi di attesa, prima di scatenarci con l’analisi, la ricerca di quello che ci hanno incaricato di trovare. Se l’hard disk esterno è stato formattato in Ext3, nonostante i driver EXT2FSD per Windows, che permettono la scrittura su HD EXT3 e EXT2 da Windows, conviene zippare da Linux col gzip, poichè ho provato che la lettura e scrittura di grosse moli di dati genera errori di lettura dopo un pò di ore...mandando all’aria tutto il resto dei files generati con WinRar o con Winzip. (In pratica la lettura da Windows di un HD EXT3 non è perfetta.) Quindi facciamo un boot da Helix e da terminal root scriviamo: gzip -N -C -9 /media/sda/image.img > /media/sda/zip/image.gz Il paramentro -N serve a mantenere il nome file ed il timestamp uguali al file origine (molto importante), mentre il -9 indica il fattore di compressione massimo, infine il > /media/sda/image.gz serve ad indirizzare l’output sul file image.gz nella directory "zip". Ore 10:00 Iniziamo a zippare Ore 14:00 Abbiamo finito di zippare....4 ore di attesa... 59

Ma dopo aver generato il file image.gz dobbiamo generare l’hash MD5 per “firmare” (creiamo un codice univoco) il file. Ore 14:01 Lanciamo l’md5sum /media/sda/zip/md5gz.txt

/media/sda/zip/image.gz

>

Ore 15:16 L’Md5 è terminato finalmente! (1 ora ed un quarto, con un Centrino 760 2Ghz) Adesso andiamo su Windows e lanciamo il Winzip e splittiamo (dividiamo) il file image.gz (includendo il file md5gz.txt) da 44Gb, scegliamo l’opzione di compressione Fast e il taglio DVD, genereremo 11 files (10 da 4.4Gb ed 1 da 1Gb) Ore 16:46 Finito abbiamo gli 11 pezzi pronti per essere masterizzati, ma non è ancora finita, dobbiamo firmare ogni singolo file. Lanciamo md5deep c:\dvd\*.* > md5split.txt Arriviamo alle 18:00 più o meno A questo punto firmo il file delle firme: md5sum md5split.txt > md5check.txt Così anche se qualcuno dovesse manomettere tutto e ricreare un md5split.txt, la nuova firma del md5split.txt non coinciderebbe mai con quella presa dall’md5check.txt (paranoia??? Ma sì....) Ed ora la parte peggiore, masterizziamo ogni singolo file (aggiungendo sempre i due files md5split.txt e md5check.txt) su DVD velocità 8x, ci vogliono 15 minuti per scrivere il DVD e 15 minuti per la verifica di scrittura (che in questo caso è

60

consigliabile), poi nella immensa paranoia che ci prende, firmo ogni singolo DVD con pennarello indelebile. A 30 minuti a DVD per 11 pezzi ecco che perdiamo altre 5 ore e mezzo e arriviamo alle 23:30 ed abbiamo FINITO! Adesso passiamo all’analisi!! Prima di tutto cerchiamo di focalizzare l’obbiettivo che ci hanno commissionato, ad esempio, cercare un carteggio e-mail, oppure cercare delle JPG, oppure una ben determinata informazione, così da non perdere tempo in ricerche spasmodiche su cose inutili e fuori mandato. Se cerchiamo tutto quello che riguarda i rapporti del sospettato con la Ciccio Ltd, dobbiamo cercare: e-mail, documenti e navigazioni sul sito della Ciccio Ltd. Chiaramente in casi estremi, si potrebbe parlare di steganografia, ossia messaggi nascosti nelle immagini, oppure, informazioni criptate, ma dipende dall’importanza dell’indagine e da cosa si cerca e quali sono i sospetti. In ogni caso tutto si può fare...ad esempio lanciamo Autopsy e cerchiamo le keywords che possono ricondurre a files o spezzoni di files, che contengono qualcosa di pertinente al caso: Ciccio, indirizzo IP della Ciccio Ltd, sito internet, e-mail di Ciccio Ltd, money, bank, ecc. ecc. Le keywords le cerchiamo sia in formato Ascii sia in formato Unicode e magari anche nello spazio non allocato. Dai riferimenti uscenti da Autopsy possiamo salvare i contenuti dei files in rapporti testuali (magari da allegare) e poi montare l’immagine magari con un software come Mount Image Pro e poi andare a copiare i files da esaminare con software più GUI, ad esempio se becchiamo Posta Inviata.dbx lo possiamo dare in 61

pasto a software come "Attachment Extractor for OE", che permette di visualizzare tutta la corrispondenza e gli allegati. In ogni caso possiamo aprire i files dbx con un editor testuale e fare l’analisi delle intestazioni delle e-mail per capire chi ha inviato effettivamente l’email ecc. Gli allegati li visualizzeremo con l’UUDecode che trasformerà i caratteri Ascii componenti l’allegato in formato binario. Senza andare in fondo alle varie ricerche possibili, alla fine dovremo: 1) Consegnare i DVD con un foglio firmato riportante tutti gli MD5 ricavati 2) Consegnare tutte le prove trovate (masterizzate) e firmate con MD5 o SHA1 3) Stilare un rapporto tecnico ed uno discorsivo (per il magistrato) sulle azioni compiute ed aggiornare i documenti di catena di custodia. L'indagine è conclusa e le prove...parleranno.

62

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). 63

3) Domandare: 3.1) Ci sono altri dati su altri supporti oltre i PC (es. cdrom, 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) Etchettare ed imballare tutto e portare via. 7) Fissare una data per l'acquisizione (duplicazione) dei supporti.

64

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…

65

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…

66

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 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 procedo 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: 67

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 disck 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.

68

Questa storia è stata abbastanza “classica” e “semplice”, ma può sempre capitare di tutto, come ad esempio acquisire dei dischi, che vi dicono NON criptati e poi lo sono, allora conviene sempre provare in loco a montare in READ ONLY le immagini dei dischi appena fatte, al fine di verificare la criptazione. 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 69

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.

SELECTIVE FILE DUMPER 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. 70

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

71

ALTRI CASI REALI In un caso reale dovremmo utilizzare una workstation con un HD abbastanza capiente ed un bay (cassettino per hard disk), nel quale inserire l’hard disk da acquisire. La workstation potrebbe anche avviarsi dal cd di Helix oppure da un altro hard disk interno sul quale abbiamo installato una distro come, ad esempio, UBUNTU, nella quale abbiamo imposto di montare tutti i dispositivi solo in lettura. Quando avremo finito, potremo backuppare l’immagine dell’hard disk suspect, su altri dispositivi, poi alla fine dell’indagine consegnare l’hard disk agli inquirenti con su anche le evidences ritrovate (ma quelle le potremmo anche masterizzare su DVD-ROM), oppure masterizzare centinaia di DVD (come nell’esempio precedente). Per quanto riguarda la ricerca delle prove, in certi casi, bisogna affidarsi all’intuito, all’esperienza (quindi aver visto più cose possibili, saper riconsoscere dei files dal loro contenuto esadecimale e/o Ascii) e al caso. In un esercizio di computer forensics è capitato di ritrovare l’evidenza in un file ascii senza estensione e solamente guardando il suo contenuto ho visto il suo header che, cercando su Google, ho scoperto essere una codifica base64 di un’immagine presa da un file PDF ed allegata ad un’email, qualcun altro avrebbe riconosciuto il tipo di file dal footer che terminava col carattere “=”, quindi tutto dipende da quei fattori su citati. In altri casi si deve lavorare in fretta e non si possono passare mesi a craccare passwords, quindi usare l’astuzia per capire dove può essere una password: in un’immagine tra i layers, caso d’immagini vettoriali (es. png)? In un’immagine scritta con lo stesso colore dello sfondo? 72

In un file con un testo enigmatico? In un file di testo coperta da un carattere non presente sul vostro sistema? In qualcosa di molto piccolo, che necessita un ingrandimento? In qualche chat/carteggio dell’utente? Insomma bisogna usare molto la fantasia e seguire ogni pista….ma questo è il lato divertente delle indagini.

73

PROBLEMI INSOLUTI L'unico mezzo per investigare sui nuovi mezzi digitali come: computers, flash memories, palmari, cellulari, ecc. è la digital forensics, ossia quella disciplina che comprende una serie di protocolli di preservazione,acquisizione e ricerca della prova elettronica (digital evidence). Per raggiungere tal fine si usano molte tecniche e molti strumenti software ed hardware, perchè la prova digitale deve essere considerata e trattata allo stesso modo di una prova tradizionale, quindi non deve essere “adulterata” dagli investigatori, per questo, nella fase di acquisizione si deve effettuare una copia bit a bit su di un altro supporto, per poi ricercare le tracce di ciò che si sta cercando. Dopo la fase d’acquisizione, gli investigatori possono usare dei software open source o closed source (quest'ultimi certificati dalle maggiori agenzie investigative), per analizzare il contenuto della memoria acquisita. Grazie a questi mezzi sembra che nulla possa sfuggire all'occhio ed al tool di ricerca, quindi tutti i files (anche quelli cancellati) possono essere recuperati, i files criptati riescono ad essere individuati e poi, con molto sforzo, essere decifrati. Però ho provato a lanciare una sfida su alcuni forum e blog italiani su una potenziale tecnica di information hiding per capire se ci fosse un sistema per recuperare un file nascosto e criptato con semplici tecniche da power user e non da genio dell'informatica, ma prima di continuare devo ringraziare Maurizio Anconelli e Mario Pascucci per le idee e le risposte sui forum....ecco la mia sfida. : 74

Figura 1: Sito di AxCrypt

Scrivo un file di testo con all’interno un piano terroristico “hello world„, quindi lo zippo in un file che ha chiamato kmxer22.zip e poi magari lo rinomino kmxer22.dll, poi lo cripto con AXCrypt e lo faccio diventare kmxer22.axx, lo rinomino di nuovo in kmxer22.dat ed infine lo piazzo in mezzo ad una cartella di un programma zeppo di files dll, dat, ecc. ecc. Ora, le domande sono: 1. Se un ricercatore acquisisce l'intero disco rigido e in che modo troverà il contenuto di quel file? Poiché quel file si è trasformato in un file binario in modo da vanificare una ricerca per keywords testuali ed inoltre è mimetizzato in mezzo a migliaia di files. 2. Se un ricercatore trovasse questo file sospetto, in che modo potrebbe risconoscerne il fomato? Ed anche se lo riconoscesse come farebbe a decriptarlo senza password?

L'algoritmo AES a 128 bit è molto forte, ma questo è un problema secondario, perché la questione principale è trovarlo! 75

Ho ricevuto alcune risposte ed ho pensato di classificarle, forse in modo improbo ma utile per semplificare, due approcci alla risoluzione del problema. L'APPROCCIO STRUMENTALE, che prevede il mero uso dei software tools senza altre considerazioni, spesso utilizzato da chi sa usare solo i programmi d’investigazione e non ci mette la logica o la ricerca frutto d'esperienza.

L'APPROCCIO METODICO, che è un insieme più grande delle procedure e che include inoltre l'uso di molti tools (approccio strumentale), oltre che la logica, l'esperienza e la fantasia dell'investigatore. Questa classificazione è stata fatta per capire meglio che una buona ricerca non è un semplice click e l'uso di vari programmi, ma si ha bisogno del metodo, della fantasia, dell'esperienza e di una quantità grande di fortuna. L'APPROCCIO STRUMENTALE: Al fine di risolvere il problema sollevato dalla sfida, potremmo utilizzare dei tools che ricercano i file per headers (intestazioni dei files) conosciuti (per esempio TRID, WinHex, Foremost, ecc.) in modo da poter riconoscere un file AXX (estensione di AxCrypt) nell'immagine del disco rigido acquisito Hex: C0 B9 07 2E 4F 93 F1 46 A0 15 79 2C A1 D9 E8 21 15 00 00 00 02 a questo punto potremmo provare un dictionary attack o un attacco di forza bruta per decriptare il file oppure potremmo 76

intervistare il proprietario dell'hard disk per ottenere la password (ammesso che il proprietario sia ancora vivo o nelle nostre mani), usando tutte le nostre abilità di ingegneria sociale. Dobbiamo ricordarci sempre che l'anello più debole della catena è l'uomo! Le limitazioni di questo metodo sono rappresentate dall'aggiornamento dei softwares, dei tools d'esplorazione delle intestazioni e dai softwares di crypting conosciuti, perché se sviluppo un software di criptaggio, che utilizza AES 128 (l'ho fatto), il file risulatante sarà senza un'intestazione conosciuta.

Figura 2: Forum della sfida http://www.nannibassetti.com/cf

77

L'APPROCCIO METODICO: Questo approccio inizia col classificare i files presenti sull'hard disk. Si comincia con l'escludere tutti i file noti per lavorare sul sottinsieme dei rimanenti, eventualmente si può anche verificare il codice hash per controllare la loro integrità, quindi possiamo esaminare questo sottoinsieme usando un editor esadecimale in modo da ridurre il sottoinsieme a tutti i files non identificati (anche se il sospettato potrebbe cambiare header signature di un certo file per mezzo dello stesso editor). Ora possiamo cercare sul disco rigido alcune tracce delle installazioni del software “genitore„ che ha creato/installato dei files sospetti, ma se il file sospetto fosse stato generato su di un altro computer o tutte le orme sono state cancellate (per mezzo di tools come il wipe, cancellando manualmente le chiavi di registrazione o creato su una flash memory, ecc.), questa ricerca sarebbe vana. A questo punto possiamo ipotizzare che su di un disco rigido il numero medio di files presenti sarà più o meno di 200.000, allora dopo il primo step (ossia scoprire i file ben noti, sperando che non siano stati modificati e camuffati con un renaming ed un padding o compressi da un software come UPX ed editati da un editor esadecimale per cancellarne l'header originale), ci rimarrà un sottoinsieme di più o meno lo 0,1% dei files conosciuti, in una visione ottimista, il subset di ricerca potrebbe essersi ridotto a 200 files. A questo punto, effettuando un'analisi con un editor esadecimale, potremmo ottenere 80 “file conosciuti”. Infine potremmo dare in pasto, questi files rimasti, a vari tool di cifratura (AxCrypt, gnuPGP, PGP, ecc.), ma per fare questo 78

dovremo effettuare molte prove, per esempio, se provassimo con soltanto 4 programmi dovremmo fare 4 x 80 = 320 prove, con un consumo di tempo eccezionale! Ipotizziamo di essere fortunati e di riuscire a trovare con che programma il file è stato criptato, il nostro lavoro non è concluso, perché lo dobbiamo decriptare! Per decriptare un file cifrato con AES 128, le tecniche più usuali sono il dictionary attack (attacco da dizionario) ed il brute force attack (attacco di forza bruta) , con un inevitabile ulteriore spreco di tempo uomo e tempo macchina, che comincerebbe a rendere la nostra ricerca troppo onerosa, considerando che si sta cercando un semplice file di testo. Tutto questo lavoro sarebbe inutile se il file fosse stato criptato da un programma sconosciuto, dovremmo analizzare tutti i files e, anche se, trovassimo il file sospetto, non capiremmo che genere di procedura e/o di programma è stato usato per cifrarlo. CONCLUSIONE Il limite della computer forensics si raggiunge in questo modo, perché se provassimo a scoprire il file criptato usando la header signature potremmo incorrere in questi problemi: 1. I tools di analisi e ricerca delle intestazioni dei files non sono aggiornati 2. L'intestazione del file è stata modificata, quindi non sarà riconosciuta dai tools di analisi 3. Il programma di cifratura è un software creato dall'indagato o è un prodotto sconosciuto Possiamo terminare che, senza molta destrezza informatica, un qualunque terrorista può scaricare un programmino open 79

source come AxCrypt, criptare un file di testo, cambiare l'intestazione usando un semplice hex editor come XVI32, rinominare il file ed il gioco è fatto! La cosa stupefacente è la semplicità delle operazioni, chiunque non ha bisogno di essere un super esperto di crittologia o un programmatore eccellente, ma bastano pochi clicks e l'uso di semplici programmi. Se il terrorista fosse un programmatore (nemmeno troppo bravo) potrebbe sviluppare un facile software usando la libreria CAPICOM di MS WINDOWS e potrebbe criptare il file usando molti algoritmi (3DES, RSA RC4, AES), con il massimo della lunghezza della chiave di cifratura. Ho provato a criptare, con un mio programma che utilizza AES 128 bit, un semplice file di testo “hello.txt”: HELLO WORLD e questo è l'output, dopo la cifratura: MHIGCSsGAQQBgjdYA6BlMGMGCisGAQQBgjdYAwG gVTBTAgMCAAECAmYOAgIAgAQQAAAAAAAAAAA AAAAAAAAAAAQQaMsrdSNQ1GHDjOsX6dt1UgQgYgi MWp3LSBUtj2rbpGsBZtovrhLCEqXScMnYclW9u1Y= Ora potrei rinominare il file, lo potrei nascondere in mezzo a migliaia di files e, se anche, un investigatore lo trovasse, non so proprio come potrebbe: 1. Capire che tipo di file è. 2. Capire con che algortimo è stato criptato. 3. Capire come leggerne il contenuto.

80

Questo è il limite della digital forensics, pochi tools, poca competenza informatica serve a mettere in crisi gli investigatori! Come diceva qualcuno in TV anni fa....meditate gente meditate....

Anti-Forensics alcune tecniche di base Riassumiamo alcune tecniche di base dell'anti-forensics, niente di nuovo, ma serve 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 http://www.ismprofessional.net/pascucci/index.php/2008/06/co nvegno-cfitaly-giugno-2008-il-giorno-dopo/ potete trovare una 81

trattazione di Mario Pascucci in merito ad alcune tecniche, ma esaminiamo quelle più comuni e conosciute: Encryption Criptare interi volumi (http://www.truecrypt.org/) o solo dei file (http://www.axantum.com/AxCrypt/) , 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 (http://www.nannibassetti.com/dblog/articolo.asp?articolo=52) o una più complessa con NBSTEGO 82

(http://www.nannibassetti.com/dblog/articolo.asp?articolo=60) Ci sono tanti strumenti per la steganografia come: JHide, Digital Invisible Ink (http://diit.sourceforge.net/index.htm) e tanti altri che potete leggere qui http://en.wikipedia.org/wiki/Steganography . 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 http://sfdumper.sf.net ), 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 83

(http://www.metasploit.com/research/projects/antiforensics/) 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 (http://www.nannibassetti.com/secur/ads.pdf ). 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

84

quest'ultimi tool, quindi va fatta un'ispezione accurata e manuale!

85

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"

Altri sistemi anti forensics possono essere: 1) Navigazioni e/o operazioni da Live Distro o da macchine virtuali non pesistent

86

2) ADS (Alternate Data Streams) ossia nascondere dei files dentro gli streams di files innocui. (type pedo.jpg > notepad.exe:pedo.jpg). 3) Wiping – cancellazione reale di un file scrivendo, con più cicli, degli zeri o dei caratteri casuali. 4) Criptaggio 5) Sfruttare i bugs dei tools forensi 6) Pulire tracce lasciate in memoria 7) Steganografia ossia inserire dei files dentro files binari, con una password d’accesso per poterli estrarre. Si consideri che con strumenti come stegbreak, che sferra dei dictionary attacks, non sempre si riesce a scoprire la password, a causa della limitazione del dizionario. 8) Data Hiding nelle strutture del File System • Slacker — Nasconde dati nello slack space • FragFS — Nasconde dati nella NTFS Master File Table • RuneFS — Inserisce dati nei “bad blocks” • KY FS — Inserisci dati nelle directories • Data Mule FS — inserisce negli inode reserved space • Host Protected Areas & Device Configuration Overlay

The SleuthKit mini guida operativa Spesso accade di dimenticare tutte le potenzialità ed i tools di Sleuthkit (http://www.sleuthkit.org), quindi ho deciso di scrivere una piccola guida veloce per illustrare gli usi più prêtà-porter di questa utilissima suite di strumenti per la computer forensics, sviluppata da Brian Carrier. 87

Iniziamo dal disco/immagine mmls /dev/sdaX o mmls disk.dd serve a visualizzare le partizioni di un device o di un file immagine, fornendoci in output lo starting sector, molto utile per determinare l'offset di inizio partizione. 'Mmls' è simile a' fdisk-lu 'in Linux con alcune differenze. Vale a dire, che mostra i settori che non sono stati utilizzati in modo tale che questi possono essere usati per cercare dei dati nascosti. Inoltre, fornisce anche il valore della lunghezza delle partizioni in modo che possa essere usato con 'dd' più facilmente per estrarle. fsstat -f file_system -o offset disk.dd serve a fornire dati importanti sul file system presente sul dispositivo o file immagine del dispositivo in analisi, compreso un dato particolarmente interessante, ossia il block/cluster size. ifind -f file_system -o offset -d numero_del_cluster disk.dd serve a fornire l'i-node appartenente a quel determinato cluster. Il numero del cluster si ricava dall'offset decimale in bytes, che stiamo osservando, diviso la dimensione del cluster/blocco determinata da fsstat. Se troviamo, per esempio, una stringa che inizia all'offset decimale 101345 in un file immagine DD, per ricavare l'i-node effettueremo 101345/dim_cluster. ffind -f file_system -o offset disk.dd i-node

88

serve a fornire il nome del file corrispondente all'i-node. istat -f file system -o offset disk.dd i-node serve a fornire i metadati relativi al file corrsipondente a quell'i-node. fls -d -r -p -f file_system -o offset disk.dd serve a visualizzare i file cancellati, ricorsivamente in tutte le sottocartelle e col percorso completo (-p). fls -a -l -p -r -f file_system -o offset disk.dd lista tutti i files non cancellati. icat -f file_system -o offset -r disk.dd i-node > nomefile.ext Serve ad esportare il contenuto del file relativo all'i-node su file (nomefile.ext). sigfind -t file_system disk.dd Serve a cercare le "firme" che identificano i vari file system, -t list per visualizzare i vari file system supportati. Altre informazioni preziose sono: http://wiki.sleuthkit.org/index.php?title=FS_Analysis The SleuthKit Manual: http://wiki.sleuthkit.org/index.php?title=TSK_Tool_Overview Esempio di come estrarre una stringa da uno spazio non 89

allocato Normalmente per cercare le stringhe utlizziamo la pipe di comandi: strings -t d disk.dd | grep -i "abcd" ("-t d" genera l'offset in decimale) che risulta essere più veloce del comando: grep -iaob "abcd" disk.dd -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; $ mmls disk.dd DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot 00: Meta 01: ----02: 00:00

Start End Length Description 0000000000 0000000000 0000000001 Primary Tabl 0000000000 0000000062 0000000063 Unallocated 0000000063 0174000014 0173999952 NTFS (0x07)

Se vogliamo cercare le stringhe nello spazio non allocato di disk.dd e considerando che lo starting sector della partizione sia 63 e che il file system sia NTFS, allora: 1) Estraiamo lo spazio non allocato dal disco 90

blkls -f ntfs -o 63 disk.dd > disk.blkls 2) Estraiamo le stringhe e prendiamo solo quelle che contengono "abcdefg", dal solo spazio non allocato estratto da blkls (disk.blkls) strings -t d disk.blkls | grep -i "abcdefg" per esempio un risultato potrebbe essere: 10389739: abcdefg dove 10389739 è l'offset in bytes 3) Troviamo la dimensione del cluster impostata nel file system: fsstat -f ntfs -o 63 disk.dd

CONTENT INFORMATION ---------------------------------Sector Size: 512 Cluster Size: 1024 Total Cluster Range: 0 - 21749992 Total Sector Range: 0 - 173999950

4) Dividiamo 10389739 per 1024 ed otteniamo il numero 10146 che è il cluster che contiene la stringa "abcdefg", però nel file disk.blkls e non nel file immagine, quindi dobbiamo convertire l'indirizzo del cluster del file immagine disk.blkls in un indirizzo reale del file immagine originale, cioè disk.dd 5) blkcalc -f ntfs -o 63 -u 10146 disk.dd otteniamo 59382 che è l'indirizzo reale del cluster che contiene la stringa cercata. 6) Possiamo visualizzare il cluster usando il comando: blkcat -f ntfs -o 63 disk.dd 59382 | less

91

7) Adesso cerchiamo l'i-node che ha un pointer al cluster 59382 ifind -f ntfs -o 63 -a -d 59382 disk.dd che ci ritorna il numero 493-128-1 come risultato. 8) Reperiamo informazioni sui metadati che si riferiscono all'inode 493: istat -f ntfs -o 63 disk.dd 493

$FILE_NAME Attribute Values: Flags: Archive Name: pippo.jpg Parent MFT Entry: 458 Sequence: 122 Allocated Size: 0 Actual Size: 0 Created: Tue Mar 18 15:05:19 2008 File Modified: Tue Mar 18 15:05:19 2008 MFT Modified: Tue Mar 18 15:05:19 2008 Accessed: Tue Mar 18 15:05:19 2008

9) Vediamo se c'è ancora un file associato all'i-node: ffind -f ntfs -o 63 -a disk.dd 493 /Document and Settings/spectra/Documenti/pippo.jpg abbiamo trovato un file che si chiama pippo.jpg. 10) Recuperiamo il file pippo.jpg icat -f ntfs -o 63 -r disk.dd 493 > pippo.jpg Consideriamo che lo starting sector della partizione sia 63, che disk.dd sia NTFS, tramite il comando icat esportiamo il contenuto del file basandoci sul suo numero di i-node. Spero che questo piccolo manualetto pratico sia utile a tutti

92

quelli, che come me, cominciano ad avere l'had disk biologico sempre più full

Raw2Fs e Scripts4CF scripts and tools... Raw2FS, acronimo che serve ad indicare lo scopo di questo mio nuovo bash script per Linux, ossia ricondurre i nomi dei file estratti con tool come Foremost, al nome presente nel file system, con tutto il suo percorso. Sappiamo che Foremost, come altri carver, salvano i file nominandoli col numero di settore (da 512 bytes), di partenza, in cui questi si trovano, quindi mi serviva uno strumento per risalire all'eventuale nome presente nel file system. Se il file "carvato" non ha corrispondenza con un i-node allora il tool salva l'output hex/ascii di un settore/cluster/block in un file di testo. Tutto è riassunto in un report in HTML. Ma visto che ero in argomento, perchè non implementare anche una ricerca per stringhe? Raw2Fs permette di cercare più keywords oppure di caricare un file di testo, generato dal "grepping" e riportare tutti i file nel file system che contengono quelle keywords, se invece la keyword è contenuta nello slack space, allora viene salvato l'output hex/ascii di un settore/cluster/block. Il motore di tutto è questo: se ho un file nominato 00001234.doc (carving), quel numero "1234" rappresenta il settore in cui il file è stato trovato dal carver, quindi lo si moltiplica per 512 (dimensione minima del settore) e si ottiene l'offset in byes del file, che chiamremo $offcarv. 93

Poi il tool cerca a quale partizione appartiene il file, trova l'inizio della partizione/spazio non allocato e moltiplica lo starting sector per la dimensione del settore/cluster/blocco (es. 1024), che chiameremo $ss, per ottenere l'offset in bytes della partizione, che chiameremo $offbytepart. (ricordiamo che per fat -> settore, ntfs -> cluster, ext2/3 -> blocco). Ed ecco la formuletta: ($offcarv - $offbytepart) / $ss Quindi se la partizione inizia al settore 63, il file ha come nome 34091122.jpg e l’fsstat del disco ci dice che il cluster è di 1024: $offcarv = 34091122 * 512 = 17454654464 $offbytepart = 63 * 512 = 32256 $ss = 1024 La data unit in bytes dove si trova il file è: (17454654464 – 32256)/1024 = 17045529,5 (prendiamo solo la parte intera chiaramente) = 17045529 Ossia l'offset del file carvato - l'offset di inizio partizione diviso la grandezza del settore/cluster/blocco usato in quella partizione da quel file system. Poi tramite i tools dello Sleuthkit, Raw2Fs fa tutto il resto.... :) Per le keywords stesso discorso, solo che nel file derivante dalla ricerca con strings e grep, si trovano già gli offset in bytes delle stringhe, quindi non c'è bisogno di moltiplicare per 512. Dopo quest'ennesima "fatica", ho pensato di lanciare il sito: http://scripts4cf.sf.net

94

contenente alcuni scripts utili, ad oggi realizzati da me e da altri, ma aperto ad ospitare anche scripts fatti da altri, insomma una vera e propria piccola biblioteca di tools costruiti dagli "investigatori digitali", man mano che si trovano a dover affrontare e risolvere i problemi che incontrano durante le loro indagini e/o esercizi. Spero di aver fatto cosa utile... ;)

95

XMount finalmente liberi di virtualizzare! Cosa succede dopo che abbiamo acquisito un disco in bitstream su file immagine? In genere si comincia l'analisi del disco montando il file dd (raw), ewf o aff, ma ad un certo punto può esser utile virtualizzare l'immagine per tante ragioni, come per esempio lanciare i vari tools della Nirsoft, Sysinternals, lavorare con programmi proprietari istallati sulla macchina acquisita, guardare i processi attivi, ecc. ecc. Fino a poco tempo fa, i sistemi per virtualizzare un file immagine erano quelli di: 1) Convertire il file in formato VDI o VMDK (VirtualBox o VMWare tanto per citare i due virtualizzatori più diffusi), occupando così altro spazio su hard disk e tanto tempo macchina. 2) Usare l'utilissimo LiveView, che evita la conversione e permette la virtualizzazione partendo direttamente dal file immagine in formato raw (dd). LiveView però ha delle forti limitazioni: 1) Gira solo sotto Windows. 2) Usa VMWare e l'unica versione gratuita di VMWare server, accettata da LiveView, è rimasta la 1.0.qualcosa....ormai abbastanza vetusta. Parlai in chat con John Lehr, che mi disse che dovevo scaricare xmount direttamente dal sito dei produttori, dato che quello preso dai repository Canonical (Ubuntu) era buggato. 96

Quindi ho proceduto in questo modo: https://www.pinguin.lu/index.php (download del pacchetto DEB) Controlliamo di avere i requisiti necessari: Per chi usa Linux - Kernel 2.6.x - FUSE library Per chi usa Mac OSX - OSX 10.5 or above - MacFUSE • Verificare che il proprio utente (quello che useremo per lanciare la Virtual Machine) sia nel gruppo "fuse" (il root c'è di sicuro).In ogni caso si fa così: sudo usermod -a -G fuse username (dove username è il vostro utente linux) e poi editate il file “/ etc/fuse.conf” e scommentate (togliere il #) la riga user_allow_other. A questo punto basta creare una directory: es. sudo mkdir /media/lab poi lanciare il comando: sudo xmount --in dd --out vdi --cache cache.dat disk.dd /media/lab per creare il file disk.vdi nella cartella /media/lab ed inoltre le modifiche durante la virtualizzazione sono riderezionate sul file di cache, così da non alterare il file sorgente originale. Infine lanciamo VirtualBox e creiamo una nuova macchina virtuale, usando come disco il disk.vdi e tutto funziona! La forza di questo sistema è che il file disk.vdi è solo "simbolico", perchè in realtà non occupa lo spazio che dice di 97

occupare, personalmente ho virtualizzato un file di 200Gb su un disco che ne aveva solo 180Gb liberi. Chiaramente nell'esempio riportato ho utilizzato un input raw ed un output su VirtualBox, ma potrei anche usare il formato ewf in input ed il formato VMWare in output e/o tutte le altre combinazioni tra VMWare/VirtualBox e i formati dd/ewf/aff. Pensavo di creare un'interfaccia grafica per XMount, ma John mi ha preceduto, lavorando mentre io dormivo (bella forza per lui era mattina!) e, scherzi a parte, ha realizzato una GUI con YAD, un'evoluzione di Zenity...la potete trovare qui, completa di file deb di xmount 0.4.4 e YAD 0.5.2-1 : http://scripts4cf.sf.net

Il settore danneggiato e l'acquisizione forense Se si deve acquisire un hard disk in maniera forense, ossia con tutti i crismi necessari al fine di garantire che la copia sia identica all'originale, a tutti quelli che operano nel settore viene subito in mente l'uso di DD, DCFLDD o DC3DD (nel mondo Open Source GNU/Linux), con le classice opzioni e parametri. Gli approcci sono due: 1) Ottimistico (consideriamo il disco sano e tutti i settori sani) 2) Pessimistico (consideriamo che il disco abbia qualche settore danneggiato) Nel caso in cui l'approccio ottimistico sia sconfessato, perchè durante l'acquisizione ci si ritrova con degli errori di lettura, allora si tenderà a porsi nell'ottica pessimistica, a volte anche ricominciando tutto d'accapo. 98

Esaminiamo gli scenari: dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32K Il suscritto comando leggerà blocchi da 32Kb dal disco /dev/sdb e scriverà sul disco destinazione /media/sdc1 (montato in scrittura) il file disco.dd, l'opzione conv=noerror,sync serve a due cose: 1) Noerror - indica a dd di non fermarsi di fronte ad eventuali errori di lettura, ignorando i blocchi illeggibili, ma questo, senza il sync, cambierebbe l'indirizzamento del disco, poichè l'immagine (disco.dd) del disco avrebbe una dimensione finale errata, inferiore a quella del disco originale. 2) Sync - Il flag sync forza dd a scrivere i blocchi della dimensione prescelta (es. BS=32K) e se non ci sono abbastanza dati per riempire il blocco, quest'ultimo sarà riempito di zeri (0s padding). Questo crea un problema, il file immagine di destinazione avrà una dimensione multipla del BS prescelto. Es. se il disco origine è di 6Kb ed il BS=4K, il file immagine avrà come dimensione 8Kb. Inoltre, con un BS=32K e conv=noerror,sync, se dovessimo incontrare dei settori danneggiati, che però appartengono al buffer di lettura di 32Kb, il dd così configurato andrebbe a riempire ben 32Kb di zeri, sacrificando anche i settori sani che potrebbero esserci in quei 32Kb. Se ci sono solo due di settori danneggiati 512 bytes * 2 =1024 bytes = 1Kb, significa che i rimanenti 31Kb saranno azzerati, perchè dd ha letto un blocco da 32Kb ha incontrato degli errori ed ha fatto il riempimento di zeri su tutto il blocco letto. Quindi la soluzione sarebbe quella di impostare dd con un BS=512, che è la misura minima di un settore, così da leggere il disco, settore per settore e nel caso uno di essi fosse illeggibile, sarebbe riempito di zeri (sync), mentre il settore 99

successivo (leggibile) sarebbe letto correttamente, preservandone il suo contenuto. dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=512 Il problema di questa configurazione è che stressa di più gli hard disk, costringendoli a moltissime letture (sector by sector) e rende l'operazione più lenta. Come risolvere? Ci sono dei tools alternativi come ddrescue o dc3dd, che permettono di leggere blocchi di dimensioni maggiori di 512 bytes, ma nel momento in cui si trovano di fronte ad un errore, questi useranno il block size di dimensione minima, 512 bytes appunto e lo riempiranno di zeri. DC3DD ha il default blocksize di 32768 bytes (32Kb), al fine di aumentarne la performance. Il file immagine finale è calibrato sulla dimensione del disco sorgente indipendentemente dalla dimensione del blocco, così la dimensione del file immagine è esattamente la stessa, come se avessimo usato un BS=512. Sector Error Recovery Quando si incontra un errore ed il block size è più grande del settore del device sorgente, e il parametro conv=sync,noerror è impostato, dc3dd cerca dalla fine all'inizio del blocco e prova a leggere ciascun settore indvidualmente, così i settori buoni saranno acquisiti e quelli cattivi saranno rimpiazzati dagli zero. Questa caratteristica permette di acquisire le aree non danneggiate del disco a velocità maggiori, (dato che il BS=32K), senza perdere i blocchi di dati che circondano un bad sector Per attivare questa modalità è richiesto il direct I/O mode abilitato (iflag=direct su Linux, /dev/rdisk* su Mac OS X). 100

dc3dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32k iflag=direct oppure con ddrescue ddrescue -d -r3 /dev/sdb /media/sdc1/disco.dd log.txt In sostanza il parametro iflag=direct o -d per ddrescue, serve a bypassare la Kernel Cache (pagecache)* e accedere direttamente al disco (direct I/O), considerando così la dimensione minima del settore. Chi volesse usare DCFLDD con direct access non può utilizzare il parametro iflag=direct, dato che dcfldd è un fork di dd, quindi non segue lo stesso sviluppo di quest'ultimo, ma può accedere al device sorgente in direct I/O tramite il /dev/raw (per questo documentarsi sul device raw in Gnu/Linux). E' chiaro che per uso forense si tende ad usare di più uno strumento come DC3DD dato che ha anche caratteristiche di multiple hashing automatico, verifica, ecc. Es.: dc3dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32k iflag=direct progress=on hash=md5,sha1 log=log.txt vf=/dev/sdb verifylog=log_verifica.txt *La page cache è il luogo in cui il kernel mantiene in RAM una copia dei dati, per migliorare le prestazioni evitando l'I/O del disco, quando i dati che devono essere letti sono già in RAM. DC3DD è basato su DD, quindi iflag=direct funziona anche con DD.

101

Il mistero di $LogFile nell'MFT PREMESSA: questo articolo è basato su un test da me condotto e mi piacerebbe avere verifica dai lettori di questo blog. Tempo fa ho notato una stranezza, non avendo cavato ancora una soluzione, ho pensato di sottoporla al pubblico del mio blog, sottolineo che è basato su una sola prova, sulla quale non ho ancora una spiegazione, che potrei non avere per mia "ignoranza", quindi vorrei altre opinioni e/o sperimentazioni. Detto questo passo a descrivere l'esperimento: da Linux (senza montare nè in lettura nè in scrittura) 1) attacco una pendrive da 128Mb formattata in NTFS 2) Faccio l'immagine dd e la chiamo pen1.dd 3) faccio l'md5sum da Windows XP: 4) attacco il pendrive da 128Mb 5) la stacco con RIMOZIONE SICURA da Linux 6) faccio immagine dd e la chiamo pen2.dd 7) faccio md5sum 8) confronto i due md5 e noto che SONO DIVERSI. La pendrive è vuota, la pendrive NON è stata sfogliata, la pendrive è stata solo attaccata a Windows e staccata con rimozione sicura. A questo punto prendo le due immagini e le confronto con un programma (per windows) che si chiama HexCMP2 Cerco le differenze e tutte cadono nel cluster del file $LogFile, che è il journal di NTFS. 102

Per esempio l'ultima differenza è nell'offset in decimale: 40203262 9) faccio mmls pen1.dd ricavo l'offset di partenza della partizione che è 32 10) fsstat -f ntfs -o 32 pen1.dd e ricavo la dimensione del cluster che è 512 11) divido 40203262 per 512=78521 che è l'offset in settori 12) ifind -f ntfs -o 32 -d 78521 pen2.dd mi tira fuori: 2-128-1 ffind -f ntfs -o 32 pen2.dd 2-128-1 mi tira fuori //$LogFile 13) istat -f ntfs -o 32 pen1.dd 2-128-1 | less istat -f ntfs -o 32 pen2.dd 2-128-1 | less e noto che la data e l'ora sono identici, quindi il file $Logfile viene modificato, ma i suoi metadati no! Why? 103

RIFACCIO il procedimento SENZA la RIMOZIONE SICURA, ma staccando brutalmente la chiavetta ed ottengo gli stessi risultati, solo che l'ultima modifica è all'offset decimale: 40174590 diviso 512 =78465 Quindi meno modifiche con la rimozione bruta. Per concludere ho notato che quando si fa la RIMOZIONE SICURA, sul display del pendrive, appare la scritta WRITE (è un pendrive con display, lettore MP3), quindi quella procedura scrive qualcosa... PROBLEMA: Se un CTU maldestro, attacca un disco NTFS ad una stazione Windows, senza il Write Blocker, altera il disco originale, però non v'è traccia di questa alterazione, in termini di timeline....l'hash code che calcolerà sarà quello che verrà generato dall'hard disk già alterato, quindi copia ed originale avranno lo stesso hash code. In un secondo tempo, un CTP riprende il disco originale, lo attacca con Write Blocker, fa l'immagine e l'hash coinciderà con quello del CTU, dato che il CTP non ha alterato alcunchè... In soldoni, il CTU ha modificato l'originale, ma non c'è traccia di data ed ora successiva al giorno del sequestro, quindi non v'è modo di dimostrare che ha attaccato l'hd originale ad un sistema sprotetto da scrittura. Il problema è chiaramente più teorico che pratico, ci son cose peggiori in giro ;) Per concludere, le stesse prove fatte con FATx danno MD5 identici, forse perchè FATx non è Journaled, mentre NTFS sì...e $Logfile è il journal di ntfs.

104

PILLOLE DI SAGGEZZA Come si fa a sapere quando il computer è stato acceso/spento? Ecco alcuni metodi (per Windows OS): 1) L’ultima accensione coincide con ora e data dei files pagefile.sys o hiberfile.sys e del file: c:\Document and Settings\nome_utente\NTUSER.DAT; 2) Si può utilizzare il software PC On/Off che si trova nella parte windows del CD di Helix; 3) Guardando il registro degli eventi di Windows (event viewer sull’eventlog). L’evento 6005 è l’avvio del sistema e l’evento 6006 è lo shutdown; 4) Si analizza la TIMELINE di un qualsiasi tool di analisi delle attività dei files (Autopsy, log2timeline, Encase, ecc.). Come si monta un’immagine su Linux? Ecco i due sistemi: losetup /dev/loop0 disco.dd poi mount /dev/loop0 /mnt/disco (dove la directory disco l’avremo creata preventivamente con mkdir /mnt/disco) oppure più velocemente: mount -o loop /tmp/disco.img /mnt/disco Montare una partizione: mount –t auto –o ro,loop,offset=32256 /media/hdb1/disco.dd /media/mountpoint

105

dove 32256 è pari a 63*512 bisogna fare lo stesso per le altre partizioni ossia moltiplicare il settore di START * 512 bytes per avere l’offset. Per capire i punti di start delle partizioni si può usare mmls o fdisk. ACQUISIZIONE VIA RETE Può accadere di dover acquisire via rete: Sulla workstation di acquisizione: ifconfig ethx 10.0.0.1 netcat –l –p 2000 > /media/hdb1/disco.dd (in ascolto) Sulla macchina da acquisire da CD-LIVE: dd if=device_da_acquisire bs=2048 | netcat 10.0.0.1 2000 HASH DISCO CLONATO SU DISCO PIÙ GRANDE Se si clona un hard disk su un supporto più grande, per controllare se l’hash coincide si deve fare così: 1. Si cerca il numeor di settori totali dell’hard disk (es. /dev/sdb) da clonare, con fdisk. 2. Si clona l’hard disk: dd if=/dev/sdb of=/dev/sdc bs=512 skip=0 3. Si fa l’hash solo del numero di settori clonati su /dev/sdc e non di tutto l’hard disk: dd if=/dev/sdc skip=0 count=num_settori_di_sdb | md5sum –

106

STERILIZZARE E CONTROLLARE: dcfldd if=/dev/zero of=/dev/hdx bs=4096 (usiamo bytesize di 4Kb per andare più veloci e dcfldd perché ci permette di vedere l’avanzamento) controlliamo che sia tutto azzerato con: xxd –a /dev/hdx

Estrarre le sessioni da un CD/DVD-ROM multisessione Se su un CD o un DVD rom ci sono più sessioni, dovremmo estrarle tutte, perché in sessioni passate ci potrebbero essere dei contenuti diversi da quello che si vede sul CD/DVD, ossia l’ultima sessione. Basta montare il CD/DVD col filesystem cdfs al posto dell’iso9660, se non si ha il cdfs bisognerà scaricarlo ed installarlo sulla propria versione di Linux. # mount -t cdfs -o ro /dev/hdx /media/cdfs # ls -l /media/cdfs vedremo (per esempio): session1.iso session2.iso Copiare i files ISO in una cartella es.: /iso $ cp /media/cdfs/*.iso /iso questo punto possiamo montare le due immagini col loopback oppure masterizzarle per poi analizzarle: # mount -t iso9660 -o loop /iso/session1.iso /media/loop1 # mount -t iso9660 -o loop /iso/session2.iso /media/loop2

107

Procedura di acquisizione da Live CD (es. Caine) Una volta effettuato il boot da CD Live, verifichiamo subito le caratteristiche degli hard disk attaccati alla nostra workstation di acquisizione (chiaramente si presume non ci siano problemi di dischi particolari, errori, hpa e dco non rilevati, ecc.) 1) fdisk -lu 2) hdparm –gI /dev/hdx (dove hdx è il disco da duplicare) 3) sudo mount – o rw /dev/hdb1 (hdb1 disco che ospiterà l’immagine di hdx) 4) mkdir /media/hdb1/dischi (creiamo la dir dischi) 5) fdisk –lu > /media/hdb1/dischi/dischi.txt (direzioniamo l’output di fdisk su file di testo dischi.txt) 6) hdparm –gI >> /media/hdb1/dischi/dischi.txt 7) Lanciamo AIR o ADEPTO 8) Salviamo il log file finale su hdb1 col nome log.txt 9) MD5 e SHA1 o solo SHA256 dei file dischi.txt e log.txt su file hash.txt 10) SHA1 e MD5 del file immagine e dell’hd originale su file hash.txt 11) MD5 e SHA1 del file hash.txt o solo SHA256

VIRTUALIZZARE VirtualBox

IL

FILE

IMMAGINE

CON

Una volta acquisita l’immagine di un hard disk, es. disco.dd, possiamo virtualizzarla creando una macchina virtuale con VirtualBox (open source), basterà convertire l’immagine .dd in .vdi e poi utilizzarla come hard disk della macchina virtuale, ecco come: lanciare una finestra terminale (shell): 108

sudo vboxmanage convertdd /media/hdb1/disco.vdi

/media/hdb1/disco.dd

Ricordiamo che per creare una macchina virtuale si può utilizzare anche l’ottimo QEMU http://fabrice.bellard.free.fr/qemu/ Per convertire un’immagine dd in formato VMDK (VMWare): qemu-img convert disco.dd –o vdmk disco.vdmk HashBot - congeliamo il web! Ormai il Web 2.0 impazza, siamo tutti più o meno protagonisti in varie piazze virtuali, ci si innamora, si litiga, si stringono amicizie, si fanno guerre ideologiche, ci si critica, insomma tutto il bene e tutto il male che l'uomo può esprimere. Diffamazione, stalking, violazione del copyright, ecc. ecc. sono tra i fatti, che posson accadere sul web, ma tecnicamente e giuridicamente diventa difficile "cristallizare" una pagina web e farne una copia conforme, perchè essa è spesso dinamica, essa spesso cambia, il proprietario ne altera il contenuto appena sente puzza di bruciato e tante altre motivazioni, note a chi si occupa di computer forensics. Ecco che Gianni Amato e Davide Baglieri, con il testing ed i suggerimenti di tanti membri di CFI (Computer Forensics Italy), hanno sviluppato HashBot http://www.hashbot.com/. Curiosi di saperne di più? Lascio l'approfondimento ad uno dei suoi creatori: http://www.gianniamato.it/2009/04/hashbotcom-congela-undocumento-web-e.html 109

Ricordiamo alcune semplici acquisizione di un sito web:

regole

per

una

corretta

1) Utilizzare un tool come wget per prelevare i codici HTML/Javascript/CSS delle pagine: wget –m http://www.sitoweb.com che non si identifica con uno User Agent particolare, in modo da prelevare le pagine in maniera indipendente da eventuali renderizzazioni ad hoc per particolari browser, poi acquisire anche coi browser più noti (salva codice sorgente). Anche consigliabile wget –m – k al fine di rendere il sito acquisito navigabile offline. 2) Dichiarare sempre con che browser si è visualizzato il sito, annotare data ed ora e sistema operativo. 3) Usare HashBot e altri sistemi terzi che potrebbero conservare traccia del sito. 4) Laddove possibile agire: 4.1) Sotto perizia giurata. 4.2) Firmare digitalmente i pacchetto di file acquisiti. 4.3) Applicare un hash code a tutti i file ed al pacchetto. 4.4) Applicare una marca temporale. Creare un timeline con Sleuthkit: Individuata la partizione che inizia, per esempio, al settore 63 ed è del tipo NTFS: sudo fls -s '0' -m 'C:/' -f ntfs -o 63 -r -i raw /dev/sda > body sudo mactime -b body -d -i hour timeline.txt.sum 201012-01..2010-12-31 > timeline.csv 110

I FUNDAMENTALS LEGALI Da studiare: Ratifica della Convenzione di Budapest Nuova legge sul Cybercrime Legge n. 48 del 2008 Accertamenti tecnici L’Art. 359 c.p.p. (Consulenti tecnici del P.M.) prevede che il P.M., quando procede ad accertamenti, rilievi segnaletici, descrittivi o fotografici e ad ogni altra operazione tecnica per cui sono necessarie specifiche competenze, può nominare e avvalersi di consulenti, che non possono rifiutare la loro opera. Il consulente può essere autorizzato dal P.M. ad assistere a singoli atti di indagine. L’Art. 360 c.p.p. (Accertamenti Tecnici Non Ripetibili) prevede che, quando gli accertamenti previsti dall’artt. 359 riguardano persone, cose o luoghi il cui stato è soggetto a modificazione, il P.M. avvisa, senza ritardo, la persona sottoposta alle indagini, la persona offesa dal reato e i difensori del giorno, dell’ora e del luogo fissati per il conferimento dell’incarico e della facoltà di nominare consulenti tecnici. I difensori nonché i consulenti tecnici eventualmente nominati, hanno diritto di assistere al conferimento dell’incarico, di partecipare agli accertamenti e di formulare osservazioni o riserve. E’ prassi chiamare l’art. 359 c.p.p. “accertamento ripetibile”. D.P.R. 115/2002 – Testo unico in materia di spese di giustizia

111

RIFERIMENTI GUIDA

STORICI

E

LINEE

1984 FBI Magnetic Media Program created... this later becomes the Computer Analysis and Response Team (CART) 1995 International Organization on Computer Evidence (IOCE) formed •

RFC3227 -Guidelines for Evidence Collection and Archiving (2002)

•

USA –Department of SeizingComputers(2002)

•

USA –IACP -Best Practices for Seizing Electronic Evidence (2006)

•

USA –DoJ–Electronic Crime Scene Investigation v. 2 (2008)

•

UK –ACPO –Computer Based Evidence Guidelines v.4 (2008) - Association of Chief Police Officers (ACPO) guidelines

Justice

-Searchingand

Computer Forensics Tool Testing (CFTT) by NIST (National Institute of Standards and Technology) Per iniziare a capire ed operare in quest’ambito consiglio dunque per iniziare ti inviterei ad iscriverti a CFI mailing list, con tantissimi membri che discutono di queste 112

tematiche e e leggere nel gruppo alcune discussione che si sono tenute in passato: http://groups.google.com/group/cfitaly/search?hl=it_IT&gr oup=cfitaly&q=come+iniziare Imparare bene a leggere e comprendere l’inglese. Testi consigliati: http://www.linuxleo.com/Docs/linuxintro-LEFE-3.78.pdf Qui ci sono alcuni testi: http://www.cfitaly.net/pubblicazioni Ma la BIBBIA è questo: http://www.amazon.com/System-Forensic-Analysis-BrianCarrier/dp/0321268172 Per quanto riguarda Windows...c'è molto, ma è tutto MOLTO costoso...qualche esperimentino casalingo lo si può fare con FTK Imager http://www.accessdata.com/downloads.html e USB Write Blocker http://www.gaijin.at/en/dlusbwp.php o WinTaylor (qui sono di parte) http://www.caine-live.net . Infine, prima di operare sul campo, affiancare un esperto e chiedere ed osservare molto, oltre che capire le procedure forensi italiane.

113

CONCLUSIONI Spero che con questo testo abbia contribuito a realizzare un mezzo utile e pratico che funga da compendio di tanti PDF e libri. Spesso ci si trova di fronte a molta informazione sparsa per i nostri hard disk o nella nostra libreria e non sappiamo più dove trovare la cosa che cerchiamo oppure dimentichiamo dei concetti appresi da letture fatte tempo addietro, ecco perché ho pensato a questo testo, che spero descriva la spina dorsale della computer forensics, poi il dettaglio va, sicuramente, integrato con le ricerche ed i confronti con gli altri esperti del settore. Non ho impostato il libro sulla descrizione dei tools di acquisizione, ricerca, parsing, ecc. per due ragioni, la prima è che è un mondo sconfinato, la seconda è che questi strumenti hanno tempi di obsolescenza brevissimi, quindi conviene aggiornarsi sempre attraverso il web. Non ho parlato tanto della Mobile Forensics, perché è basata molto sull’irrepetibilità delle procedure e quindi assimilabile alla Network Forensics (citata nell’Analisi Live) e poi perché è una branca legata a doppio filo con i software di acquisizione ed analisi, diversamente dalla Computer Forensics, dove si creano delle scene del crimine vere e quindi bisogna adottare un mix di hardware, software, esperienza, psicologia, furbizia e ….tanta fortuna!

114

Links interessanti: _ http://www.cfitaly.net – Computer Forensics Italy - http://www.nannibassetti.com/dblog - http://www.gianniamato.it _ http://www.denisfrati.it - http://sfdumper.sourceforge.net - http://scripts4cf.sf.net - http://www.caine-live.net/ - http://www.deftlinux.net/ - http://www.forlex.it - http://linuxsleuthing.blogspot.com/ - http://www.linuxteam.info/ _ http://forensicsbypila.blogspot.com/ _ http://www.cybercrimes.it _ http://www.ismprofessional.net/pascucci/ _ http://www.ictlex.com _ http://ptk.dflabs.com/ _ http://www.iisfa.it/index.html _ http://forensics.typepad.com/ _ http://www.marcomattiucci.it/ _ http://www.ossblog.it/ _ http://www.guidancesoftware.com/ (ENCASE) _ http://www.accessdata.com/products/ (UTK) _ http://www.techpathways.com/ProDiscoverDFT.htm (PRODISCOVER) _ http://www.e-fense.com/helix/forum/index.php (HELIX) _ http://www.winhex.com/ (X-Ways) _ http://www.sleuthkit.org (Autopsy e Sleuthkit) _ http://dftt.sourceforge.net/ (esercizi di computer forensics) _ http://www.honeynet.org/misc/chall.html (esercizi di computer forensics) -- http://www.dc3.mil/challenge/

115

Nanni Bassetti Curatore ed ideatore di quest’opera Nanni Bassetti - Laureato in Scienze dell'Informazione a Bari si occupa di web application development e system administration dal 1998 presso la sua azienda IBOL S.r.l. di Bari e dal 2004 titolare della NBS ditta specializzata in sicurezza informatica. Ha collaborato come free-lance con parecchie riviste informatiche nazionali ed internazionali e come docente per molti corsi presso enti ,scuole ed università ed ha scritto articoli divulgativi di programmazione, web usability e sicurezza informatica. Ha lavorato come ausiliario di Polizia Giudiziaria e CTU/CTP per alcune analisi forensi informatiche e crimini informatici. Consulente sulla sicurezza dati per l'adeguamento alle direttive del nuovo Codice in materia di protezione dei dati personali D.lgs. 196/2003. Iscritto all'albo dei C.T.U. presso il Tribunale di Bari. Consulente di parte civile per la famiglia di Brenda (caso BrendaMarrazzo). Fondatore di CFI – Computer Forensics Italy la più grande community, di computer forensics, italiana (http://www.cfitaly.net). Internal auditor ISO 27001. Project manager di CAINE Linux Live Distro forense (http://www.cainelive.net/ ) e curatore di NBCAINE la versione live usb di Caine. Curatore del sito http://scripts4cf.sf.net e realizzatore di alcune modifiche nel software AIR (Automated Image and Restore) http://airimager.sourceforge.net/ Ha pubblicato "INTERNET WEB SECURITY -TUTTA LA VERITÀ SULLA SICUREZZA DEL WEB" nel 2004 con la Duke Editrice - ISBN: 8886460201 Ha Pubblicato nel 2006 il suo romanzo thriller/informatico/esoterico “Onphalos” -ISBN 978-88-7418-421-7 con la Prospettiva Editrice http://www.nannibassetti.com/romanzo E-mail: [email protected], [email protected] http://www.nannibassetti.com

116

NOTE

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

117

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

118

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

119

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

120

121