INFORMATICA - DATABASE FORENSICS

"I database, ed in particolare quelli relazionali e ad oggetti, hanno organizzato la maggioranza delle informazioni attualmente memorizzate e disponibili online ed offline: l'indagine su di essi è divenuta di una importanza capitale! "

Febbraio 2010

Questo articolo è stato realizzato con la collaborazione della Dr. Giuseppe Totaro che ha posto gentilmente a disposizione gli scritti della sua tesi di master (II° livello - Scienze forensi) "DECRIPTAZIONE DEI FILE PROTETTI DA PASSWORD DA DBMS ORACLE" realizzata sotto la mia supervisione e quella del Ten. Dr. Giuseppe Delfinis presso la Facoltà di Scienze MM.FF.NN. dell'Università degli Studi di Messina.

Indagini Tecniche sui Database

Tra le innumerevoli applicazioni del Digital Forensics assume un ruolo di primo piano il Database Forensics, relativo alle indagini tecniche sui database ed in particolare sulle informazioni archiviate, gestite e magari anche generate (si pensi ad esempio alle varie tipologie di logging) dai Database Management System(s) (DBMS).

Il Database Forensics eredita dal Digital Forensics la caratteristica della vastità ed anche orientandosi principalmente sui DBMS relazionali (che occupano la stragrande fetta di mercato nel settore), le opportunità di scelta e le peculiarità di ognuno di tali DBMS (Oracle, DB2, MySQL, SQL Server,...) rende molto difficile costruire delle teorie generali, ad ogni modo si può ben dire che l'indagine tecnica deve comunque avvenire sui seguenti aspetti:

1) Database dump & backup: studio delle opzioni e dei metodi di dumping dei file e/o delle partizioni che realizzano il database nonchè studio della funzione di backup interna al DBMS (anch'essa spesso impiegata a livello forense).

2) Estrazioni di dati non di controllo: nella maggioranza dei casi si tratta semplicemente di data filtering & correlation svolto tramite la creazione di opportune query SQL sulle tabella dei dati archiviati. In altre situazioni particolari può essere necessaria una vera e propria operazione di data mining mediante particolari tool (quando, ad esempio, si devono trattare grosse moli di dati o bisogna desumere decisioni complesse da dati fortemente articolati).

3) Estrazione di dati di controllo: rilevazione ed analisi di access, redo & archive log.

4) SQL Forensics: analisi del codice SQL già implementato nel sistema e che realizza viste, filtri, modifiche temporizzate o innescate da eventi, ecc.

5) Data recovery: recupero di dati cancellati dal DBMS a diversi livelli (tabelle e file system).

6) Password cracking: spesso accedere al database con i poteri da amministratore (DBA) è l'unica possibilità per verificare delle operazioni e/o per recuperare dati eliminati da cui l'importanza di aggirare questa protezione tipica di ogni DBMS.

Oracle Forensics

In base all'esperienza investigativa dello scrivente lo studio del DBMS Oracle dal punto di vista del forensics è determinante. La frequenza con la quale questo DBMS si presenta su piattaforme importanti e di grandi/medie dimensioni, a livello aziendale, ne costituisce la principale giustificazione. Da diverse decine di anni, Oracle, fondata da Larry Ellison, opera come leader nel settore dei database relazionali, fornendo un ampio ventaglio di tecnologie e applicazioni. I database Oracle sono spesso deputati alla realizzazioni di sistemi complessi con una grande quantità di dati, che possono assumere un'elevata importanza e confidenzialità. Queste considerazioni fanno di Oracle un target allettante per malintenzionati e criminali i quali, volontariamente o meno, si trovano a veicolare o alterare dati gestiti da questi DBMS. E' poi da sottolineare che lo studio di Oracle, può costituire una solida base per l'approccio a diversi altri DBMS data la complessità e le potenzialità del sistema.

L'Oracle Forensics, per come è strutturato Oracle, si può definire come l'insieme dei processi attraverso i quali un operatore (auditor) cerca di determinare quando, come e perchè qualcosa sia accaduto raccogliendo e correlando informazioni (evidenti o cancellate) di controllo o meno attraverso sia il motore DBMS che direttamente sull'archivio dati posto sotto la sua gestione.

Qualcosa di simile a quanto descritto avviene nel caso delle violazioni di sicurezza di sistemi che basano la loro attività sul motore Oracle. La presenza di archive & redo log ed audit trail è determinante ai fini di avere successo nell'indagine tecnica. Nel caso del forensics è indispensabile anche avere pieno potere sui dati gestiti dal DBMS in quanto alla necessità, spesso verificata, di dover recuperare dati cancellati o modificati dal DBMS stesso. Sfortunatamente non esistono tool completi e specifici per l'Oracle Forensics quindi l'investigatore tecnico è tenuto spesso all'uso diretto di query PL-SQL e/o di un linguaggio ospite (ad esempio il C).

In molti casi purtroppo si verifica che gli audit trail non sono presenti in quanto il processo di audit non è attivato. In tale situazione, il recupero di informazioni come la rilevazione/valutazione delle SELECT svolte ed il tracciamento delle estrazioni di blocchi di dati, risulta molto difficile e deve basarsi su delle strategie che sfruttino:

- File di LOG del Listener TNS;

- Diversi tipi di trace file;

- Log di SQL*Net (Server e Client);

- Log di audit per SYSDBA;

- Datafile impostati per dati cancellati;

- File di redo & archive log;

- SGA (V$SQL, ecc.);

- Log di Apache (qualora attivo);

- V$DB_OBJECT_CACHE;

- Viste VHR$;

- Viste WHI$;

- Viste dell'utility STATSPACK;

- col_usage$;

- File cancellati da file system;

La correlazione delle informazioni deve essere applicata in due direzioni:

a) da una informazione si deve passare ad altre informazioni sfruttando timestamp, sql_hash, system change number, ecc.

b) se l'informazione da cui partire non è nota ci si deve basare unicamente sui timestamp.

In realtà non è solo importante usare i timestamp per la correlazione delle informazioni quanto per creare delle timeline relative a informazioni/operazioni fluite/avvenute nel database. Conviene innanzitutto usare i timestamp su oggetti e log del database, e successivamente, gli indizi basati su valutazioni dei timestamp devono essere correlati con risorse esterne (sempre Oracle), come listener.log, log di SQL*Net, trace le, etc. Infine, la valutazione
deve essere completata correlando le informazioni strettamente connesse al database con quelle del sistema operativo e di tutti gli applicativi esterni al DBMS, che in qualche modo possono restituire informazioni utili.

Nell'analisi forense di un database dovrebbe, poi, sempre essere considerato quanto segue:

1) una valutazione dell'affidabilità dei risultati (dato che non si lavora a basso livello e quindi bisogna tenere conto dell'interpretazione dei dati ricavati e del contesto in cui si svolge l'analisi)

2) una valutazione dell'effetto di uno shutdown del DBMS con conseguente possibile perdita delle fonti di prova (ad esempio, la cancellazione della shared pool) in quanto a seconda di tale effetto devono essere impostate strategie di repertamento dati ed analisi differenti

3) valutare se le procedure poste in atto dall'investigatore portano alla creazione di nuove tracce nel database: per ovvi motivi di validità dell'attività svolta tali tracce non dovrebbero esistere o quantomeno (in mancanza di scelta) essere perfettamente documentate sui vari log (e verbali nel caso di indagini penali).

Il concetto cardine è sempre quello di mantenere minima l'invasività delle procedure. Ad esempio, il semplice accesso da parte di un tecnico (o un altro evento legato all'autenticazione), può costituire un tentativo maldestro che da' luogo all'invalidazione di tutto il lavoro successivo in quanto ai risultati di modifica di dati e metadati che implica.

In particolare, in un database Oracle, è possibile autenticare sia utenti del database (database user) che utenti non del database (nondatabase user). Oracle, poi, impone delle procedure di autenticazione speciali per i DBA (DataBase Administrator), poichè queste figure eseguono sul database delle operazioni di fondamentale importanza e criticità. Inoltre, le password di Oracle vengono crittografate durante la trasmissione al fine di garantire un elevato livello di sicurezza dell'autenticazione di rete (network authentication). I comandi PL/SQL: CREATE USER, ALTER USER e quelli che prevedono la clausola IDENTIFIED BY, possono essere impiegati per gestire utenti e password(s) (basta riferirsi all'ampia documentazione disponibile online e sui "sacri" testi di Oracle nella versione in uso). La resistenza dei meccanismi di protezione di Oracle è argomento di profondo interesse dal punto di vista del forensics, ma vediamo di seguito.

Oracle fornisce un set di protezioni built-in (incorporate) mirate a proteggere le password utente. I meccanismi di protezione sono:

- Password cifrate: Le password sono crittografate in modo automatico e trasparente durante le connessioni di rete (clent-server e server-server). A tal fine viene utilizzato l'algoritmo AES (Advanced Encryption Standard) prima che la password sia inviata attraverso la rete.

- Controllo complessità della password: Nelle installazioni di default,
Oracle Database controlla che le password nuove o modificate siano sufficientemente complesse per prevenire che eventuali tentativi di intrusione nel sistema vadano a buon fine semplicemente indovinando la password. Inoltre, la complessità delle password è personalizzabile.

- Prevenzione cracking della password. Se un utente cerca di effettuare il login più volte usando una password errata, Oracle rimanda la possibilità di nuovi tentativi dopo il terzo errore. Questa protezione si applica anche per i tentativi provenienti da indirizzi IP differenti o connessioni multiple del client per contrastare gli attacchi ripetuti e distribuiti.

- Password case-sensitive e con salt: non è qui il caso di approfondire la tecnica dal salting delle password che comunque trova ampia documentazione su online.

- Hash di tipo SHA-1: Oracle impiega l'algoritmo di hashing SHA-1 (anch'esso ampiamente documentato online) per verificare la password e stabilire la sessione dell'utente.

L'autenticazione in un database Oracle tramite password è il meccanismo con cui si ha attualmente più a che fare nel tentativo di svolgere indagini tecniche. Risulta determinante che l'operatore forense conosca i metodi basilari per l'ottenimento delle password o quantomeno di valori loro correlati impiegati dal sistema di accesso. Più che di cracking è bene parlare di recupero password, in quanto lo scopo è entrare nel sistema realizzando il minor numero di alterazioni possibili e contemporaneamente tracciare l'attività svolta nel migliore dei modi. Tale operazione può avvenire seguendo due differenti approcci: la live analysis e la post-mortem analysis.

Nel primo caso l'istanza del DBMS Oracle è attiva ed il server in funzione, mentre nel secondo il server è un oggetto che è stato informativamente repertato a diversi livelli e poi spento. Al contrario di quanto si possa pensare la post-mortem analysis consente di operare con notevoli risultati sui valori di hash delle password recuperandoli dal file di database, ciò senza correre il rischio di alterare quanto repertato (l'immagine del database e del server). Ovviamente deve essere possibile buttare giù l'istanza e spegnere il server senza che avvengano alterazioni di grande profilo e questo spesso è difficile, da cui l'impiego dei tool che operano in live.

Per finire, lo scopo dell'operatore forense è il più delle volte accedere al database con il massimo dei privilegi consentiti, ossia autenticandosi come SYSDBA. Il target del recupero password, quindi, riguarda per la maggioranza la classe dei SYSDBA.

marcomattiucci.it

Informatica:

Digital Forensics - articoli:

Digital forensics: