Computer Forensics: sincronizzate gli orologi!

-
"Sincronizzate gli orologi", diceva qualcuno...

Determinare il tempo-macchina e metterlo in relazione con il tempo reale è di fondamentale importanza per qualsiasi tipo di indagine o investigazione di computer forensics. Capire se un messaggio di posta è stato scritto in un momento piuttosto che in un altro (non inviato, scritto), potrebbe determinare importanti considerazioni. Stabilire che le date presenti in un file system sono relative ad un clock con un "delta" rispetto al tempo reale, potrebbe fare la differenza in un'analisi forense.  

Insomma in qualsiasi tipologia di indagine vi troviate, stabilire il delta e l'evoluzione dei cambiamenti del tempo macchina rispetto al tempo reale è di fondamentale importanza. 

Sul come fare ci sono diversi orientamenti ed il metodo cambia a seconda che l'analisi sia di tipo "post-mortem" o "live":

Analisi Post-Mortem
  • disconnettere tutti i supporti di massa e riavviare la macchina entrando nel BIOS di sistema;
  • riavviare il sistema con una linux live forense (attenzione al mount dei dischi in sola lettura)
Analisi Live
  • accedere al sistema e controllare la data!
Dopo aver "appurato" quale sia il tempo-macchina c'è la necessità di certificare tale dato. Qui la cosa si fa più fumosa. Si spazia dal far testimoniare il caro vecchio maresciallo al nostro fianco, verbalizzando la cosa, al predisporre una procedura automatica che contatti un server di marca temporale e  certifichi il delta,  sino all'invio di una mail di posta certificata che attesti tale dato.
Nei casi in cui ci appoggiassimo ad una procedura informatica, ricordiamoci di certificarne il "trust"  allegando il codice sorgente.

In conclusione non trascuriamo questo importante fattore per l'analisi forense: la differenza tra il tempo-macchina e il tempo reale. Altrimenti tutto il lavoro sarà, quasi sicuramente, inutile!


Commenti

Posta un commento

Post popolari in questo blog

Exploit: icsploit o espluà?

-
Immagine
Non ce la faccio più! Continuo a sentir pronunciare " exploit ", nel senso di " sfruttamento di una vulnerabilità informatica ", in francese: espluà ! E' quasi un pugno nello stomaco! Sebbene il termine inglese derivi dal francese, quando si usa nel contesto della sicurezza informatica, la pronuncia è in inglese, ovvero " ecsploit "o " icsploit " (a seconda che sia un sostantivo o un verbo). E poi visto che la consuetudine è quella di usare termini inglesi nel contesto informatico, e per amore di un unico e non ambiguo vocabolario, usiamo i termini inglesi quando ci riferiamo a cose ben specifiche  e relative all'informatica. Per essere estremamente chiari, se dobbiamo parlare di "SQL Injection" non è che possiamo tradurla come "inoculazione di sequenze maliziose in una istruzione del linguaggio SQL". Non si capisce nulla! Altrimenti torniamo al caro professore che insisteva nel tradurre "Computer" in "...
Continua a leggere

Rappresentazione 3D di Worm, spam, ...

-
Immagine
Che qualcuno avesse rappresentato in forma artistica Malware e Spam mi mancava proprio! Interessante esperimento con delle immagini a dir poco inquietanti! Questo è un IRCBOT: (copyright © 2002-2008 Alex Dragulescu, All Rights Reserved) E qui invece uno po' di SPAM: (copyright © 2002-2008 Alex Dragulescu, All Rights Reserved) L'autore ovviamente è un artista pluridecorato (certo anche il cognome è abbastanza inquietante) e io stavo giusto cercando dei quadri per il mio studiolo ;-)
Continua a leggere

Code review e HTTPS

-
Ha senso fare la revisione di sicurezza di un codice sorgente quando la trasmissione dei dati avviene in HTTPS? In una presentazione sulla "revisione di sicurezza di codice sorgente" ho sentito tale affermazione: Se la trasmissione con la Web App avviene in HTTPS, il tampering dei dati è impossibile e quindi la revisione di sicurezza del codice interessato da tali dati non è necessaria(*) Falso! Facciamo una piccola premessa: prima di effettuare la revisione di un codice sorgente bisogna identificare le possibili minacce a cui sarà sottoposta l'applicazione (ovvero le tipologie di attori maliziosi che interagiranno con essa) e modellare i "casi di abuso" (ovvero i casi di uso dell'applicazione in cui gli attori sono le minacce) le cui finalità sono quelle di sovvertire l'applicazione. Ipotizziamo ora che in un caso di abuso i dati in input all'applicazione viaggino in HTTPS. Il codice sorgente che è responsabile dell'elaborazione di tali dati ...
Continua a leggere