Leonardo Musumeci

Il post seguente è stato tradotto, previa autorizzazione, dal blog SANS Computer Forensics

Recentemente, i cookie di flash sono stati un argomento di notevole interesse, grazie al rilascio di un ottimo paper dal titolo Cookie di flash e privacy. I cookie di flash, o local shared objects nel linguaggio Macromedia, sono un ottimo esempio di forensic artifact che esiste da molto tempo; in pratica ignorato fino a quando non si è deciso di renderlo noto. Quando vedo una nuova ricerca che riguarda problematici controlli della privacy, immediatamente estraggo il mio palmare, perché so che troverò artifact di grande valore che potranno aiutarmi nel corso delle mie indagini relative alla forensics.

Prima di tutto alcuni principi fondamentali:

• Macromedia Flash è diventato onnipresente sul web, grazie a funzionalità come lo streaming video ed altre peculiarità per il “cliente ricco”. Molti dei siti più popolari sul web sono dipendenti da Flash e quindi un’alta percentuale di utenti Internet ha installato il plug-in per Flash.
• Lo standard Flash incorpora i local shared objects (LSO), che consentono ai dati (come le preferenze) di essere conservati nell’istanza locale di Flash, sulla macchina dell’utente.
• Gli LSO vengono memorizzati come singoli file con estensione .SOL.  Per impostazione predefinita sono meno di 100 KB e non hanno scadenza (a differenza dei tradizionali cookie HTTP).
• Ho trovato i file .SOL in due posizioni, nel sistema locale: %user profile%\Application Data\Macromedia\Flash Player e %user profile%\Application Data\Macromedia\Flash Player\# SharedObjects\profile \ in un sistema XP).Per l’analisi di Vista, sarà necessario cercare nella cartella roaming all’interno di %user profile%\
• Gli LSO non sono browser based, quindi attualmente, non esiste un modo semplice per l’utente medio di rimuoverli (cancellando semplicemente i file si raggiunge lo scopo, ma l’utente deve sapere dove si trovano). Questo rende gli LSO molto difficili da eliminare sul sistema locale.

Analisi

Per i nostri scopi, il termine cookie di flash è adatto per definire gli LSO, perché fornisce informazioni molto simili a quelle che troviamo nei tradizionali cookie HTTP. Chi ha frequentato il corso SANS SEC 408 Computer Forensic Essentials ricorda che i cookie HTTP possono fornire le seguenti informazioni:

I siti web visitati

Macromedia Flash richiede che gli LSO siano conservati gerarchicamente, per dominio. In questo modo è possibile far rispettare la regola che ogni dominio può memorizzare fino a 100K sul sistema locale. Dal nostro punto di vista, questo ci fornisce uno strumento molto utile per esaminare velocemente i siti visitati.

Figura 1: Listato directory che mostra i domini LSO

Anche gli annunci pubblicitari basati su Flash hanno la possibilità di salvare gli LSO. Questo è importante, perché, in alcuni casi, si può necessariamente concludere che l’intento dell’utente fosse quello di accedere al dominio. L’origine degli LSO è spesso evidente (vedi figura 2). Ma ulteriori test o artifact addizionali possono essere necessari per giungere a conclusioni definitive.

Figura 2: Local Shared Object memorizzato da una pubblicità flash

Account utente locale che ha visitato il sito

I file .SOL si trovano all’interno della cartella %user profile% , che indica l’account autenticato nel momento in cui l’LSO è stato salvato.

La prima e l’ultima visita al sito

Dal momento che i file .SOL vengono salvati singolarmente, abbiamo un bel set di timestamp del file system da utilizzare. Su Windows XP (che ha l’Access time stamping abilitato per default), si può utilizzare l’Access Time per sapere quando l’LSO è stato letto l’ultima volta. Questo può dirci, potenzialmente, quando il sito è stato visitato per l’ultima volta; ma si deve prestare attenzione, visto che non sono a conoscenza di alcuna norma che richieda un sito di distribuzione per leggere gli LSO. È certamente nel loro interesse e i miei test sembrano confermarlo, ma se il sito non legge l’LSO per qualche ragione, l’access time non sarà aggiornato.

Il creation time del file .SOL, potenzialmente, può comunicare quando il sito è stato visitato per la prima volta. Ancora una volta, però, non è possibile stabilire con certezza che l’LSO sia stato creato durante la prima visita al sito; quindi è difficile essere definitivi. Per analizzare meglio tutto questo, si dovrebbe considerare “la prima visita nota al sito”. Altri artifact del sistema, possono essere in grado di confermare questa data, o indicare una visita precedente.

Così, osservando di nuovo la figura 1, è possibile vedere che la prima visita nota a mg3.mail.yahoo.com è stata l’ 11/27/2008 all’ 1:38 e l’ultima visita nota l’ 8/17/2009 alle 5:27 (local machine time).

Dati memorizzati dal sito

Flash tenta semplicemente di offuscare i dati all’interno di ogni LSO, controllando il formato e forzando una serializzazione binaria dei dati memorizzati. Detto questo, se trovate un file rilevante, non trascurate questa area di dati. Ho trovato informazioni interessanti, come text-based location information memorizzate da un sito web meteo.

Strumenti

Sebbene non sia raccomandato come forensics tool (in primo luogo, perché richiede l’installazione/esecuzione su un sistema live), l’estensione per Firefox, Better Privacy, è un ottimo strumento per identificare (e rimuovere) gli LSO sul sistema locale. Uno dei modi migliori per conoscere i forensics artifact è l’analisi su un sistema con un comportamento noto (cioè il vostro sistema). Il plug-in Better Privacy vi permette di esaminare (e gestire) gli LSO su un sistema live.

Figura 3: Better Privacy Firefox plug-in Screenshot

Questo è solo un primo rapido esame relativo ai Cookie di Flash, esorto i nostri lettori ad inviare eventuali link o informazioni supplementari nei commenti del blog.

Ciad Tilbury, GCFA, ha trascorso oltre dieci anni nell’ambito investigativo relativamente al crimine informatico: dal computer hacking allo spionaggio, fino a casi di frode per svariati milioni di dollari. Attualmente insegna al SEC408 Computer Forensic Essentials e SEC508 Computer Forensics, Investigations, and Response per il SANS Institute.

Fonte: Flash Cookie Forensics

Il post seguente è stato tradotto, previa autorizzazione, dal blog SANS Computer Forensics

Durante un incidente informatico in un’azienda protetta da antimalware, Host IPS e Windows GPO; atti ad impedire l’esecuzione di materiale pericoloso, abbiamo notato qualcosa di sospetto nella rete e sembrava venisse utilizzato per far trapelare informazioni. Cosa dobbiamo fare per avere indizi su ciò che sta accadendo?
La memory forensics ci può aiutare. Effettuiamo una prima immagine della memoria utilizzando il software MDD di Mantech (http://www.mantech.com/msma/mdd.asp):

Dopo aver effettuato l’immagine, useremo uno strumento che possa essere in grado di sondare in maniera più approfondita ciò che contiene, in modo da ottenere le prove utili per il caso. Si userà Volatility framework (https://www.volatilesystems.com/default/volatilità). Un software open source in Python che è in grado di analizzare le immagini della memoria di Windows XP e raccogliere informazioni: come i socket creati, la lista dei processi, la lista delle DLL caricate, le connessioni attive, l’indirizzo di memoria, i file aperti e le chiavi di registro per ogni processo. Ecco come si usa: digitiamo python volatility :

src=”http://manuel.santander.name/sans/volatility_usage.jpg” alt=”" />

Otteremo la lista dei processi, ora cerchiamo di trovare qualcosa di strano. Digitiamo python volatility pslist memory.dmp-f :

Abbiamo trovato qualcosa. PID 2316 sembra essere un netcat. Vediamo se c’è qualche trasferimento in corso, grazie ad un controllo delle connessioni attive sull’ host, digitiamo python volatility connections -f memory.dmp :

Nessun trasferimento in corso. Netcat potrebbe essere in ascolto? Verifichiamo ogni socket creato digitando python volatility sockscan memory.dmp-f :

Abbiamo trovato qualcosa! Netcat sembra essere in ascolto sulla porta TCP 1234 (Protocollo 6).

È possibile verificare i numeri di protocollo qui .

Dove sta scrivendo? Proviamo ad aprire i file digitando python volatility file memory.dmp-f :

Sembra essere in attesa di un file di Excel. Proporrò altri casi nei prossimi post.

Manuel Humberto Peláez Santander è Chief Information Security Officer dell’ Empresas públicas Medellín ESP .

Possiede GCFA, GCIA, GNET, GCFW, GCIH e GSEC.

Fonte : Memory forensics: A practical example

Il post seguente è stato tradotto, previa autorizzazione, dal blog SANS Computer Forensics

Le informazioni ricavate dai metadati dei documenti possono essere una valida fonte di informazioni per gli investigatori ed il loro valore è indiscusso. I documenti creati utilizzando Microsoft Office compaiono spesso nel corso delle indagini. Parecchi script e software permettono di leggere il formato proprietario dei documenti creati utilizzando Office 2003 e versioni precedenti, di conseguenza non c’è altro da aggiungere per quanto riguarda questi strumenti. Ma non ci sono molti software che possano leggere i metadati nel nuovo formato che utilizza Office 2007 , OpenXML. Così ho deciso di esaminarlo un po’ più accuratamente.

Microsoft ha già pubblicato un documento che descrive abbastanza bene la struttura di OpenXML [ 1 ]. In sostanza un documento creato in OpenXML, è un file compresso con il noto formato ZIP, in modo che possa essere facilmente aperto con qualsiasi software che faccia uso di tale formato (ad esempio, modificando il nome del documento da document.docx a document.zip e utilizzando un software che legga il formato ZIP).

All’interno del file ZIP sono presenti alcune strutture predefinite di file, generalmente file XML che descrivono il documento ed il suo contenuto, facilmente leggibili tramite librerie standard disponibili nei linguaggi di scripting come Perl.

Secondo quanto detto da Microsoft, all’interno dell’archivio ZIP viene creata una cartella chiamata “_rels”. Questa cartella contiene un file chiamato “. Rels” che definisce le relazioni all’interno dell’archivio. Questo dovrebbe essere il primo luogo utile per effettuare il parse del documento. All’interno del file .rels si trovano i tag che definiscono le relazioni del documento:

<Relationship Id="someID" Type="relationshipType" Target="targetPart"/>

I metadati sono memorizzati in file che contengono un tipo di “proprietà * “, generalmente nota come “proprietà core” e “proprietà estesa”. Questi file sono in genere memorizzati secondo il percorso seguente:

• DocProps / core.xml
• DocProps / app.xml
  
  Questi file contengono, quindi, le informazioni effettive dei metadati: chi ha creato il documento, ultimo file salvato, ecc. Per essere in grado di visualizzare i metadati di tali informazioni è necessario estrarre ed effettuare il parse dei documenti.

  A questo proposito ho creato uno script read_open_xml.pl , che effettua il parse dei contenuti del file .rels per individuare i metadati e successivamente estrarli e stamparli sullo schermo. Ecco un esempio di come possa essere utilizzato:

  ./read_open_xml.pl test.docx

  ==========================================================================
   cmd line: ./read_open_xml.pl test.docx
  ==========================================================================
  
  Document name: test.docx
  Date: Tue Jun  9 16:51:23 GMT 2009
  
  --------------------------------------------------------------------------
  File Metadata
  --------------------------------------------------------------------------
   title = my company template
   subject = Document template
   creator = Kristinn Gudjonsson
   keywords = template, word
   description =
   lastModifiedBy = Kristinn Gudjonsson
   revision = 3
   lastPrinted = 2008-08-15T10:14:00Z
   created = 2008-08-15T10:14:00Z
   modified = 2008-08-15T10:14:00Z
   category = template
  --------------------------------------------------------------------------
  Application Metadata
  --------------------------------------------------------------------------
   Template = my_template.dot
   TotalTime = 0
   Pages = 2
   Words = 159
   Characters = 908
   Application = Microsoft Word 12.1.2
   DocSecurity = 0
   Lines = 7
   Paragraphs = 1
   ScaleCrop = false
   Manager = Some dude
   Company = My Company
   LinksUpToDate = false
   CharactersWithSpaces = 1115
   SharedDoc = false
   HyperlinksChanged = false
   AppVersion = 12.0258
  
  copyright, Kristinn Gudjonsson, 2009

  Lo script legge anche la codifica dei caratteri dei documenti XML e ne codifica l’output.

  Lo script è stato creato per essere usato con Linux, grazie ad alcune modifiche che ho apportato, dovrebbe funzionare anche con sistemi operativi Windows (è stato testato su Win XP SP3 con ActivePerl 5,10).

  È possibile scaricare la versione per Windows qui .

  La versione per Windows e per Linux non sono state ancora testate, quindi potrebbero essere ancora instabili ( alcune informazioni per l’installazione sono contenute all’interno dello script stesso)

  Fonte : Office 2007 Metadata

Questo post è stato tradotto, previa autorizzazione, di SANS Computer forensics

I dispositivi mobili odierni sono un’arma a doppio taglio: creano nuovi rischi per la sicurezza ma allo stesso tempo forniscono preziose fonti di prova agli investigatori della digital forensics. Le capacità sempre crescenti di tali dispositivi, li rendono sempre più simili ai personal computer, che ci accompagnano durante la nostra esplorazione del mondo. Gli investigatori possono utilizzare le informazioni memorizzate per ricostruire i nostri movimenti, le comunicazioni e altri dettagli personali.

Se si ha la necessità di estrarre informazioni da telefoni cellulari, smartphone e altri dispositivi mobili, o se si è preoccupati per la sicurezza dei propri dati; in questo post sono presenti alcune informazioni importanti.

Bypassare i codici di sicurezza : gli investigatori della digital forensics sono in grado di estrarre il codice di sicurezza di alcuni dispositivi mobili protetti, utilizzando strumenti specializzati.
La schermata seguente mostra il codice di sicurezza “12345″ recuperato da un Nokia 6230 utilizzando .XRY (l’identificativo dell’abbonato è stato rimosso).

Essere in grado di aggirare i meccanismi di sicurezza, consente agli investigatori di acquisire i dati tramite il software forense.

Safe SIM Card: Inserire una carta SIM in maniera errata in un telefono cellulare, distrugge alcuni dati utili in memoria.
Per evitare simili problemi, gli investigatori sono in grado di creare Safe SIM Card, progettate per l’analisi forense.

Acquisizione Live : La rimozione della batteria prima di eseguire un’acquisizione forense, può distruggere prove preziose.
In alcuni casi, per garantire che tutte le prove disponibili siano preservate, l’investigatore lascerà il dispositivo portatile acceso fino a quando l’acquisizione forense non potrà essere effettuata; prendendo le precauzioni necessarie, atte ad impedire che i dati possano essere modificati.

Trusted Time Source: anche se il clock sul dispositivo non è impostato correttamente, alcuni time stamp possono essere corretti; visto che sono generati dal sistema sul core network. Ad esempio, il timestamp di un messaggio SMS ricevuto, è stabilito dallo Short Message Service Center, non dal telefono cellulare.

Localizzazione degli spostamenti : Alcuni dispositivi memorizzano le informazioni basate sulla posizione geografica, associate ad alcuni mezzi di comunicazione ed azioni, sul dispositivo stesso.
Gli investigatori possono recuperare tali informazioni per rilevarne la posizione in un determinato momento. Ad esempio, la seguente schermata mostra i metadati exif estratti utilizzando JPEGsnoop da una fotografia digitale scattata utilizzando un dispositivo mobile G1. Questi metadati includono la data e l’ora della foto e le coordinate GPS della località (i dettagli relativi allla località sono stati eliminati ).

Recupero dei dati eliminati : Quando l’utente cancella il log delle chiamate, può essere recuperabile con relativa facilità. Quindi anche se i log delle chiamate non vengono visualizzati, gli investigatori potrebbero essere in grado di visualizzare i dettagli delle chiamate effettuate, ricevute e perse, utilizzando strumenti facilmente reperibili.

Getting Physical : Gli investigatori possono recuperare grandi quantità di dati cancellati da diversi dispositivi mobili, tramite l’acquisizione e l’analisi dell’intero contenuto della memoria. Questa schermata mostra l’acquisizione della memoria fisica di un Nokia 6610, tramite l’applicazione di Sarasoft, Twister flasher box.

Per imparare queste ed altre tecniche relative alla forensics dei dispositivi mobili, iscrivetevi al SEC563 Mobile Device forensics di Baltimora, 27-31 luglio ( Iscrivetevi qui ).

Si tratta di un corso tecnico intensivo, con numerosi esercizi pratici per familiarizzare con il funzionamento interno dei vari dispositivi mobili e mostrare vantaggi e limiti dei vari approcci e strumenti. Non solo dimostreremo lo stato dell’arte per quanto riguarda gli strumenti e le tecniche della mobile forensics; ma sveleremo lentamente i vari livelli delle prove digitali per mostrare ciò che accade dietro le quinte. In questo modo, otterremo una conoscenza più approfondita delle informazioni necessarie alle indagini.

Eoghan Casey è founding partner di cmdLabs (http://www.cmdlabs.com/), autore del libro “Digital Evidence and Computer Crime” e coautore di “Malware Forensics”.
Ha partecipato ad una vasta gamma di indagini digitali, inclusi casi di intrusioni di rete, frode, crimini violenti, furto d’identità ed attività criminali on-line. Ha testimoniato in materia civile e penale, ha presentato relazioni tecniche e documenti prodotti in giudizio, relativamente alla computer forensics ed in casi di criminalità informatica.

Fonte: Top 7 ways investigators catch criminals using Mobile Device Forensics