Analisi forense su Oracle - dump dei file di log

La prima delle tecniche di analisi forense di cui parlerò è basata sull'esportazione (dump) del contenuto dei Redo Logs in formato ASCII. Oracle salva i file di log in forma binaria, per cui non possono essere letti direttamente. Con i log riportati in formato ASCII è possibile ricostruire la sequenza di operazioni compiute durante la violazione, facendo ampio ricorso alle espressioni regolari per la ricerca nel testo.

Per ottenere l'esportazione occorre inviare il comando :

alter system dump logfile 'pathcompletodelfile'

Si noti che il path del file di log deve essere incluso tra apici. Inoltre occorre ovviamente possedere i necessari privilegi per la alter system. È anche possibile limitare l'esportazione a una porzione dei dati, specificando gli estremi iniziale e finale di data temporale, di indirizzi di blocchi di dati o di indirizzi di record di redo (identificati da un numero di sequenza e un numero di blocco).

L'esportazione può essere fatta anche da un database esterno (soluzione preferibile in ambito investigativo), purché entrambe le istanze appartengano alla stessa versione di Oracle.

Per identificare il Redo Log corrente si può usare il seguente codice:

SELECT member FROM v$logfile WHERE group# = (SELECT group# FROM v$log WHERE status = 'CURRENT');

La tecnica di dump, pur essendo relativamente banale e quindi adatta ai casi più semplici, non è purtroppo sempre attuabile. L'investigatore potrebbe non avere accesso a un server Oracle per effettuare l'esportazione; e l'ipotesi di utilizzare il DB server violato è da scartare, perché l'operazione di dump scrive ampie sezioni di disco: si potrebbero distruggere elementi essenziali alle indagini, quali le tracce di file cancellati dall'aggressore.

Inoltre, quando il LogWriter passa da un file di log al successivo per esaurimento dello spazio assegnato (vedi post precedente), il log sequence number viene incrementato. Poiché il dump del file esporta solo i record corrispondenti al numero di sequenza corrente, esso ignora i record registrati con i numeri di sequenza precedenti, facendo così perdere delle evidenze che potrebbero essere importanti.

Infine, dalla versione 9 di Oracle il testo dei comandi DDL quali CREATE, ALTER, DROP, GRANTREVOKE, pur essendo registrato nei Redo Logs, non viene esportato dall'operazione di dump. Ciò sottrae all'investigatore degli elementi fondamentali, limitandone l'operato.

Nonostante questi ostacoli, il dump dei log rimane valido per una prima ricognizione. In effetti, più che dagli investigatori forensi, viene spesso utilizzato dai DBA per operazioni di ripristino a seguito di operazioni errate. Dal prossimo post, comunque, esamineremo strumenti e tecniche più efficaci per l'analisi forense su Oracle.

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.

SQL injection: le contromisure

Nel post precedente abbiamo visto quanto sia facile attaccare un database mediante una SQL injection, pur avendo scalfito solo la superficie di questa tipologia di attacchi. Adesso vediamo quali sono le contromisure generali da adottare per limitarne l'impatto. Le linee d'azione da seguire sono raggruppabili in due fronti: ridurre le vulnerabilità dell'applicazione e monitorare gli attacchi in corso.


Ridurre le vulnerabilità dell'applicazione

Come già detto, la SQL injection agisce mediante l'applicazione web, e i suoi effetti saranno tanto maggiori quanti più privilegi saranno stati assegnati all'account con cui si connette al database. Analizzando le tecniche usate dagli aggressori, col tempo si sono adottate varie misure per contrastarne gli effetti. Elenco quelle che si sono dimostrate più efficaci:

• convalidare tutti gli input inseriti nei form, e purgarli di caratteri e stringhe particolari che non dovrebbero farne parte (per esempio gli asterischi, i segni di uguaglianza, i punti e virgola, gli identificativi di commento ecc.);

• evitare il più possibile le stringhe concatenate per generare i comandi SQL da inviare al database, cercando per quanto possibile di passare i dati di input come parametri, ricorrendo per esempio a prepared statements, parameter collections e parameterized stored procedures (non mi dilungo nelle spiegazioni, per le quali è sufficiente una ricerca su internet);
  

• ricorrere a una stored procedure sicura per il login dell'applicazione, evitando l'uso di una query dinamica;

• usare pacchetti che testano in automatico la vulnerabilità alla SQL injection, come quelli segnalati qui. Anche quelli che effettuano i test più semplici possono tornare utili per individuare falle nell'applicazione;
  

• ridurre i privilegi di accesso dell'applicazione. Se questa accede al database per compiti diversi (amministrazione, inserimenti, reporting ecc.) e in contesti diversi (come i diversi dipartimenti o uffici di un'organizzazione), gli sviluppatori dovrebbero rinunciare a un'unica connessione indistinta con ampi privilegi, per ricorrere a più connessioni limitate ad hoc. Se ciò non è possibile (perché magari l'applicazione è già stata completata e non può essere modificata per qualsiasi ragione), chi amministra il database dovrebbe fare in modo di identificare i privilegi minimi comuni a tutti gli utilizzatori dell'applicazione per "blindare" opportunamente la connessione.
  

Monitorare gli attacchi

Le SQL injection più pericolose non vanno a segno al primo colpo, ma richiedono più prove in successione, nel tentativo di allineare la query inviata con i campi a cui si sta cercando di accedere (in particolare, l'attaccante deve identificare gli attributi e i tipi di dato). Questi tentativi potrebbero essere identificati dall’amministratore del sistema, magari in tempo reale usando appositi tool, dandogli così il tempo di correre ai ripari. L’identificazione può avvenire in vari modi:

• riconoscendo le “signatures” di un attacco: l’uso di un IDS (Intrusion Detection System) che supporti anche l’individuazione di intrusioni su basi dati può agevolmente intercettare sezioni di stringhe SQL non conformi come le identità, le UNION, o le condizioni WHERE che seguono indicatori di commento (segno di un troncamento deliberato di una query). Questa soluzione non è purtroppo ottimale, sia per la percentuale di falsi positivi (per esempio una UNION potrebbe essere legittima) sia per la vasta casistica di stringhe di injection che bisognerebbe controllare;

• ricevendo segnali di errore SQL dal DBMS: solitamente un’applicazione entrata in produzione dopo una seria fase di test non genera errori sul numero di attributi di una SELECT, sulla mancata chiusura di apici o sulla conversione di tipo di dato, che rappresentano invece il segnale di allarme di un attacco in atto. Occorre pertanto monitorare costantemente gli errori ritornati dal DBMS. A tale proposito, sarebbe buona norma segnalare gli errori SQL solo al DBA e mai all’utente dell’applicazione (se non genericamente), perché sono fonte di informazioni sullo schema e sul funzionamento del database;

• confrontando il codice SQL con una “baseline”: poiché l’applicazione ripeterà sempre gli stessi tipi di operazione, e quindi gli stessi comandi SQL, è possibile stilare un elenco di riferimento di queste operazioni - la baseline per l'appunto - con cui confrontare ogni successiva stringa SQL. Se questa si discosta dalla baseline, si genera un allarme. Questo metodo può essere applicato mediante un SQL firewall, che oltre a identificare una probabile injection potrà bloccarla;

• mediante l’analisi dei log: in quest'ultimo caso l’attacco ha già avuto luogo (con successo o meno), e le operazioni compiute dall’aggressore sono state registrate nei file di log (se non sono stati cancellati per eliminare le tracce), che potranno essere analizzati per ricostruire l'accaduto e intervenire sulle falle sfruttate per l'attacco.

Sul web esiste moltissimo materiale per approfondire l'argomento, che non è certo nuovo e neppure è una tecnica alla portata di pochi (è una delle prime imparate dagli script kiddies). È così sconfortante allora osservare quanto facilmente abbia successo... persino con i siti di tante università che insegnano informatica!

SQL injection: cos'è, come funziona

Oggi introdurrò una delle peggiori minacce per la sicurezza dei database, la famigerata SQL injection. Comincerò parlando del suo funzionamento, per proseguire in un prossimo post con le tecniche più efficaci per evitarla.

Scenario abituale: quando su internet compiliamo i campi di un form, l'applicazione web solitamente concatena il nostro input a una stringa SQL. I nostri dati andranno a formare la clausola WHERE, allo scopo di operare su un subset di record del database.

Per esempio, in un form di login tipicamente inseriremo qualcosa del tipo:

username: pippo

password: pluto

L'applicazione ha pronta una stringa contenente il comando SQL da completare coi dati dell'utente e da inviare al database, nella forma:

SQLstring = "SELECT IDutente FROM tab_Utenti WHERE IDutente = '" & username & "' AND pwd = '" & password & "'"

che verrà completata dal nostro input in:

SQLstring = "SELECT IDutente FROM tab_Utenti WHERE IDutente = 'pippo' and pwd = 'pluto'"

La SQL injection è una tecnica che sfrutta questo funzionamento delle applicazioni web (ma non solo) per portare un attacco al database di back-end, mediante l'inserimento di codice apposito - non previsto dal programmatore dell'applicazione.

La SQL injection è quasi sempre associata alle applicazioni web perché queste si basano su un'architettura a tre livelli (client - web o application server - db server): il cosiddetto middle tier usa un pool di connessioni verso il database, per cui i login avvengono a livello di applicazione più che di database (più deboli perché spesso i programmatori gli associano ampi privilegi sugli oggetti del database). In un sistema client/server, invece, il login nell'applicazione è sostanzialmente allineato al login nel database e in buona parte le tecniche che vedremo non si applicano.

Per i prossimi esempi faremo riferimento a SQL Server di Microsoft, come del resto fanno molti altri siti, libri e articoli che trattano l'argomento. Questo non significa che il problema sia circoscritto a questo DBMS: poiché la SQL injection sfrutta una vulnerabilità dell'applicazione, non del database stesso, tutti i DBMS ne sono soggetti. Tuttavia, SQL Server offre ai suoi utilizzatori un dialetto del SQL molto ricco, il Transact-SQL, le cui funzionalità aggiuntive si sono purtroppo dimostrate utili anche per scopi non previsti; noi le useremo per studiare il funzionamento di questo tipo di attacco. Ripeto, tutti i DBMS possono subire una SQL injection, tanto che gli esempi seguenti sono adattabili - con le dovute modifiche - a ogni database.

Riprendiamo l'esempio iniziale del form di login, e immaginiamo di avere un'applicazione web che riceve in input username e password per verificare se l'utente esiste nella tabella tab_Utenti e se ad esso è associata (mediante il testo contenuto nel campo pwd della tabella) la password digitata. Assumiamo inoltre che (1) l'applicazione non effettui alcuna validazione sull'input dell'utente, e (2) che il comando SQL inviato dall'applicazione al database sia generato mediante concatenazione. Riprendiamo la stringa SQL:

SQLstring = "SELECT IDutente FROM tab_Utenti WHERE IDutente = '" & username & "' AND pwd = '" & password & "'"

La nostra applicazione potrebbe autenticare o meno l'utente in base al risultato restituito dal database. Se il risultato della SELECT è una stringa vuota, l'utente è rifiutato; altrimenti, è autenticato. In questo caso, sarà sufficiente inserire in input queste stringhe:

username: ' OR ''=''

password: ' OR ''=''

per inviare al database:

SELECT IDutente FROM tab_Utenti WHERE IDutente = '' OR ''='' AND pwd = '' OR ''=''

La condizione ''='' (un'identità) è sempre verificata, per cui il database non restituirà una stringa vuota, e l'applicazione di conseguenza autenticherà l'utente, pur non conoscendo né un nome utente valido, né la password corrispondente.

Non ci credete? Provate con un qualsiasi db, per esempio Access. Prendete una tabella già popolata, e impostate la selezione sulla chiave primaria per un valore non esistente. Per esempio, una tabella tab_Clienti, la cui chiave primaria IDCliente non contenga il valore 0:

SELECT * FROM tab_Clienti WHERE IDCliente = 0;

Questo comando restituirà un subset vuoto. Se invece aggiungiamo un'identità in coda:

SELECT * FROM tab_Clienti WHERE IDCliente = 0 OR ''='';

il database ci restituirà tutti i record della tabella. Semplice, no?

Immaginiamo ora che l'applicazione effettui qualche tipo di validazione sull'input, per esempio sulla lunghezza della password inserita. In questi casi torna utile il segno di commento dei dialetti SQL: in SQL Server è "--", per cui tutto ciò che segue il segno viene ignorato dal DBMS. Allora, inserendo:

username: ' OR ''='' --

password: boh!

il DBMS riceverà questo comando SQL:

SELECT IDutente FROM tab_Utenti WHERE IDutente = '' OR ''=''

e, di nuovo, l'utente sarà autenticato, a dispetto del controllo sulla password.

In una variante più insidiosa, l'uso dei commenti è associato con la possibilità di concatenare più comandi SQL nella stessa stringa:

username: ' ; DROP TABLE tab_utenti ;--

password: boh!

da cui al DBMS:

SELECT IDutente FROM tab_Utenti WHERE IDutente = '' ; DROP TABLE tab_Utenti ;

e voilà, la tabella degli utenti se n'è andata...

Un'altra tecnica in voga è quella di accodare all'input una UNION ALL SELECT ... per estrarre i dati da una qualsiasi tabella del database e accodarli ai record restituiti dalla query originale.

Per finire, un accenno a un uso molto sofisticato della SQL injection, in congiunzione a un buffer overflow. Come tutti i software basati su linguaggi quali il C e il C++, anche i DBMS sono naturalmente soggetti al problema del buffer overflow. Esso si presenta quando il programmatore non verifica che la lunghezza dei dati non ecceda la dimensione del buffer in uso. In una tale eventualità, i dati andranno a sovrascrivere zone dello stack, con risultati imprevedibili per il funzionamento del sistema.

Per questo tipo di attacco non è neppure necessario approfittare di una stringa concatenata, come per gli esempi precedenti. Solitamente si sfruttano funzioni interne al DBMS, di cui sia nota la vulnerabilità a un buffer overflow (per esempio passando mediante SQL injection una stringa opportuna come parametro). Sovrascrivendo lo stack si può ottenere un denial of service; ma il "meglio" si ottiene preparando la stringa affinché inserisca codice malevolo e sostituisca l'indirizzo di ritorno della funzione chiamante, in modo tale da eseguire il codice inserito. Si potrà in questo modo tentare, per esempio, la scalata ai privilegi di amministratore sulla macchina. Per avere un'idea di quello che si può fare col buffer overflow, è interessante leggere Smashing the stack for fun and profit, dal n. 49 di Phrack.

Concludo qui, anche se le tecniche di SQL injection sono molto varie, e sul web si possono trovare decine di altri esempi, tutti interessanti. In questa sede era importante spiegarne la logica di funzionamento, per potere poi trattare a breve le contromisure da adottare per contrastarle. Alcune probabilmente vi sono già venute in mente, vero?

I database applicati ai documenti medievali

Qualche settimana fa il titolo di un libro ha attirato la mia curiosità: Storia e informatica: i database applicati ai documenti medievali, di Massimo Sbarbaro (edizioni CERM, 2007).

Dopo essermi procurato il libro mi sono immerso nella lettura. A parte l'interesse per i database, come molti sono affascinato dal periodo medievale, pur avendone soltanto la conoscenza tipica dell'uomo della strada. Un'epoca spesso descritta come buia, violenta, profondamente ignorante e superstiziosa. Salvo poi scoprire che molte delle situazioni del nostro vivere quotidiano hanno profonde radici proprio in quell'epoca.

Ne è un esempio il ruolo dei notai: dal libro si apprende, tra le altre cose, che nell'XI secolo si era prodotta un'importante evoluzione nella scrittura notarile rispetto a una tradizione che si tramandava fin dal V secolo (non lo avrei mai immaginato); fu però nel secolo successivo che la professione notarile acquisì la sua importanza nella vita pubblica comunale, con l'adozione dell'instrumentum (atto notarile in tre passaggi) e il ricorso ai manuali di ars dictaminis. Ma nel XIII secolo si verifica il vero punto di svolta, quando la Summa totius artis notarie di Rolandino de' Passeggeri diventa il manuale di riferimento, grazie alle centinaia di esempi di contratti pubblici e privati in esso contenuti. Il lavoro dei notai risultava facilitato, e con la diffusione della Summa si ebbe un aumento esponenziale delle scritture pubbliche e private, tuttora custodite negli archivi storici (se non ricordo male in qualche punto si parla di milioni di documenti!). Con la sua opera Rolandino riuniva teoria e pratica della professione notarile; ma la sua strutturazione delle tipologie documentarie si sarebbe rivelata altrettanto preziosa per adottare la teoria dei database nello studio degli archivi storici.

Lo scopo dichiarato del libro è infatti di dimostrare ai ricercatori che i database non sono utili solo per indagini quantitative, come si è sempre creduto, ma che possono portare a risultati di grande interesse anche nelle indagini qualitative. Nel caso dell'attività notarile, per esempio la ricostruzione del paesaggio agrario medievale; l'evoluzione delle culture giuridiche nelle aree oggetto di studio; la complessa struttura della monetazione dell'epoca.

La prima metà del testo è dedicata alla figura del notaio medievale, ai documenti che produceva, e alle persone che a vario titolo vi partecipavano. La seconda metà introduce la teoria delle basi dati, il modello entità-relazione, e la sua applicazione pratica alla mole documentale disponibile, che ha consentito di incrociare e confrontare tra loro i dati in essa contenuti. Ampio spazio è dato in questa parte alla progettazione concettuale e logica del database, e sono raffigurati anche i principali schemi logici scaturiti dall'analisi delle questioni da affrontare. Tra queste, le maggiori difficoltà incontrate hanno riguardato la monetazione, i toponimi, ma soprattutto le confinazioni dei lotti di terreno, quest'ultime in parte ancora irrisolte.

Per concretizzare rapidamente il progetto, l'autore ha fatto ricorso a Microsoft Access, pur conscio dei suoi limiti tecnici. La scelta potrebbe fare storcere il naso, ma è invece a mio parere totalmente giustificata dalla necessità di avere uno strumento che offrisse contemporaneamente facilità d'uso e le funzionalità di archivio, di interfaccia e di programmabilità con pochi sforzi, per dedicare tempo e risorse all'acquisizione dei dati. Il libro non vuole mostrare lo stato dell'arte nell'integrazione tra storia e informatica, ma presentare un approccio metodologico che porti risultati apprezzabili. Nel testo si accenna in proposito al problema della gestione delle immagini digitalizzate dei documenti, che sarebbe stato efficacemente risolto usando un DBMS più "serio"; ma nulla vieta, una volta tracciata la strada, di adottare in futuro soluzioni più robuste e performanti. Comunque il libro si limita solo a un paio di schermate delle interfacce realizzate e a qualche rapido accenno sulla progettazione fisica, in quanto aspetto secondario e conseguente a quella logica, ben più complessa.

A questo riguardo l'autore fa notare che molti tentativi simili sono falliti, o non hanno fornito risultati soddisfacenti, proprio perché portati avanti in modo improvvisato, costruendo la struttura degli archivi informatici come un semplice contenitore, senza alcuna scientificità. In questo lui dimostra invece di avere operato in modo incredibilmente efficace, e come ingegnere informatico non posso non congratularmi con lui per il lavoro svolto.


Ho letto che Sbarbaro è docente di Informatica per la storia medievale all'Università di Trieste, indice di un certo livello di competenza in entrambe le materie. Da quanto riportato nel risvolto del libro, la sua formazione è umanistica, e le sue pubblicazioni tutte di carattere storico; eppure mi ha stupito il rigore con cui ha affrontato lo studio dei database. Certo si è basato sull'ottimo libro di Atzeni, Basi di dati, che cita spesso e che è diffuso come testo principale nei corsi di basi dati all'università (uno dei pochi autori italiani presenti nelle bibliografie straniere). E comunque dimostra di padroneggiare con sicurezza i principi matematici su cui è basata l'algebra relazionale, e questioni non semplici (spesso ignorate) come le fasi di progettazione concettuale e logica, o la normalizzazione dei dati.

Mi chiedo se le pagine dedicate alla teoria dei database siano effettivamente utili per gli storici che vogliano intraprendere la strada indicata. Quelle presenti sono appena sufficienti per una introduzione, e forse uno studioso che non abbia dimestichezza con questi strumenti si ritroverà con qualche dubbio in più, per quanto l'autore sia effettivamente molto chiaro (e preciso, nonostante qualche svista di poco conto) nella trattazione. Tuttavia i paragrafi sulla teoria delle basi dati hanno il pregio di chiarire che, dietro le interfacce, esiste una scienza rigorosa con cui bisogna confrontarsi per ottenere i risultati attesi. Gli studiosi interessati potranno sempre rivolgersi ai testi specializzati, primo tra tutti quello di Atzeni.

Chiude il libro una breve ma interessante appendice su Pietro Ispano (poi papa Giovanni XXI) e sui suoi fondamentali studi di logica. Il suo "se... allora.." consentì all'epoca di superare lo stallo portato dai terministi al sillogismo aristotelico (questioni filosofiche in cui non mi addentro...); e a distanza di 700 anni è diventato l'asse portante delle strutture logiche dei linguaggi di programmazione. Curioso, no?

Leggendo il libro, ho notato che il metodo suggerito è adattabile anche ad altri tipi di documenti. Si pensi per esempio alla sterminata produzione epistolare del due volte premio Pulitzer Norman Mailer, recentemente scomparso. Mailer (nomen omen) era un grafomane assoluto: circa 40.000 lettere scambiate con quasi tutti i personaggi celebri della seconda metà del XX secolo, raccolte in un archivio privato ceduto (per due milioni di dollari!) all'Università del Texas. Il percorso descritto nel testo di Sbarbaro può offrire ottimi spunti per l'opera di catalogazione, che consentirebbe ricerche dai risultati molto interessanti.

Sbarbaro Massimo, Storia e informatica: i database applicati ai documenti medievali, CERM, Trieste 2007, pag. 214, € 26.
ISBN: 978-88-95368-02-3

(Il libro può essere ordinato direttamente dal sito del Centro Europeo Ricerche Medievali)

Comunicare in azienda per migliorare i processi

Ci siamo passati tutti: i piani alti dell'azienda hanno preso delle importanti decisioni con sostanziose ricadute sulle infrastrutture informatiche, senza consultarci. Ci siamo sentiti scavalcati, ignorati, trattati come l'ultima ruota del carro. Abbiamo vissuto il fatto come un'umiliazione della nostra professionalità e delle nostre competenze, lamentando la poca considerazione di cui gode la professione del tecnico informatico agli occhi del management aziendale. E poi ci siamo ritirati brontolando nel nostro ufficetto a configurare un server e a lanciare una sessione di test, aspettando la notifica delle nuove specifiche da adottare.

Non mi interessa parlare qui delle ragioni di questa scarsa considerazione. Ma ammettiamolo, a volte è anche colpa nostra. A questo proposito, parlavo tempo fa con il direttore di uno stabilimento. Gli avevo chiesto su quali competenze informatiche interne all'azienda potessimo contare per un piccolo progetto da avviare. "Conosco poco quelli del CED" fu la sua risposta, perché si accorgeva della loro esistenza solo dalle continue richieste di fondi per gli acquisti e per le lamentele sugli utenti, sulle password e "qualcos'altro che adesso non ricordo". Siamo onesti: non ci riconosciamo, almeno in parte, in questo quadretto?

Potremmo obiettare che forse chi comanda dovrebbe comunque conoscere i suoi uomini; ma non è questo il punto. Il ruolo del reparto IT dovrebbe essere quello di supportare a livello informatico i processi aziendali: portare soluzioni, non creare nuovi problemi. Se i livelli superiori tendono a escluderci dai processi decisionali che ci dovrebbero riguardare, cerchiamo il modo di intervenire. Positivamente. Mai in modo conflittuale.

Per proporre un caso concreto, legato al tema di questo blog, pensiamo alle norme sempre più stringenti su privacy e sicurezza dei dati. La nostra azienda potrebbe finalmente decidere di adottare misure adeguate (magari perché costretta...); oppure potrebbe sentire l'esigenza di certificarsi per l'ISO 27001. Riunione dopo riunione, le decisioni alla fine sono prese. E a conti fatti, ci arrivano le richieste - magari in conflitto tra loro perché fatte da responsabili di settori diversi - di adattare i sistemi alle nuove specifiche.

Avremo due possibilità: mugugnare sul lavoro da fare che porterà inevitabilmente una serie di nuovi problemi; oppure avviare un canale di collaborazione e comunicazione aziendale. In entrambi i casi il lavoro sarà fatto, ma i risultati saranno di gran lunga diversi.

Scartiamo la prima ipotesi, e concentriamoci sulla seconda. Raccogliamo le richieste che ci sono state fatte:

• riflettiamo su come implementarle: gli strumenti a disposizione sono sufficienti? L'acquisto di nuovo hardware/software porterebbe a un miglioramento quantificabile? Saranno necessari dei corsi di formazione e aggiornamento specifici per gli amministratori dei sistemi e per gli utenti? In tal caso, basteranno dei corsi tenuti da personale interno, o sarà più opportuno rivolgersi a consulenti esterni?
  

• valutiamo i possibili inconvenienti che potremmo incontrare, sia prima che dopo: l'implementazione richiederà modifiche di portata limitata, o saranno necessari cambiamenti radicali nell'infrastruttura? Abbiamo le competenze necessarie per farlo? È consigliabile una fase di test, o sarà necessario portare immediatamente i sistemi a livello operativo, accettando un margine di rischio di malfunzionamenti?
  

• valutiamo l'impatto che avrà l'adozione delle nuove specifiche sul lavoro quotidiano: come prevediamo che saranno accettate le nuove regole d'uso da parte degli utenti? È possibile semplificarle in qualche modo? Tutti i dirigenti, fino ai massimi livelli, sono pronti ad adottarle diligentemente a loro volta?
  

L'aspetto fondamentale di questa analisi non è solo individuare le criticità del progetto, ma proporre delle soluzioni fattibili. A questo punto avremo tutti gli elementi per stilare un rapporto da inviare a tutti i dirigenti coinvolti dal progetto, in spirito di collaborazione. Non deve essere necessariamente un dettagliatissimo mattone di centinaia di pagine: poche pagine ben scritte si faranno leggere più facilmente, e ci sarà sempre l'occasione per un eventuale approfondimento.

Al primo rapporto potranno seguirne altri per aggiornare i dirigenti sui progressi del progetto, sulle difficoltà impreviste che si sono incontrate e su come sono state superate (in tono piano, evitando espressioni imbarazzanti del tipo "grazie alle mie conoscenze tecniche...").

Se lo stile sarà correttamente propositivo, non interpretabile come una risposta polemica alle nuove esigenze aziendali, l'effetto sarà positivo. Magari si avvierà una discussione interna basata sulle nostre considerazioni per valutare meglio la portata del cambiamento; e forse saremo finalmente visti come una risorsa capace di collaborare, degni di essere consultati per le prossime decisioni.

E se l'effetto sarà opposto? Può succedere, purtroppo non tutte le aziende sono guidate da persone capaci di riconoscere e apprezzare adeguatamente i propri collaboratori. Sta a noi decidere se pretendere di meglio per la nostra professionalità, o se tornare a mugugnare in sala server.

Masterizzare e cifrare i dati in un'unica soluzione

La Soft-R Research LLC, presente al CES 2008 appena concluso, ha realizzato un CD con un software di masterizzazione integrato, che consente di salvare direttamente i dati in maniera criptata. In Italia il CD è commercializzato da TX Italia (a quanto so in confezione da 3 CD a 14,99 euro).

L’uso è volutamente molto semplice: il supporto è un normale CD-R standard al cui interno è presente un piccolo wizard di masterizzazione che non necessita di installazione. Il wizard crea un singolo file "cassaforte" che andrà a contenere i file/cartelle da cifrare. La struttura della "cassaforte" prevede una struttura di controllo della cifratura che usa l'algoritmo di codifica AES a 256 bit in modalità Cipher-Block Chaining (CBC) e una parte dedicata ai dati, formattata in FAT.

Per accedere ai dati masterizzati occorrerà ovviamente la password (lunghezza massima 64 caratteri). Il CD dovrebbe includere inoltre un visualizzatore d'immagini sicuro, ed essere in grado di cancellare automaticamente tutti i file temporanei generati durante la scrittura/lettura dei dati.

Il software di masterizzazione è compatibile con Windows 2000, XP e Vista e con i masterizzatori che supportano i comandi della Microsoft Management Console (tipicamente quelli fabbricati dopo il 2000).

Si insinua un dubbio sul potenziale utilizzatore di questi CD. Escluderei le aziende che hanno adottato una seria politica di sicurezza, perché sicuramente seguono una procedura d'archiviazione che prevede la cifratura (nulla vieta tuttavia di adottare proprio questi CD per l'archiviazione cifrata...). Restano le piccole imprese, il cui uso della tecnologia informatica è spesso estemporaneo e non pianificato; quindi i privati, che potrebbero trarre vantaggio da questa soluzione tecnologica per scopi leciti, ma anche - e soprattutto - illeciti (curioso in tal senso il visualizzatore di immagini sicuro...).

In questi casi, l'analisi forense diventa praticamente impossibile, come afferma Roberto Galasso nel suo blog Digital Forensics a proposito già dell'algoritmo AES a 128 bit. I criminali più esperti di tecnologie non aspettavano certo questi CD per nascondere i loro dati, ma ora anche tutti gli altri avranno - purtroppo per gli investigatori - uno strumento in più per difendersi dalle eventuali indagini.

Il dato "malandrino"

Capita di fare scoperte curiose dove non le aspetti. Per esempio, basta andare sul sito della Microsoft, e inserire "sicurezza dei dati" nel form di ricerca. Live Search restituisce 33.800 pagine (solo in italiano), e al primo posto riporta "Sicurezza dei dati: diversi aspetti", un editoriale di Maurizio Cunico pubblicato l'anno scorso. Un articolo di taglio introduttivo, che correttamente - non so quanto volutamente - viene proposto come prima lettura.

Ma ecco la prima sorpresa: gli sviluppatori talvolta dimenticano che il dato "è un oggetto complesso, a volte sfuggente, a volte malandrino". Malandrino?! Perché non birbante, o canaglia? Birichino! O monello... Oddio, niente di grave, l'immagine è pure simpatica; ed è chiaro che Cunico intende stimolare il lettore a non affrontare con leggerezza la gestione dei dati. Quello che mi ha colpito è leggere quella frase così "informale" sul sito di un'azienda che trasmette un'immagine di sé seria e "controllata", quasi istituzionale.

Le vere sorprese arrivano dopo, leggendo l'articolo.

La pagina è inserita tra le risorse MSDN, ed è chiaramente rivolta agli sviluppatori. Chi si occupa di sicurezza dei database sa che spesso costoro considerano la base dati come un'appendice della loro applicazione. Non potrebbe neanche essere altrimenti, almeno dal loro punto di vista: per applicazioni di un certo livello la gestione del database è compito del DBA, e la sicurezza dei sistemi - nel migliore dei casi - di qualcun altro. Dovrebbe essere il project manager a coordinare le esigenze e il lavoro di queste persone, affinché la sicurezza sia uno degli aspetti portanti del progetto e non una feature appiccicata magari all'ultimo momento.

Comunque è giusto che anche gli sviluppatori siano a conoscenza delle problematiche di sicurezza a cui vanno incontro le loro applicazioni e del giusto modo di affrontarle. Ben venga allora un articolo come quello di Cunico, che cerca di stabilire dei punti fermi sull'argomento. Solo che, a mio avviso, non fa poi molta chiarezza!

Nulla da dire sulle sezioni relative a integrità, distribuzione e disponibilità dei dati. Mi riferisco invece a quella intitolata "Accesso ai dati / Sicurezza dei dati". Punto per punto:

• Sicurezza nella trasmissione e nel trasferimento dei dati: la trattazione è troppo sbrigativa. Fare un accenno alle varie possibilità di cifratura del canale (SSL, tunneling SSH, IPSec, funzionalità dedicate dei DBMS) avrebbe consentito al lettore interessato di approfondire autonomamente l'argomento senza rimanere nel vago.

• Sicurezza nell’accesso alle applicazioni di gestione: sarebbe tipicamente un problema "banale"? Passi per le classiche applicazioni client/server; ma per quelle multi-tier, basati su un pool di connessioni, è opportuno allineare i modelli di gestione degli utenti tra applicazione e database. Bisognerebbe almeno dirlo.

• Sicurezza nell’accesso ai dati: di nuovo, troppa vaghezza. Se leggo di una soluzione elegante, mi vengono in mente il fine-grained access control e il labeling degli attributi. Ma l'autore stava pensando a queste soluzioni, oppure ad altre?
  

Nessun accenno a uno dei peggiori nemici della sicurezza dei database, la SQL injection, che sfrutta proprio le vulnerabilità delle applicazioni. O ai sorgenti aperti o file di configurazione con password di accesso in chiaro (succede). O ancora alla cifratura dei data at rest, cioè dei dati memorizzati, che può essere fatta certamente dal DBMS, ma anche direttamente dall'applicazione (mediante opportune librerie) in particolari ambiti in cui non si vuole consentire l'accesso ai dati al di fuori della stessa.

Non conosco Cunico, ma leggendo il suo curriculum su internet traspaiono grande professionalità ed esperienza (molto maggiori delle mie, per esempio) e gli specialisti Microsoft - è noto - sono professionisti di altissimo livello. Mi sorprende dunque tanta fretta nell'affrontare un tema così complesso, di attualità e fonte di feroci critiche rivolte proprio alla Microsoft, anche nel contesto di un articolo introduttivo.

Il pezzo è nella sezione tecnica della newsletter MSDN del 22/3/2007, ma è archiviato nella cartella degli editoriali. Un editoriale è un articolo di fondo che rispecchia le posizioni e l'indirizzo dell'editore: trovo curioso che Microsoft veda la sicurezza dei dati in questo modo.

Exploit di massa mediante SQL injection

Sul sito dell'Internet Storm Center del SANS Institute si parla di un exploit di massa che ha infettato decine di migliaia di siti internet mediante la tecnica di SQL injection. Per chi non lo sapesse, questa tipologia di attacco colpisce le applicazioni web che per funzionare si appoggiano a un database e che consentono agli utenti di inserire dati (tipo login e password). Questi dati normalmente completano una query dinamica che viene inviata al database. Se l'input non viene validato un aggressore può inserire codice ad hoc nella query per compiere azioni non previste da chi ha sviluppato l'applicazione.

Dall'analisi del Sans ISC risulta che l'attacco è simile a un altro già tentato lo scorso novembre, con risultati minori. Questa volta invece la SQL injection appare più sofisticata. In breve l'attacco:

• individua siti internet vulnerabili ad attacchi di tipo SQL injection;

• inserisce una stringa di attacco mascherata in esadecimale per evitare eventuali filtri su parole chiave (in linguaggio tecnico si parla di offuscamento) mediante un operatore CAST;

• la stringa offuscata seleziona dalla tabella sysobjects tutte le righe corrispondenti a user table; scansiona questi oggetti alla ricerca del tipo varchar (stringa) ; per ognuno di questi oggetti esegue un comando UPDATE che aggiunge del codice che rimanda gli utenti dei siti compromessi a uno specifico indirizzo web (in una seconda ondata dell'attacco il sito risultava diverso, ma il codice è lo stesso);

• il codice del sito di destinazione tenterà di sfruttare alcune vulnerabilità note dei browser degli utenti dirottati per installare sui loro pc un trojan di qualche genere.
  

L'attacco ha colpito solo SQL Server perché il codice maligno opera espressamente sulla tabella sysobjects di quel DBMS. In realtà avrebbe potuto avere effetti più generali se avesse sfruttato le viste ANSI standard information_schema, presenti in tutti i DBMS principali.

Come suggerisce Ryan Barrett sul suo Web Security Blog, le soluzioni da adottare sono due:

1. filtrare l'operazione di CAST, o nella configurazione di Apache o con direttive apposite nei SQL firewall;

2. modificare i propri siti web affinché tutti i dati in input nei form vengano regolarmente validati prima di essere passati in forma di stringa SQL al DMBS.
   

Le ultime parole famose

Ecco la prova che l'allarmismo sul problema del furto dei dati non è poi così eccessivo.

Recentemente, dalle colonne del Sun, il presentatore televisivo e giornalista inglese Jeremy Clarkson si era fatto beffe pubblicamente dello scandalo della perdita di due cd-rom contenenti i dati personali di 25 milioni di cittadini del Regno Unito. Convinto che la sicurezza delle persone coinvolte non fosse minimamente in pericolo, ha pubblicato i dati del suo conto bancario, invitando i lettori a procurarsi i suoi dati di residenza, tanto "All you'll be able to do with them is put money into my account. Not take it out" (tutto quello che potreste farci è versare dei soldi sul mio conto, altro che prelievi).

Salvo che, con orrore, ha scoperto qualche giorno dopo che qualcuno aveva fatto a suo nome una donazione di 500 sterline (670 euro, più o meno) alla Diabetes UK, prelevando la somma direttamente dal suo conto. E che la banca non poteva risalire al colpevole, e non poteva garantire che la cosa non si sarebbe verificata di nuovo nel prossimo futuro.

Onore almeno all'onestà del discusso giornalista: "I was wrong and I have been punished for my mistake" (mi sbagliavo, e sono stato punito per il mio errore).