INFORMATICA - WRITE-BLOCKERS

Dicembre 2007

Le molteplici richieste di informazioni in proposito, pervenute al mio indirizzo [email protected] ed anche il fascino prettamente tecnico che trovo nell'argomento, mi hanno convinto a scrivere questa pagina sui write-blocker.

Segnalo in proposito il volume [44] ed ovviamente la parte del sito del NIST (National Institute of Standards and Tecnology) http://www.cftt.nist.gov/project_overview.htm relativa al CFTT (Computer Forensics Tool Testing)  affinchè possiate prendere da soli ulteriori informazioni sull'argomento. In particolare il sito del NIST presenta diversi risultati sui test di write-blocker sia hardware che software e la modalità con la quale hanno sapientemente impostato la sperimentazione potrà far meglio comprendere che bloccare comuni comandi di scrittura non è l'unica funzionalità richiesta a questi tool e che sono proprio i casi eccezionali di funzionamento il target di estremo interesse nel computer forensics.

L'articolo "Disk drive I/O Commands & Write Blocking" di J.Lyle, S.Mead e K.Rider in [44], pubblicato lo scorso luglio 2007, riprende proprio le attività del NIST nel gruppo di lavoro CFTT, vero e proprio punto di riferimento per la valutazione della qualità dei tool da impiegare nel Computer Forensics (a mio avviso dovrebbe essere un punto di riferimento essenziale per tutti gli operatori nel settore, ma sfortunatamente alcune ditte che operano commercialmente nel Computer Forensics non hanno interesse nel facilitare il lavoro - disponibile a tutti ed a favore di tutti - del CFTT...).

Si può iniziare dall'aspetto più pratico ed immediato dei write-blocker: perchè ed in quali circostanze si impiegano?

I momenti di impiego dei write-blocker sono fondamentalmente due: (1) l'acquisizione dell'immagine di una memoria di massa (post-mortem = dopo il fatto); (2) l'analisi real-time (durante il fatto o in prossimità di esso o direttamente sul reperto presente sulla scena del crimine) del contenuto di una memoria di massa (drive preview o talvolta live analysis).

Nel caso (1) il write-blocker ha lo scopo di assicurare che durante la copia la memoria di massa sorgente (reperto originale) non venga in nessun modo alterata dalla scrittura di dati, a prescindere da quanti essi siano (anche un solo bit!) e dal fatto che siano rilevanti o meno ai fini delle indagini (che siano dati dell'utente o dati di sistema/file system una modifica è sempre una modifica per cui va prevenuta oppure, nell'impossibilità di prevenirla basta optare per un accertamento irripetibile). Se il meccanismo di imaging impiegato è corretto ed il write-blocker opera nel modo migliore (senza eccezioni) ci si aspetta che il valore dell'hash dell'immagine e quello della memoria di massa sorgente (prima della copia) risultino, a fine processo, identici.

Molto peggio nel caso (2) il write-blocker ha l'indispensabile funzione di assicurare che l'operatore svolga l'inspecting dei dati (drive preview) senza avere la possibilità, anche involontaria, di alterare il contenuto della memoria target. E' importante fare una distinzione in questo senso: mentre il drive preview (solo lettura) può essere sufficientemente garantito dai write blocker, la live analysis è qualcosa di molto più complesso (perchè implica interazione articolate con il reperto e magari con la rete cui è collegato) ed attualmente i write-blocker sono meccanismi necessari ma non sufficienti a garantire una live analysis perfettamente ripetibile. Di questo basta tenere ovvio conto in ambito legale.

I write-blocker sono di tre tipologie fondamentali:

(a) Firmware based: orientati ad impiegare le primitive del BIOS ed a gestire la loro inibizione in qualsiasi tipo di scrittura;

(b) Software o Driver based: sono software di basso livello (in ambiente windows dei driver) orientati ad intercettare qualsiasi interruzione hardware o software che diriga qualsiasi tipo di scrittura verso la memoria di massa considerata. In questo caso è quindi il sistema operativo ad impedire l'alterazione e non il BIOS. Sempre di conseguenza eventuali bug del sistema operativo hanno un immediato effetto sulla garanzia di funzionamento del write-blocker.

(c) Hardware based: sono veri e propri dispositivi elettronici che "tagliano" il bus di comunicazione tra unità di storage fisica e scheda madre (generalmente) e si interpongono come intermediari valutando ed eventualmente inibendo tutto ciò che entra ed esce dal dispositivo target.

La mia fiducia si ripone, potendo scegliere, soprattutto sugli hardware write-blocker. Le motivazioni immediate sono le seguenti: i firmware based write blocker operano ad un livello così basso che spesso non riescono a comprendere se il comando verso la memoria di massa è nocivo o meno. I driver based sfortunatamente dipendono troppo dal sistema operativo e fino a quando si parla di un sistema operativo kernel-based molto ben strutturato e progettato come Linux o Unix ci si può fare affidamento (e non completamente...) ma e mi scuseranno i tifosi di Microsoft... quando ad operare è un sistema operativo destrutturato come Windows, talmente ricco di eccezioni costruttive da essere incontrollabile, la questione si fa problematica.

Volendo approfondire tecnicamente è bene ora trattare di quelle che precedentemente ho definito eccezioni. I comandi per le memorie di massa sono, come evidenziato in [44], riassumibili nelle seguenti categorie:

  • Comandi di lettura: che non devono essere mai inibiti dal write-blocker;
  • Comandi di scrittura: che devono sempre essere inibiti dal write blocker;
  • Comandi di lookup (presa di informazioni sul dispositivo): che dovrebbero essere inviati al dispositivo solo dal write-blocker, il quale dovrebbe preventivamente creare una tabella virtuale di tali dati nella sua memoria temporanea e proporli lui (simulando la risposta) alla scheda madre;
  • Comandi di controllo (tesi a cambiare configurazione o contenuto del dispositivo): nel write-blocker deve esserci un'"intelligenza" minima atta a filtrarli accuratamente.
  • Altri comandi: non inclusi nelle precedenti categorie e comunque, dato che sono difficilmente catalogabili, conviene che il write-blocker li filtri.

Le eccezioni consistono proprio nella difficoltà dei progettisti di write-blocker nel prevedere tutte le situazioni anomale che si possono presentare sul BUS di una memoria di massa. A partire dal danneggiamento di settori fisici della memoria cui conseguono spesso combinazioni non ordinarie di segnali elettrici sul BUS, al presentarsi di un comando di controllo non contemplato e magari non comprensibile dall'intelligenza del blocker.

Quello che è certo, comunque è che un hardware write-blocker non può essere aggirato da meccanismi software in quanto fisicamente interposto sul BUS. Lo stesso non si può dire per i sofware write-blocker.

Nello studio del NIST (http://www.cftt.nist.gov/software_write_block.htm) si può facilmente verificare come i software write-blocker spesso hanno qualche problema nell'identificare i drive e nel bloccare alcuni particolari comandi verso il dispositivo.

E per finire una domanda banale: i write-blocker sono indispensabili?

Spesso, esperti di digital forensics appassionati dell'open source (tra i quali non mi escludo di essere) mi fanno presente la loro immensa fiducia nei confronti di Linux, del suo meccanismo di mounting e della possibilità di svolgere acquisizioni sotto tale sistema operativo senza la necessità di nessuna protezione. Personalmente ritengo questo approccio non molto corretto perchè sottostima la possibilità di incontrare eccezioni. Sebbene di Linux siano state studiate anche versioni con kernel "forense" mirate proprio ad intercettare le scritture sui dispositivi, il non inserire un hardware write blocker durante l'acquisizione è mancanza di prudenza e di conseguenza è come togliere delle piccole garanzie al possessore del dispositivo.

Evito di discutere la questione di chi opera le acquisizioni sotto Windows-like system solo con protezioni software.

marcomattiucci.it

Informatica:

Digital Forensics - articoli:

Digital forensics: