giovedì 10 ottobre 2019

Acquisizione forense di un hard disk

Si stanno consolidando, negli usi e consuetudini, ma anche come conseguenza di prescrizioni legislative, alcune operazioni tecniche destinate a diventare "di routine" per gli informatici forensi. Fra queste, l'acquisizione e la messa in sicurezza dei dati digitali nello specifico memorizzati in un hard disk. Vedremo quindi come si dovrebbe procedere per evitare le problematiche note derivanti da un acquisizione non professionale.

Le linee guida, per un corretto svolgimento dell'operazione qui descritta nei dettagli, sono contenute nel codice di procedura penale, così come modificato dalla legge del 18 febbraio 2008 n.48/2008 (nota anche come "ratifica alla Convenzione di Budapest del 23 novembre 2001 del Consiglio d’Europa". 

Sono quindi disciplinate modalità e limiti all’attività investigativa già operante a livello di prassi giudiziaria  prevedendo, in parallelo, che tali operazioni assicurino la genuinità, la conservazione dei dati originali e la non alterabilità dei dati stessi. Utile ricordare che il CPP elenca unicamente i risutati attesi senza specificare il "come" questi debbano essere ottenuti. 

La parte "acquisizione forense" quindi è preliminare ed atta a garantire la genuinità dei dati, ovvero l'esatta corrispondenza fra dati originali e dati acquisiti in copia.

A premessa, è utile ricordare un paio di concetti preliminari: 

La sterilizzazione del disco: ...che dovrà eventualmente accogliere i dati acquisiti. Se l'acquisizione viene effettuata con scrittura di un "file immagine" (bit-stream image), ovvero la memorizzzazione su un supporto di destinazione di uno stream di bit letti in seguenza dal disco originale, (ad esempio con il classico comando GNU-Linux "dd"), la sterilizzazione del disco di destinazione non è necessaria, ovvero è inutile e non attinente ad offrire le garanzie previste. 

Il file immagine prodotto, conterrà la copia fedele del disco di partenza (preferibilmente del disco intero, dal primo all'ultimo bit di origine). Ciò che verrà analizzato sarà contenuto nel file immagine che sovrascriverà l'area di destinazione esattamente con quanto contenuto nel disco di origine. Tutto ciò che è al di fuori del file nel disco di destinazione non interessa per le analisi (e non interferisce con esse). A poco quindi valgono le contestazioni in merito ad una mancata sterilizzazione dei supporti di destinazione se l'acquisizione è stata fatta creando un file immagine dal supporto di origine. Il file immagine inoltre è più comodo da gestire. Può essere compresso, splittato (suddiviso in porzioni) e masterizzato, montato in loop per l'analisi del filesystem in sola lettura o per l'esecuzione con i programmi di virtualizzazione tipo Vmware o Qemu.

L'acquisizione professionale o "di legge". Qualsiasi operazione svolta e documentata in grado di soddisfare i requisiti previsti, può considerarsi "di legge" e/o "professionale". L'uso di apparecchiature note col nome di "write blocker" alternative all'uso di comandi digitati manualmente su un terminale virtuale, sono entrambi metodi validi e professionali, in grado di soddisfare i requisiti richiesti.

Procedura: Si inizia con l'accesso fisico al computer oggetto di attenzioni (solitamente un PC, stiamo trattando un caso "classico"). Non si deve in nessun modo permettere che il sistema operativo installato si avvii dai dischi oggetto di acquisizione, pena l'alterazione dei dati contenuti e perdita di uno dei requisiti richiesti.

Si può procedere quindi con staccare i cavi del disco ed avviare il PC per accedere al bios. L'accesso al bios è necessario per settare l'avvio del PC dal lettore di supporti ottici (CD o DVD), o per controllare che comunque il PC si avvii dal lettore ottico.

Effettuate le modifiche al bios, il PC viene ri-avviato da CD con una distribuzione GNU-Linux "forensic compatibile" in grado di garantire il blocco in scrittura dei dischi installati nel PC oggetto di indagine. 

L'alternativa a questo modo di procedere, è lo smontaggio fisico del disco che va collegato ad un adattatore USB su un sistema GNU-Linux già avviato su cui sia preventivamente stato disabilitato il demone che esegue il montaggio automatico delle unità esterne. La disabilitazione del demone si ottiene con il comando (per le distro Ubuntu)

sudo /etc/init.d/hald stop

o, in alternativa nei sistemi che non usano il demone \"hald\" come per la distribuzione Ubuntu 10.04 e successive,

sudo service udev stop

La disabilitazione descritta non è necessaria quando si utilizza una Distro forense appositamente confezionata per le operazioni qui descritte.

In alternativa, per usare altri sistemi, è possibile acquistare un "write blocker", collegarci il disco da acquisire ed un disco di destinazione "vuoto" per i dati e procedere con le operazioni previste dal dispositivo.

Per leggere qual'è l'unità assegnata dal sistema al disco collegato via usb, si digiti il comando "dmesg" (in pipe con tail -15 per leggere solo le ultime 15 righe  che ci interessano)

dmesg | tail -15

ci potremmo trovare un output del genere:

[21815.547051] Initializing USB Mass Storage driver...
[21815.548954] scsi2 : SCSI emulation for USB Mass Storage devices
[21815.549321] usbcore: registered new interface driver usb-storage
[21815.549329] USB Mass Storage support registered.
[21815.550497] usb-storage: device found at 3
[21815.550502] usb-storage: waiting for device to settle before scanning
[21820.548432] usb-storage: device scan complete
[21820.550551] scsi 2:0:0:0: Direct-Access     Maxtor 6 E040L0           0000 PQ: 0 ANSI: 0
[21820.554506] sd 2:0:0:0: [sdb] 80293248 512-byte hardware sectors: (41.1 GB/38.2 GiB)
[21820.598443] sd 2:0:0:0: [sdb] Write Protect is off
[21820.598451] sd 2:0:0:0: [sdb] Mode Sense: 27 00 00 00
[21820.598458] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[21820.599258] sd 2:0:0:0: [sdb] 80293248 512-byte hardware sectors: (41.1 GB/38.2 GiB)
[21820.601227] sd 2:0:0:0: [sdb] Write Protect is off
[21820.601234] sd 2:0:0:0: [sdb] Mode Sense: 27 00 00 00
[21820.601239] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[21820.601247]  sdb: sdb1
[21820.613398] sd 2:0:0:0: [sdb] Attached SCSI disk
[21820.613525] sd 2:0:0:0: Attached scsi generic sg2 type 0

Si passa quindi all'acquisizione vera e propria con il comando:

dd bs=1 conv=noerror,sync if=/dev/sdb of=/<percorso-destinazione>/<nomefile> (es. disco1.img)

Va acquisito l'intero disco (salve diverse disposizioni impartite dall'AG) dal primo all'ultimo bit, per cui il parametro 'if' deve fare riferimento all'intero device (/dev/sdb e non /dev/sdb1).Per il parametro "bs", sono ammessi valori diversi purchè frazioni intere del numero dei blocchi del disco in esame. Per conoscere il numero dei blocchi del disco basta dare il comando

sudo fdisk -l /dev/sdb

per ottenere un output simile al seguente:

Disco /dev/sdb: 160.0 GB, 160041885696 byte
255 testine, 63 settori/tracce, 19457 cilindri
Unità = cilindri di 16065 * 512 = 8225280 byte
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identificativo disco: 0x000a780e

Dispositivo Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1       18709   150274048   83  Linux
/dev/sdb2           18709       19458     6013953    5  Esteso
/dev/sdb5           18709       19458     6013952   82  Linux swap / Solaris

Una chiavetta formattata per Windows potrebbe dare un output simile al seguente:

Disco /dev/sdb: 262 MB, 262144000 byte

32 testine, 33 settori/tracce, 484 cilindri
Unità = cilindri di 1056 * 512 = 540672 byte
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identificativo disco: 0x00000000

Dispositivo Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1         485      255984    6  FAT16
La partizione 1 ha diversi elementi iniziali fisici/logici (non Linux?):
     phys=(0, 1, 1) logico=(0, 0, 33)
La partizione 1 ha diversi elementi finali fisici/logici:
     phys=(254, 31, 33) logico=(484, 27, 5)

Si potrebbe indicare un parametro "bs" (Block size) pari a 1024 (pari a due settori alla volta),  prestando attenzione a cosa si fa. Data la presenza del parametro "sync" che indica a dd di scrivere i blocchi della dimensione prescelta (es. 32K) se non ci sono abbastanza dati per riempire il blocco, quest'ultimo sarà riempito di zeri modificando la dimensione totale dei dati acquisiti. Se poi ci si imbatte in qualche settore danneggiato?  La combinazione impostata di sync, noerror e bs potrebbe tralasciare la copia dei settori sani che potrebbero esserci in quei 32Kb. 

L'output di dd:

dd bs=1 conv=noerror,sync if=/dev/sdb of=chiavetta.img
262144000+0 record dentro
262144000+0 record fuori
262144000 byte (262 MB) copiati, 2810,4 s, 93,3 kB/s

della durata di circa 45 minuti, mentre:

dd bs=512 conv=noerror,sync if=/dev/sdb of=chiavetta_bs512.img
512000+0 record dentro
512000+0 record fuori
262144000 byte (262 MB) copiati, 33,9994 s, 7,7 MB/s

oppure

dd bs=512K conv=noerror,sync if=/dev/sdb of=chiavetta_bs512k.img
500+0 record dentro
500+0 record fuori
262144000 byte (262 MB) copiati, 33,0811 s, 7,9 MB/s

con durata decisamente inferiore. Si noti che:

dd bs=1000K conv=noerror,sync if=/dev/sdb of=chiavetta_bs1000k.img
256+0 record dentro
256+0 record fuori
262144000 byte (262 MB) copiati, 33,0725 s, 7,9 MB/s

non porta a significativi incrementi di velocità di trasferimento. Se al parametro diamo un valore "a caso", ecco cosa accade:

sudo dd bs=488K conv=noerror,sync if=/dev/sdb of=chiavetta_bs488k.img
524+1 record dentro
525+0 record fuori
262348800 byte (262 MB) copiati, 33,0055 s, 7,9 MB/s

Si noti infatti la differenza record dentro/fuori che produce un risultato inaccettabile da un punto di vista forense e sbagliato da un punto di vista tecnico.

Dopo aver generato il dump su un file, si prosegue quindi con la generazione delle impronte di hash MD5 e SHA1 (si suggerisce di generarne almeno un paio per arginare in partenza la solita contestazione in merito alle collisioni). Un hash SHA512 taglia la testa al toro.

Negli esempi di prima:

md5sum chiavetta*

7213171f0d4391fb7ad4e89a30322f38  chiavetta_bs1000k.img
7213171f0d4391fb7ad4e89a30322f38  chiavetta_bs512b.img
7213171f0d4391fb7ad4e89a30322f38  chiavetta_bs512k.img
7213171f0d4391fb7ad4e89a30322f38  chiavetta.img
2674c185feabf53391c060901dcfc7d5  chiavetta_bs488k.img

che evidenzia l'errore ottenuto con il parametro "bs" errato e la correttezza dell'acquisizione con gli altri valori.

Se l'immagine viene successivamente splittata (il termine parte dal comando GNU-linux  "split") in porzioni di dimensioni compatibili con la capacità dei DVD su cui verrà masterizzata l'immagine, vanno generate le impronte di hash per ogni porzione creata e va firmato anche il file di testo che le contiene ed elenca (per sicurezza occorrerà riportare nella relazione tecnica e/o a verbale tali valori e rendere anche i supporti cartacei difficilmente alterabili apponendo firme autografe, timbri e quant'altro di utile).

Per l'analisi, si esegue il montaggio dell'immagine acquisita in sola lettura. Dato che è stata acquisita l'intera area del disco di origine (non una singola partizione), nel montaggio è indispensabile, affinchè vada a buon fine, indicare l'offest di inizio della partizione oggetto di attenzioni. Immaginiamo che il file immagine creato presenti un'unica partizione. Nei sistemi NTFS, la partizione inizia dal blocco 63 in poi. Ogni blocco è di 512 bytes pertanto l'offset da indicare sarà 63*512=32256 per la prima partizione.

sudo mount -t ntfs -o ro,offset=32256 /dev/sdb /media/disco1

Ricordarsi il parametro "ro" = read only - sola lettura

Per il montaggio manuale in sola lettura:

mount -t <tipo> -o ro /dev/sdb1 /<percorso-destinazione dove si desidera montare il dispositivo...es. mnt>

Meglio ricordare qui che l'opzione "ro" (read only o in italiano sola lettura) può da sola non essere sufficiente per garantire l'inalterabilità del supporto.

Per esempio, montando un file system ext3 danneggiato solo con l'opzione -o ro potrebbe esserci una modifica dei metadati nel processo di recovery, come da messaggio che segue:

EXT3-fs: INFO: recovery required on readonly filesystem. 

EXT3-fs: write access will be enabled during recovery. 

kjournald starting. Commit interval 5 seconds 

EXT3-fs: recovery complete. 

EXT3-fs: mounted filesystem with ordered data mode. 


Per ovviare, basta aggiungere l'opzione "loop" al parametro -o come da esempio che segue:

mount -o ro,loop /dev/sdb1 /<percorso-destinazione dove si desidera montare il dispositivo...es. mnt>

oppure ricorrere al blocco dei dispositivi in sola lettura con

blockdev --setro /dev/sdb1

Si può, nel caso che ci interessa, montare il file immagine creato  con "dd" attraverso l'uso di alcuni accorgimenti. Vediamo l'esempio che segue:

sudo fdisk -lu sdc.img

Sdc.img è l'immagine di una scheda di memoria SDC.  Risposta:

Si devono impostare cilindri.
È possibile effettuare questa operazione dal menu delle funzioni supplementari.

Disco sdc.img: 0 MB, 0 byte
10 testine, 41 settori/tracce, 0 cilindri, totale 0 settori
Unità = settori di 1 * 512 = 512 byte
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identificativo disco: 0x00000000

Dispositivo Boot      Start         End      Blocks   Id  System
sdc.img1             233     1006591      503179+   6  FAT16
La partizione 1 ha diversi elementi iniziali fisici/logici (non Linux?):
     phys=(0, 3, 45) logico=(0, 5, 29)
La partizione 1 ha diversi elementi finali fisici/logici:
     phys=(998, 9, 41) logico=(2455, 1, 1)

Per montare questo file immagine, si usa l'opzione "loop" al fine di poterlo  consultare come fosse un normale device, indicando correttamente l'offset che in questo caso, pe la partizione che ci interessa, inizia dal settore 233. Ogni settore è di 512 byte, per cui per trovare l'offset basta moltiplicare 233*512= 119296. Quindi il comando corretto per il montaggio sarà

sudo mount  -t vfat -o offset=119296,loop,ro sdc.img /mnt

Per sfogliare il contenuto si può utilizzare il comando:

ls -l /mnt

che produrrà ad esempio il seguente risultato:

totale 8752
-rwxr-xr-x 1 root root 3831808 2008-06-19 20:32 ACDC - Safe In New York City.mp3
-rwxr-xr-x 1 root root 5080380 2008-06-19 20:32 ACDC - Shoot To Thrill.mp3
drwxr-xr-x 2 root root   16384 2008-12-26 14:28 documentazione
drwxr-xr-x 2 root root   16384 2008-03-03 09:55 perizie

Terminata la procedura di montaggio si procede con lo strumento di analisi preferito (es. Autopsy od Encase) per procedere con la stesura della relazione, documentando le operazioni compiute, le ricostruzioni, le metodologie usate, le motivazioni, i risultati, le conclusioni ecc...

Grazie per l'attenzione

Giovanni Grandesso


Nessun commento: