Le chiavi di registry e gli hive file di interesse

In questo articolo non viene fornita alcuna spiegazione generica sui registry di Windows, nè sul formato delle informazioni memorizzate, ivi compreso il LastWriteTime, nè sugli hive file, perché in Internet si trova veramente abbondante materiale al riguardo, anche in italiano. Tali concetti si riterranno pertanto nel seguito già noti al lettore.

Per lo stesso motivo la presente analisi non tiene conto delle differenti caratteristiche dei registry delle diverse versioni di Windows. Per semplicità quanto segue assume che il sistema in esame sia basato su Windows Xp. Il “porting” di quanto detto ad altre versioni di Windows dovrebbe risultare al lettore abbastanza semplice.

Le chiavi dei registry dove si trovano informazioni interessanti ai fini della presente analisi sono:

1. HKLM\SYSTEM\MountedDevices, che contiene:
• il  ParentIdPrefix del dispositivo USB,
• l’identificativo del Volume associato al dispositivo USB, l’ultima volta che è stato inserito
2. HKU\SID\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume, che contiene:
• L’elenco dei Volumi montati con l’account dell’utente, con la data di ultima installazione
3. HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR, che contiene:
• il nome/marca del dispositivo USB,
• il suo Serial Number (laddove presente, in quanto non tutti dispositivi lo forniscono) verificabile con appositi tool quali UVCView
• il suo “ParentIdPrefix” (corrispondente a quello reperibile nella prima chiave di cui sopra)
• la data di primo inserimento del dispositivo nel PC
• la data di ultimo inserimento del dispositivo nel PC

Incrociando le informazioni contenute nella terza chiave con la prima chiave si può sapere quali dispositivi USB sono associati a quali Volumi (l’ultima volta che sono stati inseriti). Incrociando quest’ultima informazione con l’elenco contenuto nella seconda chiave, si può sapere con quale utente sono stati collegati l’ultima volta quegli stessi dispositivi USB.

La prima e la terza chiave si trovano in HKLM\System, quindi possono essere trovate negli hive file di tipo “system” che si trovano in %SYSTEMROOT%\System32\config, oltre che negli equivalenti salvati nei punti di ripristino.

La seconda chiave va cercata nello hive file HKCU\SID dell’utente SID, che si trova nella sua home directory, ovvero in  %USERPROFILE%\NTUSER.DAT (da non confondersi con l’hive file HKU\SID_CLASSES che si trova in  %USERPROFILE%\Local Settings \Application Data\Microsoft\Windows\UsrClass.dat).

Il tool regripper di H. Carvey

Il tool utilizzato per la presente analisi è regripper di H. Carvey, keydet89@yahoo.com. Si tratta di un tool open source, scritto in Perl, reperibile presso http://regripper.wordpress.com/. La versione qui esaminata è la 2.02 del 12 Maggio 2008.

Regripper per Windows ha una GUI abbastanza semplice codificata nel file rr.pl. Qui, viene caricata la main window che, oltre a consentire di scegliere l’hive file su cui effettuare l’analisi ed impostare il nome del file di output, consente anche di selezionare i plugin da utilizzare.

Come spiegato dallo stesso Carvey in un breve articolo di accompagnamento, i plugin sono singoli moduli in perl, situati nella  directory .\plugins, che effettuano uno specifico tipo di analisi. Ad esempio, mountdev.pl effettua l’estrazione dei dati disponibili alla chiave HKLM\SYSTEM\MountedDevices. A titolo di curiosità tra i plugin è disponibile anche un file mountdev2.pl che probabilmente corrisponde ad una versione successiva ma che, a quanto risulta allo scrivente, non viene utilizzato nella release in esame. Analogamente, usbstor.pl effettua l’estrazione dei dati presenti nella chiave HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR. Curiosamente anche per questo file esiste una versione 2 non utilizzata.

Ovviamente non tutti i plugin sono adatti per tutti gli hive file. A questo scopo regripper prevede un meccanismo di pacchettizzazione dei plugin in modo che a seconda dell’hive in esame si possa scegliere il pacchetto di plugins indicato. I pacchetti disponibili nella versione in esame sono:

• all: esegue il plugin regtime, che effettua l’esame di tutte le Hkeys dell’hive file estraendole e riportando anche il LastWriteTime
• ntuser: esegue i plugin finalizzati all’analisi dell’omonimo hive file
• sam: esegue il plugin samparse.pl finalizzato all’analisi dell’omonimo hive file
• security: esegue il plugin auditpol.pl finalizzato all’analisi dell’omonimo hive file
• software: esegue i plugin finalizzati all’analisi dell’omonimo hive file
• system: esegue i plugin finalizzati all’analisi dell’omonimo hive file

• Il programma effettua a runtime una lettura dei contenuti della directory .\plugins, selezionando tutti i file che non hanno estensione “.pl”, corrispondenti ai pacchetti di plugin sopra descritti
• Questi file vengono visualizzati nella combo di lista dei plugin. Nella versione attuale solo uno dei pacchetti può essere selezionato, determinando quali plugin eseguire.

Il meccanismo di costruzione dei pacchetti di plugin è talmente semplice che volendo aggiungerne o modificarne uno è sufficiente creare un nuovo file di testo, con l’elenco dei plugin di interesse, e salvarlo nella directory .\plugins.

Nel nostro caso noi vogliamo quindi utilizzare i plugin mountdev.pl e usbstor.pl per l’esame degli hive file di tipo system.

Invece, per l’esame della chiave HKU\SID\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 utilizzeremo il plugin mp2.pl sugli hive file di tipo ntuser.dat reperibili nelle home directory degli utenti del sistema in esame.

Per effettuare questa analisi è sufficiente utilizzare l’interfaccia utente di regripper, selezionando opportunamente l’hive file ed il plugin. Se fosse necessario si ricorda che l’hive file di un sistema live non può essere acceduto direttamente senza l’ausilio di strumenti appositi.

L’analisi “storica” basata sui Restore Point

Come già detto in un altra serie di articoli, “L’Analisi forense dei ‘Punti di Ripristino’ (Restore Points)”, gli hive file vengono memorizzati da Windows  nei Restore Point generati dalla utilità di ripristino configurazione di sistema. Questo consente di recuperarli e di effettuare analisi di una determinata chiave di registro “nel corso del tempo”, andando a vedere ad esempio come il valore dell’ultimo utilizzo di un dispositivo USB risulta aggiornato nel tempo.

A questo scopo è conveniente utilizzare l’eseguibile da linea di comando fornito con regripper con il quale si possono selezionare i plugin da utilizzare e che può anche essere inserito in un batch per effettuare la stessa analisi sui diversi hive file. Con questa utility, volendo solo effettuare l’analisi della chiave di registro  HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR è possibile usare questa sintassi:

rip -r $system_hive_file -p usbstor >> report_file

dove $system_hive_file può essere una variabile contenente i nomi dei vari hive file di tipo system recuperati dai diversi Restore Point.

Ad esempio, in Windows XP ad ogni salvataggio della configurazione di sistema, gli hive file vengono salvati nella directory snapshot che si trova sotto la directory RPXX (dove XX è il numero progressivo del restore point) che si trova a sua volta due livelli sotto la directory “System Volume Information”.

L’unico accorgimento da tenere presente in questo caso è che gli hive file vengono rinominati. Nel nostro caso l’hive_file system di interesse per l’analisi dell’USBSTOR è reperibile come _REGISTRY_MACHINE_SYSTEM.

Com’è noto, la maggior parte dei tool di informatica forense consente il carving dei file, ovvero:

• Recupero di file cancellati:  possibile quando la entry del file (ad esempio nell’MFT dell’NTFS) viene invalidata, cioè resa disponibile, ma non ancora riutilizzata ed inoltre i cluster del file non sono stati ancora riallocati

• Riconoscimento di file all’interno di cluster non allocati: (Parti di) file possono essere recuperati da porzioni di cluster contigue quando vengono riconosciuti determinati pattern caratteristici di specifici tipi di file

Quando non è possibile ricostruire i file cancellati perché le entry del file system sono state sovrascritte, è possibile tentare il recupero dei metadati contenuti in strutture dati memorizzate all’interno dei file stessi. Alcune di queste strutture dati, contenenti metadati di interesse, hanno infatti un “footprint” riconoscibile, ad esempio una struttura variabile ma che risponde a determinate regole che danno luogo a pattern identificabili. Ricercando in tutti i cluster del disco tali pattern è possibile identificare i settori del disco candidati a contenere tali strutture dati e quindi tentare di leggere le informazioni ivi contenute.

Il procedimento concettuale è il seguente (a meno di ovvie ottimizzazioni dovute all’allineamento dei dati nel filesystem):

1. Posiziono il puntatore in lettura al primo byte del primo cluster del disco
2. Se una struttura con un certo pattern cominciasse dove ho posizionato il mio puntatore, che significato avrebbe il valore che assume i(l) byte che leggo? Ad esempio potrebbe(ro) essere:
• un marker di identificazione della struttura (se la struttura inizia con un marker)
• oppure un offset al quale trovare il primo byte stringa significativo
• oppure la dimensione della struttura
• oppure altri parametri che determinano la semantica dei byte successivi
3. Interpretando i(l) byte in esame come se fosse(ro) parte della struttura ipotizzata, traggo delle conclusioni sulla struttura stessa e continuo a leggere i byte successivi
4. Se procedendo in questo modo trovo dei risultati consistenti quali
• Le informazioni di tipo stringa della mia ipotetica struttura contengono solo caratteri ASCII o UNICODE che costituiscono stringhe “sensate” (tale valutazione non può che essere euristica)
• I valori degli offset sono tra loro compatibili e compatibili con le dimensioni della struttura
• Trovo tutti i campi che mi aspetto con valori che si collocano nei range previsti per la struttura in esame
5. Allora posso concludere di avere trovato una struttura dati del tipo in esame, estrarne le informazioni contenute e spostare il mio puntatore di lettura alla fine della struttura appena letta
6. In alternativa, sposto il mio puntatore di lettura al byte successivo a quello appena esaminato
7. Torno al punto 2, sino a quando non ho terminato il disco.

Ad esempio i file di Microsoft Office contengono una struttura, denominata SummaryInfo che contiene metadati interessanti per l’analisi forense. Per intenderci si tratta della struttura dati che contiene le informazioni visualizzabili nella finestra “Proprietà del documento” (ad esempio in Word 2007 si accede a tale finestra attraverso il menu Office -> Prepara -> Proprietà -> Proprietà Documento -> Proprietà avanzate… in precedenti versioni di Word era molto più accessibile…) quali la data di creazione del file, l’ultima modifica, l’autore dell’ultimo salvataggio, il numero di revisione, il numero di caratteri contenuti nel documento ed il tempo totale di modifica. Come sopra accennato questi dati sono contenuti in una struttura dati che si trova memorizzata all’interno dei file Office.

Le caratteristiche di tale struttura dati, e dei file Office sono “abbastanza” ben documentate nella letteratura tecnica resa disponibile da Microsoft. Con un po’ di pazienza, un po’ di prove ed errori e qualche slancio di fantasia, lo scrivente è riuscito a mettere a implementare una procedura software in grado di effettuare con successo l’analisi descritta sopra.

Questo approccio è stato utilizzato  con successo nel corso di un importante processo penale allo scopo di verificare la presenza al computer dell’imputato asseritamente impegnato in attività di video scrittura mediante l’applicativo Microsoft Word. In tal caso, oltre alle informazioni sulla data ed autore di ciascun salvataggio, si sono rivelate estremamente interessanti anche le informazioni sul numero di revisione e sul numero complessivo di caratteri del documento Word, presenti nella struttura SummaryInfo sopra richiamata, che hanno consentito di ricostruire la progressione delle attività di scrittura nel periodo in esame. 

Successivamente la procedura è stata utilizzata anche con file di diversa tipologia con risultati sorprendentemente interessanti. Ad esempio analizzando le strutture dati dei file di tipo thumbs.db prodotti da Windows Xp è stato possibile ricostruire la presenza nell’hard disk di un indagato di determinati file di fotografie.

Il giorno 1 ottobre, alle ore 9:00 a Roma (Sheraton Hotel), si è tenuta la conferenza dal titolo “DIGITAL FORENSICS AND SECURITY CONFERENCE 2011“, a partecipazione gratuita.

I relatori sono nomi più che noti in questo specifico ambito. Gli interventi hanno spaziato dagli aspetti più tecnici, alle procedure, ai casi reali riscontrati nell’attività, ai risvolti giuridici della ricerca e valenza della prova digitale:

Verso la metà degli anni ’60 negli Stati Uniti furono registrati i primi casi in cui i computer furono utilizzati come mezzi per mettere in atto crimini. Il primo processo tenuto da una corte federale per crimini informatici risale al 1967 quando un tribunale condannò un consulente informatico di una banca di Minneapolis per averne programmato i computer in modo che stornassero parte dei soldi verso un suo conto corrente. Gli agenti federali, chiamati ad investigare su tali casi, molto spesso erano privi di una preparazione specifica e dovevano affidarsi alla loro buona volontà per apprendere le nozioni necessarie.

La storia dell’informatica forense, intesa come scienza e disciplina accademica, nasce solo vent’anni più tardi, intorno alla fine degli anni ’80 – inizio degli anni ’90, con il lavoro pionieristico dei proff. Eugene Spafford della Purdue University in USA e del prof. Peter Sommer della London School of Economics in UK. Sino al 1988, anno in cui si diffuse il famoso virusWorm, la maggior parte delle persone non avevano alcuna percezione di quali fossero i rischi connessi all’utilizzo dei computer e della rete. Quell’anno, il virus messo a punto da Robert Morris, allora studente della Cornell University, riuscì a paralizzare la rete mandando in tilt qualcosa come 6,000 server, circa il 10% dei computer allora attestati su Internet. Il danno fu stimato tra i 10 e i 100 Milioni di dollari americani e l’autore fu condannato, sulla base di una legge del 1986, aqualche anno di carcere, oltre ad una multa di 10,000$.

Da allora la pratica della computer forensic si è sviluppata sino a diventare una disciplina per addetti ai lavori con una preparazione specifica, strumenti di supporto specialistici e metodologie riconosciute dalla legge. Trent’anni dopo l’informatica forense è diventata, in tutto il mondo sviluppato, oggetto di studio e di impiego quotidiano da parte di aziende, avvocati, autorità giudiziaria, investigatori, organizzazioni commerciali. Tale utilizzo è destinato inevitabilmente ad aumentare insieme alla progressiva informatizzazione della vita moderna. Al giorno d’oggi noi facciamo un uso continuo dei computer per comunicare sia per lavoro che per motivi personali.

La diffusione capillare dei personal computer, cellulari internet e, più recentemente, di e-mail, chat, palmari, chiavi USB, reti WiFi, ha portato all’aumento esponenziale della quantità di dati trasmesse e memorizzate in formato elettronico. Tutti questi strumenti mantengono tracce del loro utilizzo, nella forma di file, log, record, documenti, frammenti, spesso nascosti all’utente inconsapevole, che possono consentire ad un esperto informatico forense di ricostruire importanti informazioni sui relativi utilizzatori ed, all’occorrenza, possono diventare materiale di interesse giudiziario e fonte di prove applicabili in tribunale. D’altra parte, l’enorme disponibilità su Internet, unita con l’ormai universale (nel mondo occidentale) facilità di accesso della Rete, di validi strumenti di pirateria informatica ha reso possibile a utenti non specialistici ed altrimenti insospettabili, di improvvisarsi pirati informatici e di lanciare attacchi, ad esempio, per utilizzare reti wireless non adeguatamente protette oppure per carpire informazioni riservate all’interno della propria azienda. Questo comportamento, che nella maggioranza dei casi passa inosservato per l’incapacità di chi lo subisce di rendersene conto, può talvolta portare conseguenze serie, quali danni d’immagine, perdita di informazioni strategiche, intoppi nella catena produttiva e perfino danni a terze parti. In tali casi l’intervento di un esperto forense è indispensabile non solo per identificare la fonte dell’attacco, raccogliendo prove sufficienti per un’azione giudiziaria, ma anche per individuare quali siano state le debolezze sistemiche sfruttate e predisporre opportune contromisure.

In definitiva è evidente come la stessa tecnologia abilitante il mondo dell’informazione nel quale viviamo stia allo stesso tempo rendendo indispensabile lo sviluppo dell’informatica forense, intesa come lo studio delle tracce informatiche lasciate dalle persone nell’utilizzo dei sistemi info-telematici, che può essere di interesse sia ai fini dell’accertamento della verità giudiziaria, sia in ottica di tutela delle informazioni. Non è insolito infatti vedere accomunati i temi di informatica forense con quelli della sicurezza.

ANALISI DEI LINK NEI PUNTI DI RIPRISTINO

Dopo aver descritto nei precedenti articoli il funzionamento e le modalità di analisi dei Restore Points, si ritiene utile approfondire nello specifico come analizzare la tipologia di file ‘.lnk’.

La creazione di ogni file di tipo A00* (all’interno delle cartelle dei Punti di Ripristino) fa riferimento ad un evento di cancellazione all’interno del filesystem, e non il contrario. Ovvero, quando un file viene cancellato e la sua estensione è compresa nella lista delle estensioni tracciate dai punti di ripristino, viene tenuta copia dello stesso in un file ditipo A00* all’interno delle cartelle dei punti di ripristino.

Questa operazione viene anche tracciata all’interno del log file del relativo punto di ripristino (file di tipo rp.log). All’interno di questi log vengono anche riportate le altre operazioni effettuate sui file con estensione presente nella lista dei punti di ripristino, per esempio le operazioni di creazione di unnuovo file. In questo caso però non avviene la corrispondente creazione del file di tipo A00*.

E’ quindi importante la corretta lettura dei dati presenti sia nei punti di ripristino che nei relativi file di log. A tal fine, il programma di parsing che abbiamo realizzato (vedi articolo precedente) quale supporto all’analisi dei file di log, consente di analizzare in formato comprensibile i contenuti di tali log. L’output di tale programma consente di comprendere le operazioni tracciate nel file di log, tra cui:

• tipo di operazione (creazione, cancellazione, etc);
• nome file;
• eventuale file di tipo A00* creato.

Poiché nella lista dei file tracciati è presente l’estensione dei file di tipo link (.lnk), è anche utile focalizzare il meccanismo di creazione di tali file: quando viene aperta una foto, o un documento,viene creato, all’interno della directory ‘Recent’ o ‘Documenti Recenti’ un link al file appena aperto, e un altro link alla cartella in cui si trova lo stesso file. Non vengono però creati indefinitamente nuovi link nella cartella, ma un numero predefinito in base ai settaggi del sistema operativo.

Quando viene creato un nuovo link, viene tipicamente cancellato un link più vecchio della stessa tipologia (documento, immagine, etc).Il meccanismo descritto sopra conduce a questi eventi, praticamente contestuali, all’apertura di unfile documento (ovvero non di tipo programma):

• viene creato un link nella directory dei documenti recenti;
• viene tracciata l’operazione di ‘creazione file ‘ nel log dei punti di ripristino;
• viene contestualmente cancellato il link più vecchio (se superato il numero massimo dioccorrenze previste) della stessa tipologia (estensione del file);
• viene creato un file di tipo A00* all’interno della cartella dei Punti di Ripristino attiva;
• viene tracciata l’operazione di ‘cancellazione file’ nel log dei punti di ripristino.

L’insieme di tutti questi artefatti consente di poter risalire alle operazioni effettuate, incrociando fraloro dette informazioni, anche per poter disporre di un riferimento temporale, non presente all’interno del file rp.log.

Contenuto dei Restore Points

I file di registro (hives) sono copiati in ciascun Punto di Ripristino al momento della sua creazione. Altri file specifici vengono copiati nel Punto di Ripristino “corrente” prima di una loro modifica/cancellazione. Tuttavia, non tutti i file sono copiati dopo una modifica nei Punti di Ripristino. La selezione dei file è governata da istruzioni di inclusione ed esclusione nel file “filelist.xml”, situato normalmente nella directory “C:WINDOWSsystem32Restore” e pressoché sconosciuto agli utenti comuni. Questo file XML guida il processo di creazione dei punti di ripristino e definisce quali estensioni saranno monitorate. In questa lista sono anche definite le directory incluse ed escluse dal monitoraggio. Nell’ambito di un’investigazione, gli elementi che possono essere utili sono:

• Copie dei Registri: l’analisi delle copie dei registri nel corso del tempo può mostrare modifiche al sistema, quali (a titolo esemplificativo e non esaustivo) l’installazione di hardware o software, cambi nella configurazione dei programmi, cambi di password e storia di rete. Per la vastità di informazioni contenute nei registri, la lista può essere molto più lunga.

• Copie dei file: Un esempio dei file che possono essere trovati nei punti di ripristino includono i file .exe, .dll, .ini, .lnk e altri meno comuni. File che tipicamente non si potranno trovare nei punti di ripristino sono quelli più specifici dell’utilizzatore, come i file .doc, .pdf e .pst. Vari log file, tra i quali i log degli eventi di windows non sono normalmente inclusi nei punti di ripristino.

L’importanza di questa ulteriore fonte di informazioni è elevata quando altri elementi utili all’indagine sono persi o compromessi (o manomessi). Sicuramente sono degni di rilievo i file di tipo ‘link’: dal momento che diversi applicativi di Windows creano questa tipologia di file in per tracciare i ‘file recenti’ utilizzati dall’utente, le variazioni di questi rimangono anche nelle directory dei punti di ripristino, consentendo quindi di avere elementi aggiuntivi di supporto per l’analisi forense. In mancanza di specifici software sul mercato (tra le poche eccezioni, il tool prodotto da Mandiant), per la lettura puntuale degli elementi presenti nel file ‘change.log’, che contiene tutti gli eventi associati ai punti di ripristino, abbiamo realizzato un parser ad hoc per l’ estrazione e rappresentazione in excel (csv) di detta tipologia di file.

Fine seconda parte – continua –