Network forensics: un approccio laterale

Computer forensics e investigazioni digitali: Dott. Ing. Paolo Verderi tecniche e strategie informatico-giuridiche Dott. Ing. Marco Carlo Spada di gestione degli incidenti informatici Dott. Donato La Muscatella Dott. Davide Paltrinieri

Network forensics. Un approccio “laterale”.

Abstract Il lavoro ha conseguito l’obiettivo di definire un insieme di “best practices” giuridicamente

valide riguardo al tema dell’acquisizione di prove in rete utilizzabili nel procedimento penale. Partendo dall’acquisizione di un falso sito web corredata dalle relative prove, abbiamo cercato di

soddisfare le esigenze di rigore tecnico e metodologico circa la completezza della stessa attività di acquisizione (o almeno così abbiamo fatto sembrare), circa l’integrità ed l’esaminabilità dei dati acquisiti, circa la verificabilità delle procedure seguite, facendo anche uso della firma digitale per dare garanzia su integrità, autenticità e validazione temporale dei reperti acquisiti.

Il fatto stesso di cimentarsi con la produzione di un falso ci ha consentito di evidenziare i punti deboli dell’attività fraudolenta svolta dandoci modo di individuare un insieme di test e analisi idonei a smascherarlo.

Le reiterazioni del progetto attraverso cui siamo passati per migliorare la qualità del falso ci hanno consentito di individuare anche quegli ulteriori elementi probanti che se prodotti renderebbero particolarmente complessa la realizzazione del falso stesso.

Le considerazioni fin qui esposte ci hanno condotto a redigere la seguente checklist di attività che dovrebbero sempre essere parte di una attività di acquisizione di siti web:

Far partire la registrazione “esterna”. Far partire la registrazione “interna”. Visualizzare la o le connessioni di rete. Visualizzare l'assenza di condivisioni, incluso quelle amministrative. Visualizzare il contenuto del file hosts. Azzerare la cache del browser. Caricare il programma di sniffing (es.Wireshark). Fare un traceroute al server DNS. Fare un traceroute al server NTP. Sincronizzazione dell’ora su un server NTP. Caricare il browser. Aprire la pagina di Google. Cercare sito “bersaglio”. Cliccare sul link di Google al sito. Visualizzare il sito. Avviare un programma che reitera in background il traceroute al server NTP. Sincronizzazione dell’ora su un server NTP. Avviare un programma che reitera in background il traceroute al server del sito. Se possibile, registrare la pagina visualizzata con hashbot [14] Verificare di chi è il sito (http://whois.domaintools.com/<nome_sito>). Verificare di chi è il sito (http://www.wipmania.com/whois/<ip_sito>/?ff). Chiudere il browser. Fare un check del sito con httprecon [15] Sincronizzazione dell’ora su un server NTP.

Computer forensics e investigazioni digitali: tecniche e strategie informatico-giuridiche di gestione degli incidenti informatici

Università degli Studi di Milano A.A. 2010/11 pag. 2/39

Salvare traffico. Chiudere il programma di sniffing. Fermare la registrazione “interna”. Salvare video. Comprimere i due file in uno zip. Firmare lo zip con firma digitale. Verifica della firma. Fermare la registrazione “esterna”.



1. L’idea: realizzare un falso e corredarlo della “prova”. Nell’ambito del contributo richiesto ai partecipanti al corso, abbiamo deciso di unire i nostri

sforzi per derivare delle “best practices” riguardo al tema dell’acquisizione di prove in rete (ad esempio di un sito che presenti materiale diffamatorio o ingiurioso) attraverso un approccio “laterale”. L’esigenza di affrontare il tema da un punto di vista differente si è materializzata in noi fin dai primi momenti di confronto: è infatti emerso con chiarezza che l’analisi “in astratto” delle tecniche probatorie riguardo l’attività di acquisizione di un sito non poteva che essere accompagnata da una disamina sulle possibilità di contestazione delle stesse prove prodotte a supporto della veridicità del sito acquisito.

Dal dubbio nasce la domanda se e quanto è sicura una prova nel caso in cui fossimo in grado di riprodurla identica o modificata a piacere e con le stesse caratteristiche oggettive di qualità attendibilità, autenticità, integrità e immodificabilità.

In altre parole la domanda alla quale sarebbe stato necessario rispondere diveniva: “quali contestazioni potrebbero essere mosse alle prove di veridicità dell’acquisizione da noi prodotta?”. Da questa non banale considerazione si è fatta strada in noi l’idea di “ribaltare” il percorso cioè: perché allora non provare a realizzare una falsa acquisizione corredata dalle relative prove?

L’idea di realizzare una falsa acquisizione corredandola delle relative prove ci è sembrata quindi la strada migliore per derivare delle prescrizioni sulle modalità di acquisizione.

Abbiamo cercato di soddisfare le esigenze di rigore tecnico e metodologico nella completezza dell’acquisizione (o almeno così abbiamo fatto sembrare), integrità ed esaminabilità dei dati acquisiti, verificabilità delle procedure seguite e abbiamo usato la firma digitale per dare garanzia della integrità e autenticità e validare temporalmente (time stamping) i reperti e le operazioni per dare garanzia della esistenza della stessa in un certo istante, ovviamente non è fattibile la riproducibilità delle procedure eseguite.

L’esigenza di affrontare le difficoltà di produzione di un falso ci ha infatti consentito di evidenziare i punti “deboli” dell’attività “fraudolenta” svolta indicandoci pertanto i test e le analisi necessarie per smascherarla. Ma non solo, infatti come vedremo, le reiterazioni del progetto attraverso cui siamo passati per “migliorare la qualità” del falso ci hanno consentito di individuare che l’inclusione nell’acquisizione di ulteriori elementi probanti avrebbe reso particolarmente complessa la realizzazione del falso. Così è apparso evidente come la presenza di tali ulteriori elementi di probatori rafforzi il valore dell’acquisizione stessa. Di fatto abbiamo ottenuto delle prescrizioni per l’acquisizione che vanno a pieno titolo incluse fra le “best practices” per questa attività.

Ulteriore obiettivo della ricerca è stato individuare le corrette modalità di utilizzazione processuale delle evidenze acquisite, ed i margini di riscontro di eventuali falsificazioni probatorie, verificando la tenuta, in questa materia, dell’attuale sistema di garanzie, anche alla luce delle innovazioni introdotte dalla legge n. 48 del 2008 e degli orientamenti giurisprudenziali.



Come sempre accade in attività di questo tipo non ci aspettiamo di aver esaurito l’argomento, consci che qualcuno più bravo di noi si dimostri capace di realizzare falsi ancor più robusti, però siamo convinti di aver dato un piccolo contributo.



2. Profili tecnici comuni ad entrambe le realizzazioni: Per prima cosa è stato necessario riprodurre il falso sito che è stato copiato con “HTTrack

Website Copier” (http://www.httrack.com) su un portatile con sistema operativo Windows Seven e server web IIS

Per esigenze “pratiche” condizionate dalla scarsa disponibilità di tempo (e nella consapevolezza di poter correggere questo aspetto con poca difficoltà) abbiamo optato per la pubblicazione del falso su di un computer equipaggiato con il server Microsoft IIS v. 7.5 (differente pertanto dalla versione 7.0 rilevata sul server del sito originale – aspetto che vedremo sarà puntualmente rilevata dalle analisi effettuate).

Per la realizzazione dell’acquisizione abbiamo poi fatto una checklist di attività la cui esecuzione ci è sembrata necessaria in tutti i casi. Va evidenziato che la filosofia di indirizzo per l’esecuzione dell’acquisizione è quella della realizzazione di un “filmato” della navigazione effettuata sul sito. In questo modo si ha la possibilità di vedere e valutare i contenuti del sito nell’ambito della dinamica dell’interazione client-server cioè nella condizione tipica di fruizione dei contenuti web. Questa si contrappone alle tecniche di acquisizione statica delle pagine realizzabile attraverso l’uso di strumenti software quali il comando UNIX/Linux “wget –mirror” e il già citato programma “HTTrack Website Copier” per Windows o, in alternativa, realizzabile con l’ausilio di servizi di certificazione “terzi” quali quelli offerti dal sito www.hashbot.com o la stampa in hard copy della pagina web su carta eseguita e controfirmata da un notaio.

L’uso della tecnica del filmato consente anche le acquisizioni di siti di tipo dinamico superando i limiti delle tecniche poc’anzi elencate che risultano valide e applicabili solo per le pagine statiche, ma comporta la necessità di corredare il filmato stesso con della documentazione che ne rafforzi il valore probatorio fugando ogni dubbio sulla possibilità che il filmato riproduca la navigazione di un falso sito sostituito in qualche modo a quello originale. Va sottolineato che la produzione del falso di un sito dinamico richiederebbe una preparazione molto più laboriosa rispetto a quella necessaria per falsificare un sito statico, ma (anche tenendo in buon conto questa maggiore difficoltà) la presentazione del solo filmato sulla navigazione sarebbe da considerarsi insufficiente ai fini probatori.

Pertanto abbiamo completato le acquisizioni con un file di cattura “live” del traffico di rete prodotto dall’attività della navigazione stessa e abbiamo “sigillato” il tutto con la firma dei file delle attività con carta SISS.

Le considerazioni fin qui esposte ci hanno condotto a redigere la seguente checklist delle attività comuni a tutte le acquisizioni:

• Far partire la registrazione “esterna”. • Far partire la registrazione “interna”. • Visualizzare la/le connessioni di rete. • Caricare il programma di Wireshark qui usato per in funzione di sniffer. • Sincronizzazione dell’ora su un server NTP. • Caricare il browser Firefox. • Aprire la pagina di Google. • Cercare la parola “perfezionisti”. • Visualizzare sito www.perfezionisti.it . • Verificare di chi è il sito (http://whois.domaintools.com/perfezionisti.it)



• Verificare di chi è il sito (http://www.wipmania.com/whois/82.85.92.195/?ff). • Chiudere Firefox. • Salvare traffico. • Chiudere Wireshark. • Fermare la registrazione “interna”. • Salvare video. • Fare uno zip dei due file. • Firmare lo zip con CRS-SISS. • Verifica della firma. • Fermare la registrazione “esterna”.

Le due registrazioni filmate “esterna” ed “interna” sono necessarie al fine di rendere evidente (attraverso la registrazione esterna) che le attività di registrazione “interna” con il salvataggio, la compressione dei dati e la firma dei files sono state eseguite completamente rispettando tutti i passaggi.

Riportiamo di seguito alcuni screenshot relativi alla checklist:

Verifica dell’ora della connessione:



Apertura di Firefox:



Ricerca su Google del sito dei perfezionisti:

Richiamo del link di Google.

.



A questo punto con whois si risale al soggetto che ha registrato il sito.



Registrazione del file di cattura del traffico

Arresto e registrazione del video:



Compressione dei due file

Firma digitale con carta CRS-SISS



3. Profili giuridici Gli accertamenti di network forensics, ed in particolare quelli operati su siti web, possono

assumere particolare rilevanza giuridica nella prospettiva del difensore, condizionando sempre più spesso, nell’attuale società della comunicazione virtuale, l’esito di procedimenti penali.

Documentare i contenuti pubblicati online in modo scientificamente corretto, oggettivo, dimostrabile e, dunque, giuridicamente solido, diviene l’essenziale presupposto per poter pianificare un’efficace strategia forense, utilizzando al meglio le fonti di prova raccolte.

In simili ipotesi, naturalmente, sarà fondamentale il coordinamento, tempestivo ed efficace, tra difesa tecnica e difesa informatica. Tale conduzione dovrà poi proseguire anche qualora si giunga al dibattimento, ed in tale sede sarà fondamentale che il consulente assista alle udienze nelle quali si discuta di digital evidence (di tale presenza sarà bene far dare atto a verbale), per poter guidare il difensore nei punti più complessi di alcune escussioni (con particolare riferimento al controesame dei testi esperti e dei consulenti delle altre parti processuali).

Per ragioni di sintesi espositiva, ed in considerazione delle rilevanti differenze presenti con il rito civile, ci siamo soffermati sull’utilizzazione degli elementi raccolti nell’ambito di un procedimento penale, analizzando il punto di vista della persona offesa e dell’indagato, per poi concentrarci sui criteri di valutazione della nuova prova scientifica.

3.1. Le operazioni compiute Per poter valutare al meglio come procedere, tuttavia, si dovrà in primo luogo chiarire la natura

degli accertamenti che si intendono condurre, per poter rispettare le garanzie imposte dalle vigenti disposizioni processuali.

Al di là degli istituti coinvolti, infatti, l’eventuale ripetibilità di tali indagini, produce radicali differenze tanto nella procedura di acquisizione (che, in assenza di tale condizione, implica l’attuazione in contraddittorio di ogni operazione) quanto nel valore delle fonti di prova acquisite (che, nei casi di accertamento irripetibile, transitano direttamente nel fascicolo del dibattimento, acquisendo dignità di piena prova in virtù dell’esplicazione preventiva della dialettica processuale).

Nel caso di specie, si ritiene che, vista l’intrinseca fragilità dei reperti e la naturale dinamicità dei siti web (il cui contenuto, pur se progettati con un linguaggio “statico”, può essere variato con estrema rapidità, tanto da rendere indispensabile, quale migliore pratica, l’installazione di firma digitale sui documenti, per poter provare il riferimento temporale dei dati acquisiti), le attività di acquisizione, ad avviso di chi scrive, andrebbero qualificate come “irripetibili”.

Più nel dettaglio, tale qualificazione va correlata non alla possibilità che le indagini compiute alterino le fonti di prova (aspetto disciplinato dall’art. 117 d.a. c.p.p.), ma allo stesso trascorrere del tempo, durante il quale, per interventi esterni e non solo (si pensi ad un semplice problema tecnico del server in assenza di sistemi di ridondanza) i dati oggetto di acquisizione potrebbero essere modificati.

Si ritiene, dunque, che le attività che verranno descritte dovrebbero essere svolte con la procedura più garantista prevista dall’art. 360 c.p.p., alla presenza delle parti in contraddittorio, sia quando vengano poste in essere dalla polizia giudiziaria, sia qualora siano svolte dal consulente



tecnico del difensore. In tal modo, oltre a rispettare quanto previsto dal codice di rito, si otterrebbe l’ulteriore vantaggio, indiretto, di acquisire gli elementi di prova direttamente al fascicolo processuale, facendo si che essi vadano a far parte del compendio probatorio sulla base del quale il giudice formerà il proprio libero convincimento.

Risulta evidente, tuttavia, che non sempre si avrà modo di adottare simili cautele (si pensi solo al tempo necessario per comunicare a tutte le parti quanto si sta per fare). In questi casi, qualora non sia possibile procedere all’assunzione dell’evidenza in contraddittorio, sarà bene utilizzare la massima cautela ed accuratezza nelle investigazioni (sia nelle metodologie adottate sia nella puntuale documentazione di tutte le attività compiute), affinché, successivamente, sia possibile sostenere la genuinità delle fonti di prova acquisite, dinanzi alle eccezioni di utilizzabilità che potrebbero essere sollevate.

Quando si proceda all’acquisizione mediante la copia di dati rilevanti, infine, il consulente dovrà far riferimento al dovere di lasciare inalterato il dato originale e di garantire la conformità della copia, alla luce dei nuovi parametri codificati con la legge n. 48 del 2008.

3.2. La strategia difensiva È possibile ipotizzare che il professionista debba tutelare due posizioni contrapposte e, a seconda

della parte assistita, mutare la linea ottimale della tesi difensiva.

In particolare, nel nostro contributo, abbiamo ipotizzato l’utilizzo di un sito web per la pubblicazione di contenuti di tipo diffamatorio o ingiurioso, analizzando la possibilità che la prova digitale sia falsificata.

3.3. Indagato/Imputato La difesa, in questo caso, dovrà approfondire la rilevanza penale delle condotte compiute dal

proprio cliente e, soprattutto, valutare la sussistenza di eventuali circostanze che ne elidano o attenuino la responsabilità.

In primo luogo, quindi, dovrà essere individuato l’autore della pubblicazione asseritamente diffamatoria o ingiuriosa, tanto se si tratti di siti che consentano l’interazione degli utenti (forum, blog, etc.), quanto negli altri casi, in cui sarà necessario verificare eventuali accessi abusivi. In tal caso, a seguito di nomina per il compimento di investigazioni difensive e conferimento incarico ad un consulente tecnico, sarà necessario individuare e preservare ogni evidenza che consenta di ricondurre le dichiarazioni al proprio autore.

Altrettanto rilevante sarà lo studio delle policies di sicurezza del sito, affinché possa dimostrarsi la predisposizione di ogni misura tecnica idonea a scongiurare il rischio di consumazione di tali comportamenti e garantire un efficace controllo di quanto pubblicato per rimuovere tempestivamente contenuti illeciti.

Per ragioni di cautela, inoltre, ogni pubblicazione potenzialmente lesiva dovrà essere immediatamente rimossa, anche al fine di ridurre le conseguenze dannose della condotta (e, quindi, contenere i profili risarcitori) nella prospettiva di un’eventuale condanna e, qualora si decida di rinunciare al dibattimento, di soluzioni processuali alternative (quando praticabile, ad esempio, l’oblazione).



Sarà inoltre necessario, se disponibili, analizzare i terminali dai quali sono stati gestiti i contenuti, al fine di poter documentare quanto si affermerà in relazione all’estraneità ai fatti.

Tali precauzioni, naturalmente, permangono anche qualora sia lo stesso responsabile del sito ad aver pubblicato i contenuti ritenuti diffamatori, benché, in tal caso, l’attenzione del difensore dovrà concentrarsi sui profili di merito relativi all’integrazione di tutti gli elementi costitutivi delle fattispecie contestate (soprattutto con riferimento al tenore dei testi utilizzati).

Da un punto di vista procedimentale le osservazioni del consulente tecnico, comprese di eventuali allegati o supporti, potranno essere prodotte dopo aver reso interrogatorio sui soli aspetti di merito dinanzi al pubblico ministero (ai sensi dell’art. 391 octies, quarto comma, c.p.p.) ovvero, se si ritenga di non chiedere l’interrogatorio, mediante apposita memoria difensiva a sostegno della richiesta di archiviazione. Ritardare la discovery di tali elementi, infatti, complicherebbe l’acquisizione di eventuali elementi di riscontro estrinseco a quanto allegato, non fornendo alcun vantaggio strategico rilevante (possibile, invece, in relazione alle contestazioni che possano muoversi nei confronti dell’operato della polizia giudiziaria o dei consulenti tecnici dell’accusa).

3.4. Persona OFFESA Il difensore, per poter tutelare nel migliore dei modi i diritti di chi si ritenga diffamato tramite la

Rete, dovrà procedere nel modo più rapido possibile.

Dopo aver consultato il cliente per comprendere la dinamica dei fatti e, soprattutto, dove andare a cercare eventuali elementi di riscontro, si dovrà immediatamente procedere al conferimento di una nomina ai sensi dell’art. 391 nonies c.p.p., per poter compiere investigazioni difensive preventive tese ad individuare e preservare le fonti di prova.

Il difensore potrà dunque incaricare un consulente tecnico con specifica formazione che procederà ad acquisire, rispettando le procedure citate, ogni evidenza rilevante per provare : a) i contenuti pubblicati; b) l’identità dell’autore; c) il momento della pubblicazione; d) il tempo di permanenza sul sito; e) se ancora reperibili, gli accessi compiuti al sito nel periodo di riferimento.

Lo scopo delle diverse acquisizioni sarà fornire per tutte le informazioni rilevanti, più elementi di riscontro, provenienti da fonti diverse (ove possibile, ad esempio, network based ed in locale), soprattutto per quanto concerne eventuali files di log (che ad avviso di alcuni giudici di merito, se provengano dalla persona offesa, non costituiscono materiale sufficiente a fondare una pronuncia di responsabilità, cfr. Tribunale di Chieti, 2 marzo, 2006).

Oltre agli aspetti di merito, utili ad individuare i responsabili della diffamazione ed a provarne le responsabilità, sarà importante preservare ogni elemento rilevante per poter fornire già in sede penale la prova del danno subito e consentire così al giudice, in caso di condanna, la determinazione di una liquidazione provvisionale (una stima presuntiva, ad esempio, potrebbe essere compiuta sulla base del tempo di permanenza online e degli accessi al sito).

Il materiale raccolto sarà quindi allegato ad atto di denuncia-querela, cui potrà accludersi, quando necessaria per interrompere la prosecuzione della condotta diffamatoria, una richiesta urgente di sequestro preventivo (ai sensi dell’art. 321 c.p.p.) con lo scopo di impedire che la libera disponibilità del sito incriminato possa aggravare o protrarre le conseguenze dannose del reato.



3.5. … e la prova scientifica? Aspetto comune ad entrambi i ruoli processuali è quello relativo ai criteri di valutazione della

prova digitale, quale nuova prova scientifica del terzo millennio. L’entità e la sostanza del contributo che le nuove tecnologie possono fornire al giudizio penale dipende in larga misura, infatti, dal modo con il quale l’ordinamento regola il rapporto tra scienza e diritto.

Quale che sia lo scopo delle parti all’interno del processo, sarà fondamentale individuare i parametri di garanzia che dovranno connotare le operazioni tecniche e le prove digitali acquisite.

In caso di falsificazione delle evidenze digitali prodotte al termine degli accertamenti telematici, come sarà possibile accertare le carenze delle fonti di prova raccolte?

Quali sono i criteri che dovranno guidare il giudice per governare l’ingresso di queste nuove tecnologie di indagine nel processo?

Sebbene il risultato delle investigazioni digitali sia prodotto in dibattimento, tendenzialmente, in forma documentale (rientrando nella nozione prevista, anche dopo la riforma del 2008, dall’art. 491 bis c.p.) le modalità con le quali si perviene alla prova digitale saranno oggetto, nel nostro sistema, del giudizio di ammissibilità previsto dall’art.189 c.p.p. per le prove atipiche.

Lo strumento probatorio, per essere legittimo, dovrà quindi presentare dei requisiti di rilevanza, attendibilità, comprensibilità e ragionevolezza, in conformità a quanto sancito dalle migliori interpretazioni dottrinali [8].

Il codice di rito accusatorio, infatti, oltre ad obbligare ad un’effettiva cross examination del materiale probatorio, conferisce al giudice un ruolo attivo di filtro rispetto a prove che non siano idonee ad assicurare l’accertamento dei fatti [9].

Tali presupposti saranno valutati dal giudice sulla scorta di criteri che egli stesso individuerà in base alle elaborazioni teoriche ed agli orientamenti giurisprudenziali. Questa impostazione è il frutto più evidente di un progressivo avvicinamento a dinamiche processuali tipiche dei sistemi di diritto comune, ed, in particolare, di quello statunitense, la cui logica viene adottata ed estesa, rimuovendo lo statico riferimento ai parametri annunciati dal Daubert standard [10].

Nella decisione fu ribadito il contenuto della Rule 702 sottolineando che la consulenza tecnica deve essere basata su validi metodi e principi scientifici mentre resta al giudice federale la responsabilità di ammettere o meno la consulenza al dibattimento. La corte osservava come, anche etimologicamente, il termine scientifico rimandava a qualcosa fondato su metodi, procedure o principi della miglior scienza del momento storico.

Al criterio della general acceptance già previsto nello standard Frye [11] si affianca, dunque, quello che giudica l’ammissibilità della prova scientifica sulla base della sua affidabilità (reliability). Per fare un esempio pratico, quindi, sarà importante che gli eventuali log siano prodotti in formato “grezzo” elettronico e non, come spesso avviene, depositati su stampa cartacea come se si trattasse di una qualunque prova documentale.

Il giudice si riappropria del suo ruolo di filtro (gatekeeper), evitando l’abdicazione dal controllo a favore della comunità degli esperti, e potendo verificare direttamente la genuinità degli elementi



probatori che originerebbero dall’accertamento tecnico. Tale inversione di tendenza, sicuramente auspicabile nell’ottica dei giuristi, non rimane immune da difficoltà applicative.

In che modo il magistrato potrà valutare l’attendibilità di una metodologia estranea al suo percorso formativo, accademico e professionale e, per di più, su che base motiverà la propria decisione sul punto?

Il giudice risponde a questi interrogativi con una serie di elementi che, restando nella prospettiva oggettiva di quelli già presenti nel precedente standard, possono essere valutati a prescindere dalla preparazione specifica dell’interprete. Non si chiede al giudice di divenire scienziato ma, piuttosto, di impiegare criteri e principi scientifici che siano suscettibili di verificazione o falsificazione (cioè sottoposti a precedenti verifiche secondo la falsificabilità delle teorie scientifiche di Popper) e sottoponibili al controllo della comunità scientifica.

Sotto questo profilo il test dell’accettazione generale si traduce nella pubblicazione dei risultati delle ricerche su riviste del settore accreditate ad opera di revisori qualificati (c.d. peer review), diminuendo la sua incisività sulla decisione, e rendendo possibile l’ammissione al dibattimento di metodiche che, pur vantando un peso scientifico tale da essere oggetto di discussione dottrinale, non abbiano ancora ottenuto un consenso unanime da parte della comunità degli esperti.

Canone sussidiario è l’accettabilità dei margini di errore previsti dal metodo scelto (error rate), parametro poco sviluppato nella decisione in discussione poiché inadatto ad essere applicato a titolo generale (non tutte le discipline consentono di calcolare un margine di errore, si pensi al caso della perizia psichiatrica).

I criteri descritti, va detto, furono pienamente conformi a quelli espressi, solo dodici giorni dopo, dal Supremo Collegio (Cass. Pen., V, 09.07.1993), inaugurando un orientamento che, pur con successive evoluzioni, è rimasto sostanzialmente immutato.

In sostanza, quindi, le nuove tecnologie di investigazione telematica, dovranno essere :

- generalmente condivise all’interno della comunità scientifica di riferimento; - scientificamente affidabili; - validate da soggetti qualificati; - con un tasso noto di errore,

mirando ad assicurare una prova che sia rilevante, attendibile, comprensibile e ragionevole.

Sono questi gli obiettivi che l’operato dell’esperto dovrà per la validazione forense delle nuove tecnologie di indagine, affinché gli elementi di prova forniti al difensore a supporto della propria tesi siano solidi ed incontestabili.



4. La prima realizzazione 4.1. Descrizione del prototipo

Riportiamo in figura lo schema della rete utilizzata nella prima realizzazione:

Il sito modificato (il falso) è stato installato su di un PC sul quale risiede un web server configurato con lo stesso indirizzo IP del sito vero. Questo PC è collegato alla rete via cavo ad un apparato attivo con funzionalità di switch ethernet, access point WiFi e bridge di collegamento fra le due reti “wired” e “wireless”.

Su un portatile viene fatta l’acquisizione della prova. Il portatile opera l’acquisizione del traffico per mezzo della scheda wired (collegata via cavo e configurata con l’indirizzo IP di rete privata 10.220.21.2) mentre il collegamento al sito viene fatto tramite la scheda wireless (collegata via WiFi al “lato” access point dell’apparato) alla quale è associato un IP della stessa sottorete del sito.

Sul portatile che fa l’acquisizione è stata “mascherata” la visibilità della seconda scheda di rete per celare la presenza del clone del sito all’interno della rete locale prima dell’inizio delle operazioni di acquisizione. Vediamo le schermate che documentano queste attività preliminari.



Attività di mascheramento della seconda scheda di rete dal sistema:



Attività di mascheramento della seconda scheda di rete al programma di WireShark usato per la cattura del traffico:



4.2. Attività di analisi che “smascherano” la prima realizzazione.

Segnaliamo fin da subito che, alla luce della modalità di realizzazione del falso, appare evidente che tanto l’output prodotto dal comando tracert quanto quello prodotto dal comando ipconfig se eseguiti sulla macchina usata per l’acquisizione consentirebbero di mettere in evidenza le anomalie dovute alla configurazione adottata (la figura mostra che ipconfig non “collabora” con gli autori del falso in quanto non omette la verità sulla presenza del doppio collegamento di rete):



Pertanto nella discussione che ha seguito l’analisi di questa prima attività è stato proposto di includere nella documentazione dell’acquisizione anche l’esecuzione di questi due comandi. Va segnalato però che per quanto riguarda ipconfig non sarebbe tecnicamente difficile dotare il portatile di una versione modificata del comando stesso che risulti più “collaborativa” presentando solo l’output della configurazione della scheda wired (è pratica comune dei cracker che violano i sistemi di rete modificare i programmi informativi di sistema per nascondere le loro attività). Per il tracert invece il discorso è differente in quanto questo comando produce del traffico sulla rete con lo scopo ricostruire il percorso (i router e le reti da attraversare) che separa il computer su cui viene eseguito dalla destinazione assegnata (il comando nel nostro caso dovrebbe essere invocato nella forma tracert www.perfezionisti.it). Pertanto l’originalità del report prodotto da tracert verrebbe ad essere confermata dall’acquisizione del traffico di rete.

Superata questa prima valutazione (che riguarda l’assenza di elementi piuttosto che l’analisi del materiale prodotto) siamo passati all’esame dell’acquisizione del file in formato “pcap” ottenuto con Wireshark (rimando alle note di [16] oppure di [17] per un approfondimento su questo importante formato).

L’analisi è stata eseguita su un computer con sistema operativo MacOSX utilizzando gli strumenti software comunemente disponibili nell’ambiente UNIX lavorando in linea di comando da shell. Per alcune attività abbiamo anche utilizzato dei programmi open source reperibili gratuitamente in rete.

La prima cosa che appare strana è che nel file pcap non vi è alcun traffico destinato all’indirizzo IP del sito (82.85.92.195) e questa è sicuramente una anomalia in quanto avremmo dovuto trovare i pacchetti relativi alla navigazione verso il sito.



Per contro, sempre nel file pcap di cattura del traffico, ci sono delle richieste ARP che non dovremmo trovare. Usando il comando tcpdump -n -r Perfezionisti.pcap -s 1515 arp si ottengono tutte le richieste ARP; ne riportiamo una parte eliminando i duplicati:

16:02:22.240718 ARP, Request who-has 10.220.21.111 tell 10.220.21.100, length 46 16:03:10.132508 ARP, Request who-has 10.220.21.191 tell 10.220.21.100, length 46 16:02:14.248111 ARP, Request who-has 10.220.21.117 tell 10.220.21.2, length 28 16:02:15.326288 ARP, Request who-has 10.220.21.118 tell 10.220.21.2, length 28

Queste sono tracce normali che fanno parte di richieste di altri PC, o dischi di rete della lan domestica, le ultime due in particolare sono degli “sporchi” di una configurazione relative all’applicazione userlock. La “sorpresa” è riferita al fatto che fra gli ARP troviamo anche le seguenti tracce (anche qui abbiamo eliminato i duplicati):

16:01:53.574758 ARP, Request who-has 10.220.21.254 tell 82.85.92.195, length 46 16:02:08.039311 ARP, Request who-has 82.85.92.1 tell 82.85.92.195, length 46

Queste sono le richieste eseguite dal server clone che essendo dei pacchetti broadcast compaiono necessariamente su tutte le schede di rete del portatile di acquisizione e pertanto entrano nel pcap pur essendo questo solo letto dalla scheda wired. Necessariamente questi ARP portano come indirizzo IP mittente quello del server oggetto della nostra acquisizione pertanto questa macchina non può essere collocata in posizione esterna alla rete locale, ma deve trovarsi sullo stesso segmento LAN. La presenza di questi ARP provano senza alcun dubbio che la traccia pcap si riferisce da una attività tesa all’artefazione della prova.

Gli strumenti di analisi: tcpdump, Wireshark e NetworkMiner Per le analisi abbiamo utilizzato oltre a due strumenti di tradizione consolidata quali il tcpdump

citato sopra e il Wireshark anche un programma per Windows denominato NetworkMiner. Non riteniamo sia necessario spendere qui ulteriori parole su tcpdump e Wirshark data la loro vasta e consolidata adozione nelle attività di analisi e diagnostica del traffico di rete e rimandiamo, per gli interessati ad approfondire il tema, alla gran messe di documentazione relativa reperibile in Internet [18] [19].

Spendiamo invece due parole su NetworkMiner in quanto abbiamo “scoperto” questo software proprio durante l’esecuzione questa attività. Si tratta di un programma open source espressamente sviluppato per l’analisi forense dotato anch’esso di un modulo di cattura e sniffing dei pacchetti. In particolare questo programma è in grado di riconoscere il sistema operativo delle macchine coinvolte in una comunicazione, i nomi degli host, le porte aperte ed altre caratteristiche senza generare traffico di rete. NetworkMiner è anche in grado di leggere file di acquisizione nel formato standard pcap per eseguire delle analisi off-line. È stato sviluppato da Erik Hjelmvik, <[email protected]> ed è scaricabile dal sito http://www.netresec.com/.

Nella figure che seguono vediamo alcune immagini dell’analisi fatta con NetworkMiner sulla prima acquisizione.



Come si vede, troviamo che l’indirizzo IP locale 10.220.21.2 viene associato alla macchina N111796 ma troviamo anche, associato alla stessa macchina, l’IP 82.85.92.1: quindi anche qui viene evidenziato che sulla macchina c’erano due schede di rete.

Infine troviamo il sito clone, con tanto di mac address e la richiesta ARP vista sopra.



5. Seconda realizzazione 5.1. Descrizione della realizzazione

Sulla base della prima esperienza, abbiamo pertanto riprovato utilizzando una configurazione di rete decisamente più sofisticata. Di seguito riportiamo l’illustrato del nuovo schema dei collegamenti:

5.2. Attività di analisi che “smaschererebbero” la seconda realizzazione. Confrontando questa seconda realizzazione con la predente osserviamo che:

• l’uso di ipconfig darebbe un output da cui non risulterebbe evidenza di alcuna anomalia;

• l’uso di traceroute o tracert dalla stazione di acquisizione darebbe un output che evidenzierebbe chiaramente il “trucco”;

• dall’analisi del traffico verso l’indirizzo IP del sito (82.85.92.195) appare un comportamento corretto;



• anche l’analisi delle richieste ARP mostra un’attività corretta.

Col comando: tcpdump -n -r Perfezionisti.pcap -s 1515 arp si ottengono tutte le richieste ARP che, tolti i duplicati, appaiono solo nella forma:

19:31:41.637784 ARP, Request who-has 192.168.1.20 tell 192.168.1.1, length 46 19:31:41.637802 ARP, Reply 192.168.1.20 is-at 00:16:d3:c2:7f:8c, length 28

Queste sono le normali richieste effettuate dal PC usato per l’acquisizione che per navigare ha necessità di individuare il default gateway.

Analisi con NetworkMiner:

Il programma è molto severo e anche questa volta il falso viene smascherato! Si vede che la distanza dal sito è di un hop. In altre parole il programma ci dice che il sito verso cui navighiamo si trova proprio “dietro” il nostro primo router, cosa che anche se teoricamente possibile è altamente improbabile (solitamente dietro al primo router vi è la rete che il provider mette a disposizione della propria clientela per l’accesso ad Internet, il sito oggetto della nostra analisi dovrebbe trovarsi proprio là).

Ci siamo domandati come sia stato possibile per NetworkMiner ricavare questa informazione e abbiamo capito che ha eseguito un banale calcolo sul campo TTL dei pacchetti IP. Partendo però da una ispezione del contenuto dei pacchetti web. Più precisamente NetworkMiner ha analizzato il traffico web e da questo ha dedotto che sul server clone è in esecuzione un sistema operativo Windows di classe NT. Poiché questo sistema operativo inizializza i valori di TTL dei pacchetti IP a 128, il fatto di “vedere” i pacchetti arrivare con un valore TTL pari a 127 gli consente di affermare che questi hanno attraversato un solo router. Abbiamo reperito i valori di default per i TTL in funzione del sistema operativo all’indirizzo internet [12]. Si potrebbe tentare di argomentare che il calcolo fatto sul TTL per ricavare gli hop di distanza non sia un metodo preciso e universale, ma il valore letto (127) è decisamente “sospetto” infatti considerando una “distanza” media compresa approssimativamente fra 10 e 20 hop saremmo in presenza di un server che inizializza il campo ad un valore che sarebbe fra 135 e 150, numeri alquanto strani per il sistema binario (infatti nel sito citato poc’anzi non vi è alcun sistema operativo noto che usi questi valori).



5.3. Confronto conclusivo fra le realizzazioni Da un punto di vista tecnico, la seconda acquisizione migliora la precedente in quanto

consentirebbe di allegare alla documentazione l’output del comando ipconfig che nella prima non avrebbe potuto essere presentato; inoltre l’analisi della traccia del traffico non presenta anomalie quali l’assenza del traffico verso il sito e la presenza di richieste ARP emesse dal server web di destinazione.

Abbiamo invece identificato tramite WireShark la presenza di parecchi pacchetti indicati come “errati” e la presenza di comunicazioni protocolli che non erano presenti nella prima.

A questo punto ci è sembrato opportuno fare delle ulteriori analisi sul tracciato pcap dell’acquisizione seguendo le procedure per l’analisi delle prove raccolte sulla rete (dette anche NBE – Network Based Evidence) riferendoci alla letteratura americana in materia [13] allo scopo di verificare o escludere la presenza di ulteriori elementi che possano rivelare il falso o far insorgere il sospetto che di falso si tratti.

Le analisi eseguite non hanno dato risultati in nessuna delle due direzioni indicate, ma hanno solo consentito di far luce su quelle cose che in un primo momento erano state percepite come anomalie (pacchetti errati e protocolli “strani”). Sono pertanto stati riportati in appendice come corollario per la documentazione del metodo di indagine adottato.



6. Considerazioni estese 6.1. Scenario di siti web con contenuti dinamici Lo scenario fin ora considerato trattava il caso di un sito web dai contenuti prevalentemente

statici. Volendo estendere l'analisi a siti dai contenuti dinamici occorre adoperare alcune accortezze.

L'approccio di monitoraggio del traffico di rete è fondamentale in uno scenario di questo tipo, per poter tenere traccia e raccogliere flussi di dati che dipendono dall'interazione tra il client e il server, e non sono acquisibili direttamente da un qualsiasi client connesso al sito in esame.

Strumenti terzi come hashbot[14] sono molto utili quando dobbiamo acquisire pagine dal contenuto per lo più statico, ma quando una pagina web è scritta in AJAX o più in generale presenta dei contenuti dinamici, allora l'acquisizione con hashbot potrebbe risultare inefficace.

Hashbot ha alcune limitazioni quali la dimensione massima di 2MB per ogni file acquisibile, la mancanza di inclusione di tutti i file esterni cui la pagina acquisita fa riferimento e l'impossibilità di acquisire pagine accessibili tramite autenticazione.

Non volendo togliere nulla ad uno strumento validissimo come hashbot, occorre comunque stabilire delle linee guida che possano essere più robuste per sopperire ai limiti intrinseci di tale strumento.

Passi operativi aggiuntivi Riteniamo necessario oltre quanto è stato già fatto nei due scenari descritti nel nostro

esperimento, effettuare il dump (acquisizione integrale) dei sorgenti dell'intero sito web. Grazie ai sorgenti è possibile dimostrare la presenza di un riferimento al contenuto diffamatorio (in senso lato) all'interno dei sorgenti stessi e non come parte di una risorsa proveniente da siti terzi (banner pubblicitari, componenti di plugin compromessi o malevoli).

La rappresentazione del sito tramite il browser, è conseguenza di una interazione tra client su cui viene eseguita la navigazione e il server. Le risorse del sito mostrate al client possono differire a seconda delle informazioni raccolte dall’applicazione web (ad esesempio tramite componenti quali gli user-agent o i cookie) presso il client stesso.

Di conseguenza anche lo user-agent utilizzato e gli eventuali cookie appartenenti a passate navigazioni effettuate presso il sito da acquisire, possono influenzare l'acquisizione stessa, come nel caso descritto nell'articolo [1].

Non volendo riprendere tutto il testo dell'articolo [1] appena citato, ci limitiamo a dire che sono stati rilevati siti web compromessi in cui erano stati iniettati link a siti esterni, che erano normalmente nascosti ai browser più comuni, ma non ai BOT di Google. La presenza di un particolare cookie lato client, e di un certo valore in POST, facevano poi scattare l'esecuzione di ulteriori comandi PHP o di sistema impartiti con una semplice shell.

L'acquisizione dell'intero sito pertanto, nonostante i suoi contenuti restino invariati, può rivelarsi limitata ed incompleta a seconda del client utilizzato e del suo storico con il server da acquisire.



Inoltre lo stesso studio [1] ha riscontrato che anche all'interno del database è possibile annidare del codice eseguibile dalla web application fruibile dal web server, pertanto anche l'acquisizione dell'intero database in certi scenari può essere determinante.

L'acquisizione del database, tuttavia, non può essere compiuta senza la collaborazione del webmaster (in assenza della quale, non potendo il difensore procedere in autonomia sulla base delle facoltà che gli conferiscono le disposizioni in tema di investigazioni difensive, sarebbe necessario l'intervento dell'Autorità Giudiziaria competente) e, pertanto, esula dallo scenario fin ora trattato.

Le best practices che abbiamo elaborato, infatti, devono essere considerate protocolli operativi per il consulente che, affiancato dal solo difensore, si trovi a dover acquisire e preservare evidenze digitali nell'ambito di un caso di diffamazione a mezzo web.



6.2. Falsi miti da sfatare Se la web application fosse stata disponibile tramite HTTPS non sarebbe stato possibile in alcun

modo adoperare un server tarocco in stile MITM.

Falso!

Esistono infatti almeno due attacchi possibili che in un qualche modo permetterebbero l'utilizzo di un server tarocco anche se il server originale offrisse contenuti tramite connessioni HTTPS.

SSL Hijacking È documentato [2] come alcune implementazioni dell'utilizzo di HTTPS siano soggette ad

attacchi che permettano di rompere un flusso https prima che venga finalizzato.

Grazie a tool come SSLstrip [5] ad esempio un sito che trasmette contenuti tramite connessioni coi client in HTTPS può essere intercettato da un server tarocco che fa passare i contenuti del sito originale in HTTP.

Un attacco MITM che mantiene una connessione HTTPS anche tra il server tarocco e il client legittimo implica che sul server tarocco ci sia un certificato valido. Se così non fosse, al client verrebbe quantomeno mostrato un messaggio di errore tramite il browser che avvertendo l'utente delle conseguenze delega ad esso la responsabilità di decidere se proseguire o meno nella navigazione.

Sostituendo invece i riferimenti alle risorse in fruibili originariamente in HTTPS con i rispettivi link in HTTP non si hanno visibili messaggi di errore lato client come nel caso precedente. L'unico segnale lo si ha vedendo sparire l'icona che rappresenta una connessione sicura (tipicamente un lucchetto). Talvolta però tale comportamento lo si verifica anche su siti legittimi che implementano male il concetto di connessione sicura, riempiendo erroneamente pagine criptate di links che riportano la connessione in HTTP.

Esistono estensioni come HTTPS Everywhere [6] che aiutano a mitigare tale problema, ma allo stato attuale nessun browser integra sistemi di questo tipo.

Riteniamo pertanto la necessità di massima attenzione anche quando vengono adoperate tecniche o protocolli considerati altamente affidabili e sicuri.

Certificati SSL fasulli Recentissima è la notizia [3,4] resa pubblica dal Certificate vendor Comodo che certificati dei

più diffusi domini quali:

• mail.google.com, • login.live.com (Hotmail et al.) • www.google.com • login.yahoo.com • login.skype.com • addons.mozilla.org



sono stati falsificati. Ciò è stato possibile non per causa di una vulnerabilità intrinseca nei sistema di generazione dei certificati SSL, piuttosto invece a causa di un attacco diretto al vendor di certificati.

Grazie ad un intrusione nei sistemi del vendor è stato possibile generare i certificati che si è voluto , con la firma autentica del vendor stesso.

Tale tipo di attacco ha messo in evidenza problemi nel sistema di revoca dei certificati [7] ma tali approfondimenti esulano dallo scopo principale di questo studio, rimandiamo pertanto gli interessati ad approfondire leggendo i riferimenti bibliografici.

Abbiamo voluto trattare brevemente questi attacchi non tanto per dimostrare l'inefficacia di tali sistemi fine a se stessa, ma allo scopo di dimostrare la necessità di mantenere sempre alta l'attenzione durante tutte le fasi di analisi ed indagine anche quando ci si trova di fronte a sistemi che “si sa” fornire un alto livello di affidabilità.



7. Conclusioni: le “best practices” identificate Il lavoro svolto in laboratorio e le successive sessioni di “brainstorming” a cui ci siamo

sottoposti, ci hanno portato a concludere che l’approccio usato per l’acquisizione è in linea di massima soddisfacente in quanto con poche integrazioni al metodo usato, la realizzazione di un “falso” perfetto risulterebbe estremamente complessa (e costosa) da realizzare.

Va evidenziato a questo proposito che l’elemento centrale intorno a cui viene costruita la prova sta nella corrispondenza fra il filmato della navigazione e il contenuto dell’acquisizione del traffico di rete generato durante la navigazione stessa. Posto quindi che il filmato non sia alterabile (in quanto vediamo dal filmato esterno che questo viene sottoposto a firma digitale subito dopo l’arresto della registrazione) per la realizzazione del falso come abbiamo visto resta solo una possibilità: intervenire sulla rete e sul traffico di rete registrato.

Pertanto le integrazioni individuate hanno lo scopo di far acquisire nel file pcap (contenente la registrazione del traffico) informazioni aggiuntive che consentano a posteriori di “monitorare e validare” la correttezza dell’evoluzione della navigazione in corso.

Va però osservato che nonostante le prescrizioni aggiuntive che il lettore troverà fra poche righe, resta un “margine” pur piccolo di manovra per produrre un falso perfetto.

Senza entrare in dettagli tecnici sulle modalità di realizzazione, questa possibilità risiede nel fatto che teoricamente durante la registrazione della navigazione un sistema posto “dietro le quinte” intercetti il traffico diretto al sito vero in modo da portare al client le risposte prodotte dal sito artefatto (falso). Al termine della registrazione, un programma residente sul PC che esegue le operazioni potrebbe “aggiustare” il file con la cattura del traffico nel lasso di tempo che intercorre fra la chiusura della registrazione e la firma dei file anche se l’acquisizione fosso eseguita comprendendo le attività che andremo ad indicare. Si tratta chiaramente di uno scenario che evoca un caso limite tecnicamente complesso da realizzarsi di cui, per i limiti di tempo imposti per questo studio, non è stato possibile verificarne la concreta realizzabilità.

7.1. Ulteriori attività da aggiungere all’acquisizione Abbiamo visto che il punto più “debole” dei falsi realizzati era riferibile al tracciamento del

percorso di rete che separa la macchina di acquisizione dal server oggetto. Pertanto se sulla macchina di acquisizione venisse fatto girare in background un programma che reiteri una funzione di traceroute destinata al sito da acquisire, avremmo nel file pcap una sorta di “controllo” continuo sul corretto instradamento. Con la stessa logica potremmo andare a tracciare il percorso verso il server NTP usato per la verifica e l’allineamento dell’orologio di sistema e verso il server DNS per dare una individuazione anche a questo server. Per questi due tracciamenti non dovrebbe essere necessaria la reiterazione continua durante le attività. Invece sempre in background si potrebbe anche aggiungere una lettura reiterata del server NTP per avere frammezzata al resto del traffico più pacchetti di risposta contenti il segnale orario di un server esterno così da rendere molto più complessa un’alterazione del pcap che sia rispettosa di questi ulteriori vincoli.

Schematizzando, le prescrizioni aggiuntive risultano essere:

aggiunta di un traceroute ai server DNS e NTP usati; aggiunta di una esecuzione reiterata in background di un traceroute al server oggetto; aggiunta di più interrogazioni NTP eseguite in background durante l’acquisizione del sito.



Naturalmente si potrebbero inserire nel filmato tutte quelle attività che eseguite sul client possano in qualche modo completare la descrizione dell’ambiente operativo e documentarne la “pulizia” (ad esempio la presentazione del contenuto del file hosts e la “pulizia” delle cache del browser) anche se queste assumono un peso minore in relazione al fatto che non siano riscontrabili sul file pcap.

La discussione collegiale ha anche esaminato alcuni strumenti aggiuntivi quali hashbot [14] e httprecon [15]

Hashbot è uno strumento web per acquisire e convalidare, nel corso del tempo, lo status di una singola pagina web. Pur non essendo una terza parte “certificata”, per alcune tipologie di siti è attendibile. Risulta però complicato da usare in presenza di contenuti dinamici.

Il programma httprecon, invece è uno strumento di verifica attraverso interrogazioni standard del “fingerprinting” di un sito consentendo una identificazione ripetibile del sito stesso. Questo potrebbe essere uno strumento da usare per aggiungere ulteriori informazioni all’acquisizione che potrebbero risultare di difficile riproduzione nel tentativo di realizzare un falso.

Infine abbiamo anche discusso (nel capitolo sui siti dinamici) dell’opportunità di integrare la documentazione con l’acquisizione dei sorgenti del sito.

Concludiamo con un’ultima considerazione, teorica, sul file pcap. Poiché, come detto, l’attendibilità della prova è condizionata dall’integrità e dall’originalità di questo file, sarebbe auspicabile disporre di una estensione delle funzioni di acquisizione (nel nostro caso in Wireshark) che siano in grado di produrre un hash MD5 cumulativo dei pacchetti entranti nel pcap. Uno strumento di questo tipo, fornendo un pcap accompagnato da tutti gli hash, ci darebbe una traccia del traffico di rete sicuramente inalterabile. Anche a questo riguardo non abbiamo avuto modo di approfondire l’analisi e di conseguenza non ci è chiaro se la realizzazione di uno strumento di questo tipo risulti tecnicamente improponibile, intrinsecamente inefficace (e quindi inutile) o più semplicemente non sia stata ancora pensata e richiesta dalla comunità dagli operatori dell’informatica forense.



8. Appendice Abbiamo deciso di raccogliere qui in appendice una parte del materiale che è stato oggetto di

discussione durante gli incontri (effettuati in conference call) a seguito delle valutazioni che scaturivano durante lo svolgimento delle attività. Questo materiale è stato riportato a margine in quanto non organico alla esposizione, ci sembrava però utile anche solo ai fini di una “registrazione” conservarlo per poterne far tesoro in future attività.

8.1. Esame statistico delle tracce della seconda acquisizione. Ulteriori analisi dopo la seconda acquisizione sono state effettuate per comprenderne a fondo il

contenuto anche alla “luce” di quegli elementi che messi a confronto con la prima acquisizione sono apparsi strani ad un primo esame con Wireshark.

Per prima cosa si siamo occupati quindi della raccolta dei dati statistici sul traffico registrato nei due file pcap. Abbiamo quindi recuperato, compilato ed installato il programma Tcpdstat [20] suggerito da Real Digital Forensics [13] sia sotto Linux che sotto MacOSX (operazione non banale in quanto in entrambi gli ambienti il compilatore non compila i sorgenti scaricati, segnalando un errore relativo ad una incongruenza di dichiarazione in una variabile). Questi ulteriori sforzi non sono stati premiati da risultati entusiasmanti: le due tracce producono statistiche molto simili, pertanto non sono utili né ad identificare chiaramente un falso né a provare la pretesa autenticità delle acquisizioni.

Riportiamo i risultati (in blu la statistica sulla prima traccia, in verde sulla seconda):

PBG4-di-Marco-4:Desktop.rar Folder mcspada$ /Users/mcspada/src/tcpdstat-uw/tcpdstat Perfezionisti.pcap

DumpFile: Perfezionisti.pcap FileSize: 2.76MB Id: 201103051601 StartTime: Sat Mar 5 16:01:46 2011 EndTime: Sat Mar 5 16:03:35 2011 TotalTime: 108.82 seconds TotalCapSize: 2.63MB CapLen: 1514 bytes # of packets: 8816 (2.63MB) AvgRate: 203.39Kbps stddev:559.00K PeakRate: 5.41Mbps ### IP flow (unique src/dst pair) Information ### # of flows: 82 (avg. 107.51 pkts/flow) Top 10 big flow size (bytes/total in %): 23.1% 20.0% 11.3% 8.4% 6.4% 5.5% 5.0% 3.6% 3.3% 1.3% ### IP address Information ### # of IPv4 addresses: 47 Top 10 bandwidth usage (bytes/total in %): 99.3% 43.5% 11.6% 9.2% 6.9% 5.9% 5.6% 3.9% 3.6% 1.5% ### Packet Size Distribution (including MAC headers) ### <<<< [ 32- 63]: 4571 [ 64- 127]: 1620 [ 128- 255]: 59 [ 256- 511]: 172 [ 512- 1023]: 1526 [ 1024- 2047]: 868 >>>> ### Protocol Breakdown ### <<<<



protocol packets bytes bytes/pkt ------------------------------------------------------------------------ [0] total 8816 (100.00%) 2758064 (100.00%) 312.85 [1] ip 8736 ( 99.09%) 2753336 ( 99.83%) 315.17 [2] tcp 8473 ( 96.11%) 2699693 ( 97.88%) 318.62 [3] http(s) 1286 ( 14.59%) 1362110 ( 49.39%) 1059.18 [3] http(c) 1139 ( 12.92%) 151055 ( 5.48%) 132.62 [3] other 6048 ( 68.60%) 1186528 ( 43.02%) 196.19 [2] udp 256 ( 2.90%) 53237 ( 1.93%) 207.96 [3] dns 168 ( 1.91%) 29325 ( 1.06%) 174.55 [3] netb-ns 16 ( 0.18%) 1520 ( 0.06%) 95.00 [3] netb-se 16 ( 0.18%) 4584 ( 0.17%) 286.50 [3] mcast 44 ( 0.50%) 16112 ( 0.58%) 366.18 [3] other 12 ( 0.14%) 1696 ( 0.06%) 141.33 [2] igmp 7 ( 0.08%) 406 ( 0.01%) 58.00 >>>> PBG4-di-Marco-4:Desktop.rar Folder mcspada$ PBG4-di-Marco-4:Desktop.rar Folder mcspada$ /Users/mcspada/src/tcpdstat-uw/tcpdstat

Perfezionisti.pcap DumpFile: Perfezionisti.pcap FileSize: 1.65MB Id: 201103101931 StartTime: Thu Mar 10 19:31:11 2011 EndTime: Thu Mar 10 19:33:13 2011 TotalTime: 122.00 seconds TotalCapSize: 1.61MB CapLen: 1514 bytes # of packets: 2843 (1.61MB) AvgRate: 134.14Kbps stddev:380.65K PeakRate: 3.41Mbps ### IP flow (unique src/dst pair) Information ### # of flows: 58 (avg. 49.02 pkts/flow) Top 10 big flow size (bytes/total in %): 35.1% 14.6% 10.1% 7.3% 5.6% 4.3% 2.2% 2.0% 2.0% 1.8% ### IP address Information ### # of IPv4 addresses: 32 Top 10 bandwidth usage (bytes/total in %): 100.0% 37.3% 15.3% 11.2% 9.1% 6.3% 4.7% 2.9% 2.6% 1.8% ### Packet Size Distribution (including MAC headers) ### <<<< [ 32- 63]: 1207 [ 64- 127]: 286 [ 128- 255]: 62 [ 256- 511]: 84 [ 512- 1023]: 193 [ 1024- 2047]: 1011 >>>> ### Protocol Breakdown ### <<<< protocol packets bytes bytes/pkt ------------------------------------------------------------------------ [0] total 2843 (100.00%) 1686837 (100.00%) 593.33 [1] ip 2761 ( 97.12%) 1681307 ( 99.67%) 608.95 [2] tcp 2595 ( 91.28%) 1663464 ( 98.61%) 641.03 [3] http(s) 1402 ( 49.31%) 1490365 ( 88.35%) 1063.03 [3] http(c) 1193 ( 41.96%) 173099 ( 10.26%) 145.10 [2] udp 164 ( 5.77%) 17695 ( 1.05%) 107.90 [3] dns 154 ( 5.42%) 16618 ( 0.99%) 107.91 [3] ntp 2 ( 0.07%) 180 ( 0.01%) 90.00 [3] netb-ns 6 ( 0.21%) 552 ( 0.03%) 92.00 [3] netb-se 1 ( 0.04%) 243 ( 0.01%) 243.00 [3] other 1 ( 0.04%) 102 ( 0.01%) 102.00



[2] icmp 2 ( 0.07%) 148 ( 0.01%) 74.00 >>>> PBG4-di-Marco-4:Desktop.rar Folder mcspada$ ls perfezionisti.pcap video.avi PBG4-di-Marco-4:Desktop.rar Folder mcspada$ /Users/mcspada/src/tcpdstat-uw/tcpdstat

perfezionisti.pcap DumpFile: perfezionisti.pcap FileSize: 1.65MB Id: 201103101931 StartTime: Thu Mar 10 19:31:11 2011 EndTime: Thu Mar 10 19:33:13 2011 TotalTime: 122.00 seconds TotalCapSize: 1.61MB CapLen: 1514 bytes # of packets: 2843 (1.61MB) AvgRate: 134.14Kbps stddev:380.65K PeakRate: 3.41Mbps ### IP flow (unique src/dst pair) Information ### # of flows: 58 (avg. 49.02 pkts/flow) Top 10 big flow size (bytes/total in %): 35.1% 14.6% 10.1% 7.3% 5.6% 4.3% 2.2% 2.0% 2.0% 1.8% ### IP address Information ### # of IPv4 addresses: 32 Top 10 bandwidth usage (bytes/total in %): 100.0% 37.3% 15.3% 11.2% 9.1% 6.3% 4.7% 2.9% 2.6% 1.8% ### Packet Size Distribution (including MAC headers) ### <<<< [ 32- 63]: 1207 [ 64- 127]: 286 [ 128- 255]: 62 [ 256- 511]: 84 [ 512- 1023]: 193 [ 1024- 2047]: 1011 >>>> ### Protocol Breakdown ### <<<< protocol packets bytes bytes/pkt ------------------------------------------------------------------------ [0] total 2843 (100.00%) 1686837 (100.00%) 593.33 [1] ip 2761 ( 97.12%) 1681307 ( 99.67%) 608.95 [2] tcp 2595 ( 91.28%) 1663464 ( 98.61%) 641.03 [3] http(s) 1402 ( 49.31%) 1490365 ( 88.35%) 1063.03 [3] http(c) 1193 ( 41.96%) 173099 ( 10.26%) 145.10 [2] udp 164 ( 5.77%) 17695 ( 1.05%) 107.90 [3] dns 154 ( 5.42%) 16618 ( 0.99%) 107.91 [3] ntp 2 ( 0.07%) 180 ( 0.01%) 90.00 [3] netb-ns 6 ( 0.21%) 552 ( 0.03%) 92.00 [3] netb-se 1 ( 0.04%) 243 ( 0.01%) 243.00 [3] other 1 ( 0.04%) 102 ( 0.01%) 102.00 [2] icmp 2 ( 0.07%) 148 ( 0.01%) 74.00 >>>> PBG4-di-Marco-4:Desktop.rar Folder mcspada$

Appare strano, ad un primo colpo d’occhio, di trovare più pacchetti NON IP nella seconda

traccia (82) rispetto alla prima (80) proprio perché gli ARP sono molto inferiori nella seconda traccia.

Vediamo quindi questi pacchetti con: // totale pacchetti non IP:



PBG4-di-Marco-4:Desktop.rar Folder mcspada$ tcpdump -n -r perfezionisti.pcap -s 1515 ! ip | wc –l reading from file perfezionisti.pcap, link-type EN10MB (Ethernet) 80 // totale pacchetti IP: PBG4-di-Marco-4:Desktop.rar Folder mcspada$ tcpdump -n -r perfezionisti.pcap -s 1515 arp | wc -l reading from file perfezionisti.pcap, link-type EN10MB (Ethernet) 80 // totale pacchetti non IP: PBG4-di-Marco-4:Desktop.rar Folder mcspada$ tcpdump -n -r perfezionisti.pcap -s 1515 ! ip | wc –l

reading from file perfezionisti.pcap, link-type EN10MB (Ethernet) 82 PBG4-di-Marco-4:Desktop.rar Folder mcspada$ tcpdump -n -r perfezionisti.pcap -s 1515 arp | wc -l reading from file perfezionisti.pcap, link-type EN10MB (Ethernet) 6 PBG4-di-Marco-4:Desktop.rar Folder mcspada$ tcpdump -n -r perfezionisti.pcap -s 1515 stp | wc -l reading from file perfezionisti.pcap, link-type EN10MB (Ethernet) 62 // questi sono i CDP emessi dal Cisco: PBG4-di-Marco-4:Desktop.rar Folder mcspada$ tcpdump -n -r perfezionisti.pcap -s 1515 ether host\ 01:00:0c:cc:cc:cc | wc –l reading from file perfezionisti.pcap, link-type EN10MB (Ethernet) 2 // questi sono pacchetti di CTP “configuration testing protocol” emessi dal Cisco: PBG4-di-Marco-4:Desktop.rar Folder mcspada$ tcpdump -n -r perfezionisti.pcap -s 1515 ether proto

0x9000 | wc –l reading from file perfezionisti.pcap, link-type EN10MB (Ethernet) 12 da cui si può ricavare che nella seconda traccia abbiamo solo 6 pacchetti ARP (contro gli 80

dell’altra). Gli altri 76 pacchetti sono dovuti allo switch Cisco usato per la rete “privata” che aveva attivi i protocolli STP, CDP e CTP.

8.2. Indagine sui pacchetti “errati” della seconda traccia In una e-mail riepilogativa ci si interrogava sulle anomalie riscontrabili nella traccia pcap della

seconda acquisizione, anomalie che non risultavano in una terza acquisizione fatta da Paolo direttamente sul sito originale www.perfezionisti.it. Ecco un estratto della mail:

«…Nella discussione, Davide ha evidenziato che lo strumento di analisi da noi usato (il programma Wireshark) segnala un alto tasso di errori nei pacchetti della seconda acquisizione. Sempre riguardo a questa acquisizione, io avevo sottolineato in precedenza che una configurazione “frettolosa” dello switch impiegato aveva introdotto dei pacchetti non riguardanti le attività, ma che a mio avviso questi non avevano alcuna incidenza sullʼanalisi della prova: secondo me, appaiono come “rumore di fondo”. Davide però si domandava se questo elemento “di disturbo” non potesse in qualche modo essere collegato con gli errori osservati nella seconda traccia mentre Paolo si domandava se questi errori non possano invece essere un indizio della architettura di rete usata per mascherare il tarocco. Ho fatto quindi unʼanalisi dettagliata dei pacchetti contenti errori della seconda traccia... e questo è il risultato che propongo …»

Applicando in Wireshark sulla seconda traccia i seguenti due filtri:

• (ip.checksum != 0x00) and (ip.checksum_bad==true) -> nessun pacchetto • (ip.src_host != "192.168.1.20") and (ip.checksum == 0x00) -> nessun pacchetto

risulta evidente che tutti i pacchetti “errati” hanno checksum 0x00 e sono uscenti dal PC di acquisizione (IP 192.168.1.20)



Inoltre con queste interrogazioni:

• (ip.checksum == 0x00) and not tcp and not udp • not tcp and not udp and not icmp

si vede che abbiamo due soli pacchetti errati con ICMP mentre gli altri errori coinvolgono i protocolli TCP e UDP. Nessuna sorpresa, gli altri protocolli presenti (seconda interrogazione) sono di tipo CDP, STP, ARP e CTP, siccome si tratta di pacchetti L2 (non IP) evidentemente non hanno un checksum dello header IP.

Con queste interrogazioni:

• (ip.checksum != 0x00) and tcp • (ip.checksum != 0x00) and tcp and not tcp.analysis.retransmission (togliendo le

ritrasmissioni ne resta uno solo “segment lost”) • (ip.checksum != 0x00) and tcp and not tcp.analysis.retransmission and

ip.src_host==192.168.1.20

vediamo che in TCP oltre ai pacchetti con checksum errato abbiamo anche dei pacchetti con altri errori, in particolare tranne uno sono errori che hanno richiesto la ritrasmissione del pacchetto. Comunque sono tutti entranti!

Con questa interrogazione:

• (ip.checksum != 0x00) and udp

vediamo (sono pochi non servono altre interrogazioni) che:

1. gli unici UDP con checksum diverso da 0 in uscita (source == 192.168.1.20) sono quelli relativi ai protocolli Microsoft

2. tutti gli altri sono risposte dal dns (8.8.8.8) e dal server NTP La RFC 768 prevede che per i datagram UDP il calcolo del checksum è facoltativo e qualora sia assente questo deve essere impostato a 0x00 (N.B. il conteggio del checksum viene effettuato in complemento ad 1 pertanto in questa rappresentazione abbiamo due simboli per il numero zero, la RFC chiede espressamente che lo zero usato sia il 0x00 e non il 0xFF). Quindi possiamo concludere che i pacchetti UDP uscenti dal PC di Paolo sono corretti a dispetto di quanto indicato da Wireshark

Con queste interrogazioni:

• (ip.checksum == 0x00) and icmp • (ip.checksum != 0x00) and icmp • icmp

appare evidente che in tutta la traccia ci sono solo due pacchetti PING, si tratta di due richieste uscenti dal PC di Paolo, sono dirette ad indirizzi privati (10.220.21.117 e 10.220.21.118) e vanno alla scheda ethernet



del default gateway (ed è cosa buona e giusta!) e hanno entrambi il checksum a 0x00.

E infine con questa interrogazione:

• (ip.checksum != 0x00) and ip.src_host==192.168.1.20

scopriamo che tutti i pacchetti usciti dal PC di Paolo ad eccezione degli otto UDP emessi in broadcast (per la precisione 7 broadcast di livello 3 più 1 broadcast di livello 2) sono senza checksum (!!)

A questo punto mi sono chiesto come mai nella terza acquisizione non compaiono errori ? Se andiamo a guardare i MacAddress delle macchine che hanno fatto le acquisizioni scopriamo che sono differenti:

• 00:16:d3:c2:7f:8c (mac address della scheda Wistron_C2 usata per la seconda acquisizione) • 00:0C:29:db:63:28 (mac address della macchina Vmware usata per la terza acquisizione (quella

reale) Quindi Paolo non ha usato lo stesso hardware nelle due situazioni e questo per me può essere sufficiente a spiegare la differenza fra le due acquisizioni. Provo ad abbozzare una spiegazione (che almeno in linea teorica sta in piedi) per giustificare il comportamento del PC usato nella seconda e per motivare il fatto che funzioni pur facendo degli errori:

• il driver della scheda Wistron_C2 (o il sistema operativo Windows usato su quel PC, dato che questi cooperano) si “risparmia” il calcolo del checksum mettendolo a 0x00 quando i pacchetti devono “uscire” dalla rete LAN (quando devono stare in rete non può permettersi questo furto).

• il router riceve il pacchetto senza checksum, “se ne frega” e siccome lo deve inoltrare su unʼaltra interfaccia ed è pertanto costretto a smontarlo e rimontarlo dallʼaltra parte, ne ricalcola il checksum dallʼaltro lato e lo “aggiusta” (in questo modo dopo il primo hop le cose sono tutte a posto)...



9. Bibliografia [1] Davide D'Agostino, Mario Pascucci. Analisi siti web compromessi: aspetti giuridici ed

investigativi. IISFA memberbook 2009 - Digital Forensics.

[2] Chris Sanders. SSL Hijacking - http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part4.html - 9/6/2010.

[3] F-Secure, Rogue SSL Certificates ("Case Comodogate"). http://www.f-secure.com/weblog/archives/00002128.html – 23/3/2011.

[4] TOR, Detecting Certificate Authority compromises and web browser collusion - https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion – 22/03/2011.

[5] SSLstrip - http://www.thoughtcrime.org/software/sslstrip/

[6] Electronic Frontier Foundation (EFF) - HTTPS everywhere - https://www.eff.org/https-everywhere

[7] Revocation doesn't work - http://www.imperialviolet.org/2011/03/18/revocation.html

[8] DOMINIONI O., In tema di nuova prova scientifica in Diritto penale e processo (editoriale), 2001, fasc. 9, 1063.

[9] DOMINIONI O., La prova penale scientifica – Gli strumenti scientifico-tecnici nuovi o controversi e di elevata specializzazione, Giuffrè, Milano, 2005.

[10] DAUBERT V. Merrel Dow Pharmaceutical, Inc., 113S. Ct.2786, 1993.

[11] Frye v. United States 293F 1013,1014, D.C. Cir.1923.

[12] Default Time To Live (TTL) values - http://www.binbert.com/blog/2009/12/default-time-to-live-ttl-values/ - cap 5.2 – 8/9/2009.

[13] K.J. Jones, R. Bejtlich e C.W. Rose, Real Digital Forensics, Addison-Wesley Professional, 2005 --cap 5.3

[14] Gianni Amato, Davide Baglieri, HashBOT - https://www.hashbot.com/

[15] Marc Ruef - httprecon project – Advanced Web Server Fingerprinting http://www.computec.ch/projekte/httprecon/

[16] http://wiki.wireshark.org/FileFormatReference/libpcap

[17] http://en.wikipedia.org/wiki/Pcap

[18] http://www.wireshark.org/

[19] http://www.tcpdump.org/

[20] http://staff.washington.edu/dittrich/talks/core02/tools/tools.html

Network forensics: un approccio laterale

Internet

Transcript of Network forensics: un approccio laterale