Analisi forense su Oracle - premessa

Sbaglia chi crede che i propri sistemi informatici siano inattaccabili, anche quando siano state adottate tutte le misure di prevenzione possibili. Come ho già avuto modo di dire in un precedente post, il difensore deve agire sempre senza sbagliare, tenendo costantemente sotto controllo aggiornamenti, falle, utenti; all'attaccante basta una singola breccia nelle strutture poste a difesa per penetrare nel sistema.

Succederà dunque che - prima o poi - un aggressore avrà successo. A seconda della gravità delle operazioni compiute, la vittima dell'intrusione potrà decidere di considerare il fatto come un incidente, oppure di denunciarlo agli organi competenti.

In quest'ultimo caso sarà necessario raccogliere (in ambito investigativo) e presentare (in sede giudiziaria) le prove di un accesso illecito ai sistemi e ai dati in essi contenuti. Ciò avviene solitamente nell’alveo della normativa che sanziona direttamente i reati di natura informatica (introdotto con la Legge n. 547 del 23 dicembre 2003 e successivamente integrati pienamente nel Codice Penale), quelli relativi allo spionaggio industriale e militare mediante l’utilizzo di sistemi informatici (disciplinati da specifici articoli del Codice Penale), nonché quelli che ledono il diritto alla privacy e alla tutela dei dati sensibili (Legge n. 196 del 30 giugno 2003).

Riguardo alla raccolta di prove di accesso non autorizzato a una base dati, va detto che il più delle volte è sufficiente ricorrere ai log di sistema o agli audit trail. Esistono però le eccezioni: sistemi su cui non viene tenuta traccia dei login e delle operazioni; disattivazione di logging e auditing a opera dell'aggressore; cancellazione delle tracce d'accesso (evento meno frequente perché richiede più tempo e maggiori competenze, ma per questo più sofisticato). In questi casi si fa allora ricorso all'analisi forense sui sistemi, compresa l'indagine diretta sul database.

Con questa breve serie intendo introdurre le tre principali tecniche di analisi forense su un database Oracle. Tutte e tre si basano sull’analisi dei Redo Logs, ma con diverse modalità. Queste tecniche non sono ovviamente le uniche, ma rappresentano quelle di indagine più "generale". Inoltre, pur essendo utilizzate su sistemi Oracle, sono adattabili anche agli altri DBMS, fatte salve le debite differenze e peculiarità nella gestione dei dati archiviati.

Non entrerò nel dettaglio delle operazioni da compiere e delle procedure da seguire per garantire l’evidenza di prova delle informazioni ottenute, volendo solo offrire una panoramica sull’utilizzo di tecniche comuni che traggono beneficio dalla versatilità degli strumenti forniti dai moderni DBMS relazionali. Rimando a futuri post gli opportuni approfondimenti.

Molto di questo materiale è frutto delle ricerche di Pete Finnigan, Paul Wright e David Litchfield, autentiche autorità in materia, ai quali rinvio per tutti gli approfondimenti del caso.


I Redo Logs

Lo sviluppo del DBMS relazionale di Oracle è stato incentrato sul concetto di resilienza, ovvero di capacità di resistere agli eventi negativi (di qualunque natura, dunque anche dolosa) senza perdere la capacità di continuare a funzionare. Parte di tale strategia è stata realizzata mediante i cosiddetti Redo Logs. Ogni volta che si effettua una modifica sul database, per esempio la creazione di una tabella, o l’aggiornamento dei campi di una riga, il processo in background denominato Log Writer (LGWR) aggiunge un record al file corrente di log. In tal modo, in caso di eventuale problema tecnico o corruzione dei dati sarà possibile ripetere le modifiche registrate.

Più nello specifico, le modifiche apportate al database sono mantenute in appositi buffer circolari nella memoria globale di sistema (SGA) di Oracle, per essere registrati dal Log Writer nei Redo Logs ogni tre secondi, o immediatamente dopo un comando COMMIT. I Redo Logs possono essere due o più, e sono di dimensione prefissata. Quando il Log Writer ha raggiunto il limite del log corrente passa a quello successivo; quando tutti i log sono pieni, il Log Writer ricomincia dal primo, sovrascrivendolo. Per evitare di perdere le registrazioni precedenti è possibile attivare in background il processo di archiviazione (ARCH), che si occupa di archiviare un file di log quando questo viene riempito. Una istanza di Oracle che abbia il processo di archiviazione attivato è detta operare in modalità ARCHIVELOG; se non è attivato, la modalità è detta NONARCHIVELOG (si veda in proposito la Oracle 10g database administrator’s guide).

Questo processo di registrazione delle operazioni è utile anche nel caso si cerchino le tracce di un eventuale aggressore. Appare ovvio che la modalità ARCHIVELOG offre maggiori possibilità di recuperare prove, soprattutto per quei database soggetti a traffico di dati e transazioni ad alta intensità (telefonia, grandi portali di e-commerce ecc.) nei quali i Redo Logs verrebbero riscritti con frequenza elevata; ma proprio in questi casi l’overhead per la scrittura e l’archiviazione dei log è considerato punto critico per le prestazioni, e spesso si scende a compromessi tra l’esigenza di velocità e la necessità di tenere traccia delle operazioni effettuate. È per questo che a volte un’analisi accurata non produce risultati soddisfacenti. Risulta quindi fondamentale l’intervento investigativo nel più breve tempo possibile, nel tentativo di minimizzare la possibilità della cancellazione o della perdita di tracce.

Abbiamo visto cosa sono e a cosa servono i Redo Logs. Nei prossimi post vedremo come usarli per recuperare le tracce di una violazione.