SQL injection: suggerimenti di Microsoft

Torno sul tema della SQL injection per segnalare che il 24 giugno la Microsoft ha pubblicato il Security Advisory n. 954462 (Rise in SQL injection attacks esploiting unverified user data input).

In particolare, è interessante la voce "Suggested Actions", in cui si introducono tre tools (Scrawl, Urlscan e MS Source Code Analyzer) che possono tornare utili per individuare parti di codice di proprie applicazioni web suscettibili di questo tipo di attacchi. Inevitabilmente l'advisory è più incentrato su IIS e ASP, ma può sempre tornare utile.

Cose da non fare per dismettere i vecchi hard disk

E' abbastanza comune comprare sul mercato dell'usato computer o periferiche da cui il venditore non ha prima cancellato i dati memorizzati. Palmari, hard disk, portatili, fotocamere con tracce abbondanti della vita e delle attività del vecchio proprietario.

Sul divertente blog che racconta le epiche avventure del SuperBabbo, alias il papà "geek" del disegnatore Mauro Borgarello, si può leggere come l'iperattivo genitore ha risolto alla radice la questione della distruzione dei supporti... ma senza i risultati sperati.

Auditing dei database: protezione dei dati

A prescindere da quale architettura di auditing si decida di implementare, la mole di informazioni raccolte sarà comunque elevata e porrà il problema della memorizzazione, dell’archiviazione e della conseguente protezione, soprattutto considerando che la normativa che impone l’uso di sistemi di controllo stabilisce anche per quanto tempo (solitamente anni) le informazioni raccolte devono essere conservate.

Per ovvi motivi di spazio e prestazioni, è sempre consigliabile dedicare un sistema a parte per la memorizzazione di questi dati. Riguardo all’archiviazione, si possono seguire alcune linee guida essenziali:

• se è prevista la produzione periodica di rapporti occorre programmare il processo di archiviazione di conseguenza, prevedendo anche un periodo transitorio in cui potrebbero essere richieste informazioni più dettagliate per investigare un particolare evento. Per fare un esempio, se si producono rapporti mensili, si potrebbe programmare l’archiviazione dei dati ogni tre mesi;
• oltre ai dati grezzi è utile archiviare anche i rapporti che ne derivano, perché sono di consultazione più immediata;
• indicizzare e catalogare le informazioni ogni volta che si procede all’archiviazione consente un rapido recupero in caso di necessità;
• dove le risorse disponibili lo consentono, adottare una rete SAN (storage area network) o comunque dispositivi sviluppati espressamente per l’archiviazione per semplificare la gestione e la manutenzione dei sistemi.

Le informazioni raccolte e archiviate devono essere protette, perché molto spesso includono dati sensibili. Gli elementi-chiave da rendere sicuri sono: il database in cui vengono raccolti i dati processati dal sistema di auditing; i file di archivio generati a intervalli periodici; quelli passati al sistema di archiviazione; il processo di trasmissione dei file dal sistema di auditing a quello di archiviazione.

Il database popolato dal sistema di auditing è un punto focale della sicurezza dei sistemi informativi. Se non fosse intrinsecamente sicuro si genererebbe il classico infinite loop: per monitorare un sistema di auditing insicuro occorre un altro sistema di auditing, a sua volta insicuro, dunque da monitorare con un altro sistema, e così via. In realtà la sua protezione è abbastanza semplice, perché i sistemi in commercio prevedono il blocco di tutti gli accessi che non provengano dal sistema stesso e impongono regole ferree di sicurezza sul funzionamento del database.

Anche la generazione dei file di archivio dei dati deve seguire un processo preciso per garantirne la sicurezza. I dati estratti dal database di auditing (dal quale vengono eliminati) vanno crittografati per cautelarsi da accessi non autorizzati ai file. Solo il sistema di auditing deve essere in grado di aprirli, decifrarli e utilizzarli. Inoltre, i file di archivio devono essere dotati della firma digitale del sistema per autenticarne i dati (utile eventualmente per certificare la rispondenza alle norme vigenti o a fini investigativi).

Essendo stati criptati i file di archivio, la loro archiviazione nei sistemi di storage non rappresenta un serio problema di sicurezza. L’unica nota riguarda i controlli da effettuare sulla trasmissione dei file e sulla corretta archiviazione, per assicurarsi che le informazioni di auditing siano effettivamente disponibili in caso di necessità e rispondano alle specifiche imposte dalla normativa da rispettare.

Un ultimo accenno può essere fatto sull’auditing del sistema di auditing. Quella che a prima vista potrebbe sembrare una riproposizione del loop infinito di cui si è detto, in realtà è un’ulteriore pratica di sicurezza volta a garantire il corretto funzionamento del sistema di controllo secondo le regole stabilite dalla politica di sicurezza aziendale. È una funzionalità presente nella maggior parte dei sistemi in commercio, in grado di controllare tutte le operazioni compiute sui dati e sulle impostazioni del sistema, particolarmente utile per certificarne la corretta implementazione. Anche dove non richiesto espressamente - e sempre se le risorse a disposizione lo consentono - andrebbe attivato come ulteriore livello del sistema di difesa in profondità.

Auditing dei database: architetture di implementazione

Tutti i principali DBMS sono dotati di funzionalità di auditing più o meno sofisticate, tutte comunque efficaci nello svolgere i loro compiti. Tuttavia, molti esperti di sicurezza informatica consigliano l'uso di sistemi esterni per separare le funzioni di controllo dalla normale gestione del database.

I vantaggi sono diversi: si aderisce meglio al modello della difesa in profondità, perché un sistema di auditing separato è più difficile da compromettere ed è meno soggetto alle vulnerabilità del database; si soddisfa il requisito della separazione dei compiti; l'utilizzo di prodotti esterni è alla portata di un utente privo di competenze avanzate, consentendo di sgravare il DBA dal lavoro di gestione dell'auditing. Infine, in ambienti ad alto livello di sicurezza è anche possibile usare un prodotto esterno in parallelo con le funzionalità interne del database, per confrontare costantemente i dati e verificare se uno dei due sistemi è stato compromesso.

Le architetture di implementazione dei sistemi di auditing sui database che si sono evolute nel tempo sono tre:

• ispezione delle strutture dati interne del database;
• ispezione delle comunicazioni col database;
• ispezione dei file generati dal database durante il normale funzionamento.
  

I database usano delle strutture dati interne per processare i comandi, gestirne i risultati ecc. In appoggio a queste strutture, il DBMS ne mantiene altre in memoria: un metodo per monitorare quello che succede nel database consiste proprio nell'ispezionare queste aree di memoria. Il sistema di auditing, condividendo lo stesso spazio di indirizzamento del database, interroga in polling le strutture in memoria, come in figura 1.

Figura 1 - Ispezione delle strutture dati interne del database

Nello stesso schema è indicato un metodo alternativo. In alcuni DBMS le strutture interne vengono astratte mediante tabelle e viste disponibili a un utente con privilegi da amministratore. È il caso di Oracle, che mediante le viste identificate dal prefisso v$ (come v$session per esempio) astrae le strutture rappresentate nelle tabelle interne identificate dal prefisso x$. Invece di interrogare direttamente le strutture interne, il sistema di auditing può connettersi al database mediante un account da amministratore e interrogare le viste di sistema.

Questa prima architettura di auditing, pur essendo basata su una struttura semplice, soffre di un problema di sincronizzazione: il polling di entrambi i metodi presentati deve essere eseguito con una frequenza sufficiente a rilevare i dati prima che siano sostituiti da quelli successivi; ma allo stesso tempo tale frequenza non deve essere eccessiva per non sovraccaricare le risorse del database.

Figura 2 - Ispezione delle comunicazioni locali e di rete col database

La seconda architettura, raffigurata in figura 2, consente di ispezionare tutti i flussi di comunicazione che terminano sul database. Le comunicazioni possono transitare su rete (usandone i rispettivi protocolli), o essere locali quando il client risiede sullo stesso server del database. In questo caso le comunicazioni si basano sui meccanismi di comunicazione tra processi (IPC - inter-processing communications). Il sistema di auditing adottato in questo schema fa generalmente uso di strumenti di ispezione dei pacchetti per le connessioni di rete, e di apposite sonde (probe) nel sistema operativo per controllare le comunicazioni IPC. Le sonde possono essere configurate anche per verificare l'ultimo tratto delle connessioni di rete, quando i pacchetti giungono al sistema operativo che le inoltra alle porte su cui il database è in ascolto.

Figura 3 - Ispezione dei file generati dal database

La terza architettura di auditing ricorre ai file di supporto del database, dai quali estrae le informazioni che gli occorrono (figura 3). Tipicamente è coinvolto il log delle transazioni, in cui i DBMS registrano tutti i comandi DDL e DML a scopo di ripristino in caso di guasti. Il sistema di auditing può leggere e processare in tempo reale i record registrati nel log e ricostruire la sequenza di operazioni effettuate sul database. Altri file utilizzati possono essere quelli di configurazione, i trace file, altri tipi di log, a seconda dei meccanismi attivi sul database e del supporto ad essi offerto dal sistema di auditing implementato.

Nel prossimo post concluderò il discorso sull'auditing parlando di archiviazione e protezione dei dati raccolti. Vi aspetto!

Auditing dei database: categorie di dati da monitorare

Il processo di auditing di un database può facilmente produrre enormi quantità di dati: si può infatti sottoporre a controllo qualsiasi operazione o evento sui dati e sulle strutture interne. Tuttavia, appare ovvio come non sia conveniente controllare tutto, sia per le inevitabili problematiche prestazionali (risorse di calcolo e spazio disco), sia per l'utilità delle informazioni che si possono estrapolare dai dati raccolti.

L'approccio corretto consiste nel decidere in prima istanza quali sono gli aspetti che si vuole monitorare, basandosi sulle specifiche imposte dalla regolamentazione esterna (leggi, standard di conformità ecc.) e dalla politica di sicurezza aziendale. Le possibilità sono molte, ma mi limiterò a elencare quelle fondamentali.

I login al database si sottopongo praticamente sempre ad auditing. Occorre registrare le connessioni e le disconnessioni, complete di orario, indirizzo IP di provenienza e nome dell'eventuale applicazione usata. Una categoria particolare è rappresentata dai login falliti, che possono essere dovuti a una password digitata male o a un tentativo di accesso non autorizzato. I dati dei login riusciti e falliti possono essere tenuti insieme per praticità, ma vanno sempre presentati separatamente nei rapporti per evidenziare i tentativi di intrusione e possibili trend sospetti. Le informazioni sui login possono inoltre essere usate per una baseline (un elenco di riferimento): qualsiasi variazione, come un utente che si connette regolarmente ma da un indirizzo IP insolito, o ad un orario imprevisto, risulterebbe sospetto e richiederebbe un controllo ulteriore.

È buona norma bloccare uno username dopo un certo numero di login falliti consecutivi. Per farlo si può ricorrere a una stored procedure che allerti in tempo reale il DBA; oppure si può gestire l'evento dall'esterno, tipicamente con un SQL firewall (in questo caso il database non riceverebbe neanche i tentativi di login).

È importante fare l'auditing dei login che avvengono fuori dal normale orario di lavoro. In questi casi è utile monitorare tutte le operazioni compiute dall'utente sospetto. Bisogna però fare attenzione a non monitorare le operazioni programmate (come i backup notturni) per evitare alti livelli di "rumore". Anche in questo caso tornerà utile l'uso di una baseline per individuare quali operazioni siano da escludere dal processo di auditing.

Oltre ai tentativi di login, una delle attività di auditing più importanti consiste nel controllare i comandi DDL che modificano lo schema del database. Tale misura garantisce l'aderenza alle norme, ma soprattutto rinforza la sicurezza del sistema: i comandi DDL sono potenzialmente molto pericolosi, perché possono compromettere il funzionamento del database. Possono essere impartiti non intenzionalmente per effetto di un'operazione maldestra di un amministratore o di uno sviluppatore di applicazioni; ma possono anche essere dovuti a un aggressore che intende creare tabelle d'appoggio su cui copiare i dati, da cui li estrarrà in un secondo tempo per evitare l'auditing attivo sulle tabelle più protette.

Essenziale poi è fare l'auditing di tutte le modifiche apportate allo schema di protezione e dei privilegi del database: aggiunta e eliminazione di utenti, mappattura tra i login e i ruoli, modifiche ai privilegi assegnati e alle password associate agli username. Vista la pericolosità di queste operazioni se effettuate da un aggressore, è sempre opportuno prevedere degli avvisi in tempo reale per intervenire tempestivamente.

Un'altra categoria che è spesso sottoposta ad auditing è quella degli errori restituiti dal database, che possono essere causati da un tentativo di SQL injection (di cui ho parlato qualche tempo fa). L'auditing degli errori è utile anche per supportare la qualità delle applicazioni che si interfacciano al database, perché si individuano più facilmente gli errori di programmazione e i bug di funzionamento derivanti dall'integrazione tra software diversi. È da notare che è abbastanza comune avere piccoli errori anche in ambienti di produzione. Questi errori si manifestano sempre alle stesse condizioni, in modalità sempre uguali: l'uso di una baseline permetterà di individuare prontamente gli errori che se ne discostano, sui quali sarà opportuno investigare.

Uno degli attacchi più sofisticati rivolti ai database (di cui ho intenzione di parlare in futuro) è basato sull'uso dei cosiddetti DB trojan, che attaccano direttamente i trigger e le stored procedure. Se il database che si gestisce può essere soggetto a questo tipo di rischi, sarà dunque opportuno attivare l'auditing sui tentativi di creazione e modifica di questi elementi del database.

Alcuni dei dati conservati in un database sono più sensibili di altri alle modifiche non autorizzate. In ambito lavorativo, una tabella dei dipendenti potrebbe avere tra i suoi attributi il livello retributivo, il numero di giorni di ferie disponibili ecc. (oppure, pensiamo alla recente polemica sulla pubblicazione on-line delle nostre dichiarazioni dei redditi del 2005). Tutte le modifiche apportate a questi attributi possono essere oggetto di auditing se esiste il rischio di accessi e modifiche non autorizzate. In questi casi è opportuno registrare anche il vecchio e il nuovo valore inseriti per ripristinare le condizioni antecedenti (Oracle mette a disposizione per questa operazione LogMiner, di cui ho già parlato in un post sull'analisi forense su Oracle). Va però tenuto presente che questa categoria di auditing può occupare molto spazio per l'archiviazione, per cui occorre valutare attentamente quali oggetti del database e quali comandi DML monitorare.

In tema di dati sensibili, si possono sottoporre ad auditing anche i comandi SELECT quando occorre vigilare sulla riservatezza dei dati, specie per rispondere alle regole imposte dalle norme di legge. Poiché anche in questo caso si genera una grande mole di dati, è conveniente farlo solo sugli elementi che rappresentano dati strettamente confidenziali.

Per concludere, in alcune circostanze può essere necessario monitorare anche le modifiche apportate ai settaggi dei parametri dell'auditing, per evitare che un aggressore ne manipoli l'esecuzione in corso sul sistema, o ne modifichi i dati raccolti. Paranoia? Non credo, i casi reali non mancano...

La prossima volta vedremo le tre principali architetture di auditing sui database. A presto!

Auditing dei database: introduzione

Introduco oggi una breve serie di post sul tema dell'auditing, sulla scia delle considerazioni dell'ultimo intervento (caso Hannaford). Comincerò con una rapida introduzione nell'ambito specifico dei database; nei prossimi giorni parlerò di categorie di auditing, delle architetture implementative più utilizzate, e infine della protezione dei dati di auditing.

L'auditing, o revisione dei sistemi informativi è un processo di verifica sistematico, periodico e documentato, condotto da personale esperto, volto ad accertare che i sistemi informativi di un'azienda o organizzazione siano conformi a quanto previsto da norme, regolamenti o politiche interne. Nello specifico delle basi dati, l'attività di auditing consente di tenere traccia e analizzare qualsiasi attività svolta sulla base dati, tra cui gli accessi, l'attività di utenti e applicazioni connesse, operazioni sui dati e così via.

Monitorare costantemente la sicurezza delle base dati è essenziale per tutte quelle organizzazioni che devono garantire la conformità a norme sempre più restrittive, tra cui il Sarbanes-Hoxley Act (SOX) per la borsa americana, l’Health Insurance Portability and Accountability Act (HIPAA) sulla protezione dei dati clinici dei cittadini americani, la Direttiva Europea 95/46/EC sulla tutela dei dati personali e il Regolamento sul trattamento dei dati del Garante della Privacy italiano. Non solo, il processo di auditing dei database deve essere tale da garantire l'integrità dei dati e identificare possibili falle di sicurezza o tentativi di intrusione nei sistemi.

L'importanza della separazione dei compiti

Le norme citate condividono in particolare due punti: tracciano delle linee guida che stabiliscono le azioni che gli operatori coinvolti devono intraprendere (per evitare delle libere interpretazioni che finiscano col non soddisfare i requisiti imposti); ma soprattutto inducono a separare i compiti di gestione e di controllo dei sistemi informativi all'interno dell'organizzazione. Il concetto di separazione dei compiti nasce dall'idea che non è opportuno affidare i compiti di sistemista e di controllore a un unico individuo (o gruppo). Anzi, è consigliabile definire una catena gerarchica in cui ogni livello garantisce per l'operato del livello sottostante, come nel caso del SOX, che descrive espicitamente i compiti del management, quelli dell'auditing interno e quelli dell'auditing esterno.

In quei paesi come gli Stati Uniti in cui la rispondenza alle norme è questione seria, la separazione dei compiti è obbligatoria, e se non è applicata si è considerati fuorilegge. Chi sbaglia paga: il CEO della Enron, se non fosse morto prima del tempo, avrebbe fatto qualche decina d'anni di galera (il SOX è una delle conseguenze di quello scandalo). Da noi, per il caso Parmalat, a pagare sono stati più che altro gli investitori.

Parlando di database e auditing, la separazione dei compiti implica che il DBA non si occupi delle funzioni di controllo. La questione alla base è semplice e può essere riassunta in modo un po' "brutale": chi controlla un DBA disonesto?

L'utilità dell'auditing non si limita certamente a questo. Tuttavia i casi abbondano: tempo fa una grande azienda di distribuzione nazionale ha licenziato in tronco uno dei suoi DBA perché colto a modificare le presenze della sua fidanzata, collega di lavoro in altro ufficio. Il DBA non potè neppure appellarsi al licenziamento senza giusta causa, avendo contro i risultati dell'auditing sui database; mancò poco che rimediasse anche una denuncia per truffa...

Tornando ai database, tutti i principali DBMS sono provvisti di funzionalità interne di auditing, che spesso sono ritenute sufficienti per i proprio scopi, soprattutto nelle realtà medio-piccole del nostro tessuto economico. Tuttavia, il DBA ha pieno accesso a tali funzionalità, e per attendere alla separazione dei compiti bisognerà prevedere una serie di misure di controllo di non facile implementazione. Risulta invece più comodo fare ricorso a risorse esterne, che sul mercato abbondano (come DbProtect e DB Audit), con l’ulteriore vantaggio di sgravare il DBA dalla gestione diretta dell'auditing, comunque impegnativa.

Nel prossimo post parlerò di categorie di auditing, ovvero di quali elementi del database sottoporre alla revisione. Stay tuned!

Sul chiudere la stalla dopo che i buoi sono scappati...

Leggo su Computerworld che la storica catena americana di supermercati Hannaford prevede di spendere milioni di dollari per adeguare i suoi sistemi informatici agli standard di sicurezza, in particolare adottando l'ISO 27001. Ma questo solo dopo che ha dovuto denunciare il furto dei dati relativi a oltre 4 milioni di carte di credito dei suoi clienti.

La cifra preventivata, al momento precisata solo come ordine di grandezza, può sembrare enorme. Tuttavia, il management rischia di dovere affrontare cause di gran lunga più costose, che potrebbero essergli intentate dalle banche e dagli istituti di credito per i costi che dovranno sostenere per la sostituzione delle carte dei loro clienti e la gestione delle eventuali frodi.

Il fatto che l'azienda si dilunghi in dettagli tecnici sull'effrazione subita, premurandosi di sottolineare che i suoi processi informatici erano conformi allo standard di sicurezza PCI (imposto dalle principali compagnie che emettono carte di credito), ha il sapore dell'ultima, disperata difesa per limitare i danni economici.

La questione non è sapere, a posteriori, che i dati sono stati trasferiti in Cina piuttosto che in Romania, o che sono stati intercettati in transito durante la transazione (è infatti più plausibile pensare all'opera di un basista interno). E' significativo invece che, nell'arco dei tre mesi in cui si è verificato il furto continuato, nessuno si sia accorto di nulla: non un sistema di auditing interno, e neppure un file di log da controllare. O magari i file di log c'erano (da cui potrebbero venire le informazioni rese note), ma nessuno li leggeva. Il classico esempio di miopia imprenditoriale, per cui il settore IT è raramente una risorsa strategica ma sempre una voce di costo, e la sicurezza informatica una spesa da affrontare dopo, perché prima l'esigenza non è avvertita.

Uno studio della Forrester ha calcolato i costi a cui potrebbe andare incontro un'azienda per il furto dei dati delle carte di credito dei suoi clienti: tra i 90 e i 305 dollari per singola carta, variabili a seconda della portata del furto e dell'ambito operativo dell'azienda. Se anche si volesse considerare una cifra inferiore, diciamo 50 dollari, il furto subito dalla Hannaford potrebbe costare - tra spese legali, varie e perdita di immagine e clienti - intorno ai 200 milioni di dollari. In confronto, i quattro milioni destinati alla sicurezza IT sono davvero poca cosa. Meglio pensarci prima.

L'effetto "Mar Morto" nel settore IT

Segnalo un interessante articolo di Bruce Webster, esperto di fama internazionale e autore della trilogia The Art of 'Ware, Pitfalls of Object Oriented Development (che sarà rimpiazzato dalla nuova edizione intitolata Pitfalls of Modern Software Engineering) e Surviving Complexity, ancora in fase di completamento.

Sono molte le cause delle difficoltà incontrate dalle aziende, pubbliche e private, nell'organizzazione e amministrazione del proprio settore IT. Webster nei suoi libri, articoli e interventi ne ha indicate diverse, tra cui le difficoltà a reperire i migliori informatici sulla piazza (lui parla direttamente di ingegneri...). E tuttavia, se anche l'azienda fosse in grado di assumere i migliori, saprebbe poi trattenerli?

Gli ingegneri informatici più esperti sul mercato americano si contraddistinguono per la volatilità dei loro rapporti di lavoro, in virtù delle sempre migliori condizioni che riescono a trattare passando da un azienda all'altra. Ma allora, si chiede Webster, nelle aziende cosa resta? E con quali conseguenze per l'habitat aziendale?

Il paragone con il Mar Morto che propone è suggestivo. Forse non condivisibile in toto, e infatti vale la pena anche di leggere i commenti dei lettori sia al fondo dell'articolo, che nella pagina che gli è stata dedicata su Slashdot.

Sarebbe interessante vedere quanto sia applicabile questa tesi anche qui, a casa nostra.

Il Documento Programmatico sulla Sicurezza (DPS)

Periodo di superlavoro, questo, e l'inizio della bella stagione mi induce a trascurare il blog per portare le bimbe al parco appena ho un po' di tempo libero. Una scusa più che valida, non è vero?

Oggi tratterò un argomento che "avrebbe" dovuto essere al centro dell'attenzione nei giorni scorsi: il Documento Programmatico sulla Sicurezza, noto anche come DPS. Ogni anno le aziende e gli enti che trattano dati sensibili e/o giudiziari sono tenuti a a redigere tale documento, che descrive la tipologia dei dati trattati, i responsabili del trattamento, l'analisi dei rischi incombenti sui dati, le misure adottate per tutelarne integrità, disponibilità e accessibilità.

Il DPS è specificamente previsto dall'art. 34, comma 1, punto g) del D.Lgs. 196 del 30 giugno 2003:

"1. Il trattamento di dati personali effettuato con strumenti elettronici è consentito solo se sono adottate, nei modi previsti dal disciplinare tecnico contenuto nell'allegato B), le seguenti misure minime: [...]
g) tenuta di un aggiornato documento programmatico sulla sicurezza; [...]"

Il Disciplinare tecnico in materia di misure minime di sicurezza (allegato B al D.Lgs. 196/2003), al punto 19, esplicita le caratteristiche del DPS:

"Documento programmatico sulla sicurezza

19. Entro il 31 marzo di ogni anno, il titolare di un trattamento di dati sensibili o di dati giudiziari redige anche attraverso il responsabile, se designato, un documento programmatico sulla sicurezza contenente idonee informazioni riguardo:
19.1. l'elenco dei trattamenti di dati personali;
19.2. la distribuzione dei compiti e delle responsabilità nell'ambito delle strutture preposte al trattamento dei dati;
19.3. l'analisi dei rischi che incombono sui dati;
19.4. le misure da adottare per garantire l'integrità e la disponibilità dei dati, nonché la protezione delle aree e dei locali, rilevanti ai fini della loro custodia e accessibilità;
19.5. la descrizione dei criteri e delle modalità per il ripristino della disponibilità dei dati in seguito a distruzione o danneggiamento di cui al successivo punto 23;
19.6. la previsione di interventi formativi degli incaricati del trattamento, per renderli edotti dei rischi che incombono sui dati, delle misure disponibili per prevenire eventi dannosi, dei profili della disciplina sulla protezione dei dati personali più rilevanti in rapporto alle relative attività, delle responsabilità che ne derivano e delle modalità per aggiornarsi sulle misure minime adottate dal titolare. La formazione è programmata già al momento dell'ingresso in servizio, nonché in occasione di cambiamenti di mansioni, o di introduzione di nuovi significativi strumenti, rilevanti rispetto al trattamento di dati personali;
19.7. la descrizione dei criteri da adottare per garantire l'adozione delle misure minime di sicurezza in caso di trattamenti di dati personali affidati, in conformità al codice, all'esterno della struttura del titolare;
19.8. per i dati personali idonei a rivelare lo stato di salute e la vita sessuale di cui al punto 24, l'individuazione dei criteri da adottare per la cifratura o per la separazione di tali dati dagli altri dati personali dell'interessato."

Ho evidenziato in grassetto gli elementi interessanti. Il disciplinare indica un approccio metodologico sorprendentemente completo e corretto: a giudicare dai punti elencati, il DPS sarebbe dunque una valida occasione per le aziende per fare il punto sullo stato della sicurezza informatica interna a cadenza annuale. Questa ciclicità consentirebbe di adottare in modo naturale il paradigma Plan-Do-Check-Act seguito nei controlli di qualità. I responsabili della sicurezza potrebbero così verificare periodicamente l'implementazione della politica di sicurezza aziendale, intervenire sui punti deboli, aggiornare il personale.

Tuttavia, il DPS ha suscitato polemiche fin dalla sua prima introduzione. Rinvii, totale inadempienza della pubblica amministrazione, difficoltà di stesura fino alla riduzione - secondo molti esperti - della sua efficacia, a seguito della pubblicazione dell'interpretazione autentica del Garante con un modello preimpostato di DPS, particolarmente semplificato.

E' interessante il punto di vista di Corrado Giustozzi (storica firma di MCmicrocomputer ed esperto di sicurezza informatica) espresso su InterLex qualche tempo fa: se si parla di "documento programmatico", esso dovrebbe essere una dichiarazione di intenti, ovvero la definizione delle misure che si intende adottare a tutela dei dati trattati; così come stabilito dalla norma, invece, è più una relazione conclusiva, che descrive le scelte compiute e le misure implementate. E, poiché riporta i meccanismi di sicurezza dell'azienda, andrebbe considerato un documento riservato, che non dovrebbe quindi essere allegato al bilancio di esercizio... pubblico!

Il palese insuccesso del DPS è il consueto pasticcio all'italiana. All'estero le normative sul trattamento dei dati (sensibili o finanziari che siano) coinvolgono direttamente i dirigenti aziendali, imponendogli di conoscere i processi di trattamento dei dati e le misure di sicurezza adottate, costringendoli di fatto a collaborare con i responsabili della sicurezza e gli amministratori dei sistemi informatici (per esempio la SOX americana). Da noi è invece prassi comune demandare la stesura del DPS all'ufficio legale, o comunque a un avvocato: ci si tutela sul piano giuridico, ma si rinuncia - più o meno consapevolmente - a sfruttare l'occasione per intervenire sugli aspetti tecnici del trattamento delle informazioni, cruciale nell'economia attuale.

E ' questione di cultura imprenditoriale. Conosco persolmente un'azienda il cui titolare, laureato in giurisprudenza, compila personalmente il DPS, pur avendo scarsa dimestichezza con l'uso del computer. Il suo documento è ineccepibile sul piano formale; eppure, proprio due anni fa, un server della lan aziendale è stato compromesso, e tutti gli archivi sono stati cancellati per atto vandalico. I backup più recenti, effettuati saltuariamente per iniziativa personale di un dipendente, risalivano a tre settimane prima. Venti giorni di lavoro andati persi - ma poteva andare peggio; ciò nonostante, in quella azienda si continua ancora oggi a operare come se nulla fosse successo. Nessuna riflessione, nessun miglioramento, nessuna crescita.

Un caso isolato? Credo proprio di no, avendo riscontrato lo stesso problema in una grande industria del settore metalmeccanico (non quella che state pensando...) per bocca del responsabile IT.

Anagrafe Unica Nazionale: bello, ma...?

Leggo su www.pubblicaamministrazione.net che si sta realizzando "uno dei più ambiziosi e rivoluzionari progetti di E-Government mai concepiti finora: l’AUN (Anagrafe Unica Nazionale)" (dal comunicato stampa ufficiale). In pratica, un datawarehouse centralizzato in cui confluiranno tutti i dati anagrafici dei cittadini italiani, che saranno quindi messi a disposizione delle amministrazioni centrali e locali, ma anche - qui la parte più interessante - direttamente ai singoli cittadini, che potranno accedervi tramite interfaccia per sfruttare i servizi messi a disposizione (come la richiesta di certificati).

Trovo che sia un'ottima idea, nell'ottica di alleggerire il peso della burocrazia e di supportare la P.A. come fornitore di servizi ai cittadini. E' vero che alcuni servizi simili sono già disponibili (il comune di Torino, per esempio, su richiesta dell'interessato invia a domicilio tutta una serie di certificati), ma si tratta sempre di soluzioni fortemente localizzate. In questo caso invece, la centralizzazione consentirebbe una migliore armonizzazione tra i dati raccolti dalle varie anagrafi, l'accesso ubiquo alle informazioni, e le auspicabili economie di scala.

E' anche piacevole scoprire che a promuovere questo progetto sia stata fin dall'inizio non la solita impresa milanese o romana, o la sezione italiana di una grande multinazionale del software, ma un'azienda del meridione (Infinity DWH), in particolare della Calabria, di cui troppo spesso si parla solo per fatti di cronaca negativi.

Per una naturale tendenza, che potrei banalmente definire deformazione professionale, mi incuriosisce il livello di sicurezza che questo progetto dovrà adottare. Le banche dati di cittadini sono strumenti fondamentali per l'amministrazione pubblica, per cui si accetta di buon grado l'esposizione della propria privacy ad alcuni operatori, confidando nella loro correttezza e onestà. Tanto per dire, tempo fa - in seguito a una riunione di condominio particolarmente infuocata - un mio condomino, allora dipendente dell'amministrazione tributaria, minacciò velatamente personali verifiche fiscali sulle dichiarazioni dei redditi di un altro condomino con cui era entrato in conflitto. A me diede fastidio l'idea che un operatore autorizzato agli accessi sui dati personali potesse soddisfare così facilmente una curiosità dettata dal capriccio. Ma il fatto che gli stessi dati diventino oggi accessibili in rete mi allarma ancora di più.

Leggere sul comunicato stampa citato che il database è "accessibile grazie ad un’amichevole ed uniforme interfaccia che permetta in tempo reale l’aggiornamento del database centrale" mi fa un certo effetto. Perché dovrei avere la necessità di modificare personalmente i miei dati? E perché un pubblico ufficiale (l'impiegato dell'anagrafe) dovrebbe farlo tramite un accesso a internet? Sia chiaro, non sto contestando il progetto - non ho elementi sufficienti - sono solo i primi dubbi che nascono da quella frase, apparentemente innocente nella sua genericità.

Poi sul sito della Infinity DWH leggo che "il tutto [è] garantito da specifiche tecniche di sicurezza e da un accesso ai dati possibile solo con l’ausilio di carta di identità elettronica o di smart card caratterizzanti la firma digitale dell’utente". Soprattutto qui sarebbe interessante saperne di più. Finalmente cominceremo a sfruttare le funzionalità della carta d'identità elettronica, che i comuni rilasciano già da un paio d'anni. Ma l'uso di una ID card, sicuramente meglio della classica accoppiata username-password, non è tuttavia garanzia sufficiente di sicurezza, come risulta evidente da questo articolo (in inglese) o da una rapida ricerca sul sito di Schneier.

A ben guardare però, sia nel comunicato stampa sia sul sito della Infinity DWH, si parla solo di protocollo d'intesa fra aziende private e associazioni di categoria (Anipa e Alsi). Nessun cenno a un ipotetico contratto con Presidenza del Consiglio, Ministero dell'Interno o chi per loro, e neppure un bando di gara per l'assegnazione di un'appalto, come si dovrebbe fare in questi casi. Si parla per ora di un primo prototipo, che a tempo debito immagino sarà presentato pubblicamente. Vedremo presto la versione 1.0? A chi sarà presentata? Ma soprattutto, chi sarà chiamato a valutarne le caratteristiche, le potenzialità offerte e i possibili rischi? In questo senso il precedente di Italia.it non fa ben sperare...

Note sulla crittografia nei database: i data-at-rest

Dopo avere visto gli approcci alla cifratura dei dati in transito, vediamo ora quelli rivolti ai dati memorizzati (e archiviati). La cifratura dei dati su disco è da preferire quando si conservano dati che non dovrebbero essere visibili se non ai legittimi proprietari. È il caso dei numeri delle carte di credito, a cui non dovrebbero accedere neppure i DBA; ma va contemplata anche l’eventualità di una copia illegale dei file del database, o del furto del server o dei dischi su cui risiedono i dati.

Le strategie seguite sono tipicamente tre:

• Cifratura a livello applicazione: tutta la gestione è demandata ad apposite librerie crittografiche del linguaggio di programmazione usato nello sviluppo dell’applicazione per la gestione della base dati (come le Java Cryptographic Extensions). Questo approccio è completamente trasparente al database. Se questa soluzione è utile nei casi in cui le norme di sicurezza sono molto stringenti (è impossibile usare i dati all’infuori dell’applicazione che li ha cifrati), è però poco pratico perché limita l’utilizzo di stored procedure e appesantisce lo sviluppo dell’applicazione.
  

• Cifratura a livello del file system: sfrutta le capacità dei sistemi operativi più evoluti di gestire i file in forma cifrata. Anche in questo caso, l’operazione è trasparente al database. Ha un grosso limite nel decadimento delle prestazioni, perché ogni accesso ai file deve passare attraverso la fase di cifratura/decifratura.
  

• Cifratura a livello del database: si usano le funzionalità offerte dal DBMS o da estensioni sviluppate da terzi. Risulta essere la soluzione più pratica, e infatti è la più utilizzata. Tuttavia “pratica” non va intesa come semplice: a questo approccio è legata la gestione di un insieme di chiavi che non è affatto banale. Tipicamente, a ogni attributo che si intende cifrare è associata una chiave simmetrica. Gli utenti del database sono forniti di una chiave pubblica e di una privata personali. Quando a uno di questi utenti viene assegnato il permesso di accedere a un attributo cifrato, la relativa chiave simmetrica viene cifrata con la chiave pubblica dell’utente e posizionata in una locazione accessibile. Ad essa l’utente potrà accedere mediante la sua chiave privata, che gli consentirà di operare sull’attributo.
  

Comunque, quale che sia la strategia adottata, la prima considerazione da fare riguarda quali dati nascondere. Gli algoritmi crittografici consumano risorse sul server, con il conseguente decadimento delle prestazioni. Per questo motivo è necessario individuare quali attributi siano assolutamente da mascherare, evitando dove possibile gli attributi usati come chiavi o associati a indici, perché genererebbero un sovraccarico dovuto alla decifrazione ad ogni scansione della tabella a cui appartengono.

Un’altra questione riguarda le funzionalità di backup e ripristino. I backup vanno cifrati al pari dei dati in linea, altrimenti all’aggressore basterà procurarsi i file di backup per aggirare il problema (operazione anche meno rischiosa se non è previsto un auditing sugli accessi ai dati archiviati). Inoltre, bisogna tenere presente che, se la politica di sicurezza aziendale prevede il cambiamento periodico delle chiavi, bisognerà gestire e conservare (in maniera sicura) quelle usate per generare i backup.

Vista la complessità e la difficoltà implementativa di queste scelte, è indispensabile documentarsi approfonditamente prima di adottarle per i propri sistemi, studiando in particolare le funzionalità messe a disposizione dai singoli DBMS. Esse tuttavia - al momento - non affrontano ancora in modo integrato questioni complesse come per esempio la gestione della cifratura in presenza di clustering, di repliche del database, dell’auditing. In questo settore specifico si potrà scegliere di usare prodotti di terze parti, che generalmente offrono soluzioni più complete e più semplici da utilizzare.

Note sulla crittografia nei database: i dati in transito

Non sono sparito... In questo periodo sto trascurando il blog perché sono assorbito da un progetto decisamente interessante, di cui forse parlerò in futuro. Nel frattempo, pubblico qualche nota su un argomento centrale per la sicurezza: la cifratura dei dati.

Nonostante tutte le precauzioni messe in atto per proteggere i sistemi informatici e i dati custoditi, è sempre possibile che un aggressore riesca a penetrare le difese e raggiungere il cuore del sistema, la base dati. Quando l’attacco ha successo, l’estrema difesa è rappresentata dall’uso della crittografia, che rende illeggibili i dati a chi non possiede le chiavi per decodificarli.

Un ottimo libro sulla crittografia per chi volesse approfondire l'argomento è Practical Cryptography di Niels Ferguson and Bruce Schneier, che in qualche modo segue il precedente Applied Cryptography, ancora di Schneier.

Nel settore delle basi dati si sono affermati due approcci alle tecniche crittografiche, nati da esigenze diverse: la cifratura dei dati in transito e la cifratura dei dati memorizzati (o data-at-rest). Nel primo caso, che vedremo oggi, si intende proteggere le comunicazioni, perché la minaccia di furto dei dati si manifesta a livello del canale; nel secondo caso si vuole proteggere (almeno) una parte dei dati perché particolarmente riservata - come nel classico esempio dei numeri di carte di credito - dall’accesso sia di persone esterne che degli utenti interni del database.

Cifratura dei dati in transito

Tutti i DBMS all’installazione aprono delle porte di default per le loro comunicazioni, che gli amministratori meno accorti tendono a non cambiare. Gli hacker conoscono queste porte, e quasi sempre sono esperti di reti. Riescono a intercettare facilmente le trasmissioni, che generalmente avvengono in chiaro (o quasi). Se il canale di comunicazione è considerato a rischio, è opportuno cifrare/decifrare la trasmissione ai suoi estremi, ovvero all’ingresso e all’uscita del canale - avendo tuttavia ben presente che la cifratura delle trasmissioni ha un impatto considerevole sulle prestazioni. Se si sceglie questo approccio, ovvero si considera prioritaria la minaccia sul canale, i dati contenuti nelle tabelle possono rimanere non criptati (ma nulla vieta di ricorrere a entrambe le soluzioni).

Per intercettare le comunicazioni, un attaccante deve avere accesso alla rete e sapere interpretare il flusso delle comunicazioni. L’accesso alla rete è certamente semplificato se si usa una macchina facente parte della rete-bersaglio, o se si ha accesso fisico a uno dei suoi switch (magari attraverso una porta SPAN *): è sufficiente configurare la scheda di rete in modalità promiscua per intercettare tutte le trasmissioni che avvengono all’interno della rete. Per interpretare il flusso delle comunicazioni, oltre ad avere una minima conoscenza dei protocolli di rete - in pratica del TCP/IP - e dei protocolli dei DBMS che si appoggiano su di essi, basta l’uso di uno dei tanti strumenti disponibili in internet come Tcpdump o Ethereal per intercettare i pacchetti e acquisirne i payload, al cui interno sono veicolati i payload del database. Usando questa tecnica, l’attaccante sarà in grado di intercettare il processo di autenticazione (il login al database), i comandi SQL (dai quali può estrapolare la struttura della base dati), e i dati restituiti dalle query.

[* Switch Port Analyzer. Molti switch evoluti sono dotati di una porta SPAN a scopi amministrativi, sulla quale (e solo su di essa) viene trasmessa copia di tutti i dati inviati alle altre.]

Per proteggere la trasmissione si possono adottare approcci diversi. Nello specifico:

• Funzionalità dedicate interne al database: alcuni DMBS offrono dei package per il supporto e la gestione della cifratura delle trasmissioni, come nel caso del pacchetto Oracle Advanced Security incluso nella versione Enterprise di Oracle (può essere utile consultare a questo scopo il volume Oracle security handbook di Theriault, Newman e Vandivier). Quando un client tenta di aprire una connessione col server, il listener di Oracle avvia una sequenza di negoziazione sul sistema di cifratura, mediante la quale comunica al server i metodi crittografici che supporta. Il server li confronta con quelli che ha a sua disposizione, e se trova delle corrispondenze attiva quello a cui è data la priorità nei suoi file di configurazione; in caso contrario, rifiuta la connessione. Poiché solitamente questo genere di soluzioni è costoso (per l’acquisto delle versioni più care o di pacchetti aggiuntivi), la loro diffusione è limitata rispetto alle altre.

• Connessioni speciali: in sostanza si riducono tutte all’uso di SSL (Secure Socket Layer), che è adottato praticamente da tutti i DBMS sul mercato. Il protocollo SSL utilizza metodi di cifratura a chiave pubblica e richiede l’uso di certificati a chiave pubblica per verificare l’identità del DB server e della macchina su cui è in esecuzione l’applicazione.

• Tunneling: in questo caso si sfrutta il protocollo SSH, che è diventato uno standard di fatto per l’amministrazione remota di sistemi Unix e di dispositivi di rete, in sostituzione del protocollo Telnet, privo di protezione contro le intercettazioni. Questa tecnica è implementata in modo trasparente rispetto al database, perché i dati sono cifrati direttamente nel tunnel. Per cifrare il traffico del database si stabilisce un tunnel SSH mediante il port forwarding: si specifica una porta A sul client che fungerà da accesso al tunnel, il quale consegnerà i pacchetti sulla porta specificata B del server.
  

  Esempio: ssh -L 9999:localhost:4304 192.168.0.1
  

  Con questo comando si genera un tunnel tra la porta 9999 del client (localhost) e la porta 4304 del server (192.168.0.1). Ogni trasmissione che abbia luogo attraverso la porta A del client passerà automaticamente attraverso il tunnel SSH, cifrata, fino alla porta B sul server.
  

• Demandare al sistema operativo: anche in questo caso, come nel precedente, la cifratura avviene in modo trasparente per il database, ma l’operazione è direttamente a carico del sistema operativo. Si usa lo standard IPSec, che a sua volta crea una sorta di tunnel cifrato, che però ha effetto su tutto lo stack TCP/IP. È fondamentale che il servizio di cifratura di IPSec sia attivo su tutte le macchine che devono essere coinvolte.
  

Queste le soluzioni più comuni per la cifratura dei dati in transito. Nel prossimo post completeremo la panoramica vedendo quelle per i dati memorizzati. Stay tuned!

Analisi forense su Oracle - analisi esadecimale dei Redo Logs

Le due tecniche di analisi forense su Oracle viste nei post precedenti sono semplici e relativamente rapide, ma solo l’analisi esadecimale dei Redo Logs restituisce una descrizione completa di quello che è accaduto nella base dati. Per questa tecnica, in realtà complessa e poco documentata*, è sufficiente usare uno dei tanti editor esadecimali disponibili in rete, da usare come sempre su copie dei log esatte e certificate (per garantirne la validità di prova in sede giudiziaria).

* La Oracle non fornisce ufficialmente le specifiche dei formati interni dei file. Una delle poche fonti di informazioni è il sito www.databasesecurity.com, da cui è stato tratto l’esempio riportato in questo paragrafo (si veda in particolare: D. Litchfield, “Dissecting the Redo Logs”, white paper della serie Oracle Forensics), integrato nelle parti che mi sembravano meno chiare.

La maggior parte dei file binari di dati e di log in Oracle condivide la stessa struttura. In testa è presente un header, la cui prima parte riporta la tipologia di file (valore 0x22 per i Redo Logs), la dimensione del blocco logico (solitamente 512 byte), e il numero di blocchi che compongono il file (a cui va aggiunto quello occupato dall’header, non contato). Moltiplicando il totale dei blocchi per la dimensione del singolo blocco si ottiene la dimensione effettiva del file. Segue quindi un magic number, usato dal DBMS per determinare se effettivamente si tratta di un file Oracle.La seconda parte dell’header contiene una serie di informazioni relative all’istanza del database, tra cui il suo SID (Serial Identificator), la versione del database, la data e l’ora in cui è partita l’operazione di log. Inoltre contiene quattro coppie di numeri a 32 bit: Low, Next, Enabled e Thread Closed System Change Numbers (SNC), ognuno associato a un timestamp (data e ora).

Gli SNC sono una sorta di “segnalibri” per indicare un punto in cui lo stato del database è cambiato, per esempio per effetto di una INSERT seguita da un COMMIT. I primi due elencati, in particolare, indicano rispettivamente la prima e l’ultima transazione registrata nel log. In caso di necessità si potrà quindi ripristinare il database a una particolare transazione mediante il relativo SCN.

Riguardo ai blocchi, ognuno di essi ha un header di 16 byte che inizia con un identificativo, seguito dal numero di blocco, dal numero di sequenza e da un offset.



È da notare che un record del Redo Log può eccedere le dimensioni di un blocco, continuando nel successivo. L’investigatore dovrà tenerne opportunamente conto, facendo attenzione alla cadenza degli identificatori di inizio blocco. L’offset rappresenta il Relative Block Address (indirizzo relativo di blocco), ovvero il punto all’interno del blocco in cui inizia un nuovo record del log. Chiude l’header il valore di checksum del blocco, che garantisce l’integrità dei dati in esso riportati.

Sui checksum in particolare si concentra l’attenzione degli hacker più esperti, che cercheranno di riscrivere in breve tempo i record dei Redo Logs (mediante appositi programmi) lasciando intatto tutto il resto. In questi casi il lavoro dell’investigatore si complica in maniera esponenziale perché i checksum risulteranno falsamente corretti; ma fortunatamente sono pochissime le persone in grado di compiere operazioni del genere in un tempo limitato. È qui utile sottolineare quanto detto in altri post: una strategia di difesa in profondità complica il lavoro dell’aggressore, ed è più probabile che a qualche livello rimanga traccia del suo passaggio, nonostante i suoi tentativi - per quanto sofisticati - di eliminare le prove.

Continuiamo il quadro sulla struttura di un Redo Log parlando di come vengono gestiti i timestamp. Questi numeri a 32 bit rappresentano il numero di secondi trascorsi dalla mezzanotte del primo gennaio 1988 (rappresentata * come 01/01/1988 00:00:00).

* In realtà l’algoritmo di Oracle che produce il valore non calcola il numero esatto di secondi trascorsi, ma ai fini di questa trattazione potremo accettare questa semplificazione. Il lettore interessato ad approfondire potrà consultare il paper di Litchfield già segnalato.

Infine, descriviamo un Redo Record: per ogni SCN, esiste nel log un record che ne descrive tutte le modifiche apportate al database. Ogni record inizia con un header, seguito da uno o anche più change vector. Ad esempio, nel caso di una INSERT su una tabella con un indice verranno generati diversi change vector: uno per il redo e uno per l’undo della INSERT, un insert leaf row per l’indice e un commit.

Ai change vector è associato un codice operativo, formato da un codice di livello e da un sotto-codice operazionale separati da un punto. Esistono più di 150 codici operativi, di cui si elencano i più comuni:



A questo punto abbiamo gli elementi principali necessari per decodificare un Redo Log. I passi da seguire sono i seguenti:

• messa in sicurezza del server violato (secondo le metodologie forensi fondamentali per garantire l’autenticità delle prove raccolte);
• copia dei Redo Logs su cui effettuare tutte le analisi;
• di ogni oggetto del database inventariare ID, tipo e proprietari.
  

Esamineremo a titolo d’esempio un unico record di uno dei file di log, la cui codifica esadecimale, riportata nella figura seguente, comincia dall’header del relativo blocco.



L’offset dell’header (0x10) indica che il record comincia all’indirizzo 0x1d2810 (0x1d2800 + 0x10). Qui troviamo la dimensione in byte del record: 0x01A8 (424 byte).

A 68 byte dall’inizio del record troviamo la coppia 0B 02, codice operativo dell’operazione: in decimale “11 02”, corrispondente a un inserimento su riga singola. Nei quattro byte precedenti è riportato il timestamp dell’inserimento (0x24CC67F9), che è possibile convertire in forma leggibile usando all’inverso l’algoritmo di Oracle (13:15:37 del 16 marzo 2007).

A 22 byte dal codice operativo è riportato il codice identificativo dell’oggetto del database coinvolto dall’operazione. In questo caso 0x0057, ovvero 87 in decimale. Dall’inventario degli oggetti si evince che l’ID 87 corrisponde alla tabella sysauth$ (che tiene traccia dei ruoli e dei membri ad essi associati) di proprietà dell’utente sys.

La coppia di byte successiva serve per dedurre il numero di colonne coinvolte e va interpretato come dimensione in byte di un vettore. Il valore rappresentato è 0x000C, in decimale 12. Ogni elemento del vettore occupa 2 byte, da cui 6 elementi. Il primo è occupato dal valore di dimensione, il secondo e il terzo sono le coppie successive (0x0014 e 0x0031), che sono dei valori sostanzialmente fissi, quindi seguono le ultime tre coppie, che rappresentano le tre colonne su cui ha agito l’operazione che stiamo esaminando. Queste tre coppie riportano il numero di byte inseriti nelle colonne: 2 nella prima e nella seconda, 3 nella terza.

Le prime tre colonne della tabella sysauth$ sono di tipo numerico: la posizione dei valori inseriti è indicata dal byte immediatamente successivo, che può valere 01 (valori a 72 byte di distanza), 02 (valori a 64 byte di distanza) o 17 (valori a 120 byte di distanza). Nel nostro caso il valore è 01, per cui individuiamo il primo dato (0xC102) a 72 byte di distanza.

I valori numerici sono gestiti da Oracle in modo particolare. I numeri decimali vengono separati in coppie (per esempio 12345 in 01-23-45) e l’ordine di grandezza è codificato su un byte: C1 per i numeri compresi tra 1 e 99, C2 per numeri tra 100 e 9.999, C3 per numeri tra 10.000 e 1.000.000 e così via. Ad ogni coppia, se diversa da zero, viene associato un byte e al numero da rappresentare - in esadecimale - è aggiunto 1. A titolo di esempio:



Come si diceva, il primo dato inserito è 0xC102, seguito da 0xC105 e 0xC20931, ovvero i valori 1, 4 e 848. Allora possiamo ricostruire l’operazione compiuta alle 13:15:37 del 16 marzo 2007:

INSERT INTO SYS.SYSAUTH$ (GRANTEE#,PRIVILEGE#, SEQUENCE#) VALUES (1,4,848);

Dall’inventario compiuto a inizio indagine si evince che l’utente “1” corrisponde a PUBLIC e che il privilegio “4” è quello di DBA. In altre parole, questa operazione ha reso l’utente PUBLIC (ovvero chiunque!) un amministratore del database.

Nel log, ogni record riporta subito dopo l’operazione anche la relativa UNDO, nel quale è segnalato anche l’ID dell’utente che ha impartito il comando. Nel caso della INSERT in esame il valore è 0x36 (54 decimale): consultando la mappatura degli ID si potrà capire se l’operazione è stata effettuata dall’utente sys, come sarebbe lecito aspettarsi (l’accesso alla tabella sysauth$ gli è riservato), o se non si tratti piuttosto di un utente a cui è stato illecitamente consentito l’accesso. In tal caso, individuato l’utente con il profilo compromesso, si dovrà procedere a investigare sulle operazioni che sono state da lui compiute e su quelle che hanno portato all’assegnazione di privilegi non previsti. In questo modo si riuscirà a riscostruire una linea temporale delle operazioni illecite compiute sul database, da presentare in sede giudiziaria.

L’esempio trattato, apparentemente complicato, è in realtà uno dei casi più semplici tra quelli affrontati nell’analisi forense delle basi dati, e rappresenta una delle operazioni preliminari dell’indagine. Sul sito segnalato sono presenti anche gli altri white paper di Litchfield sull'analisi forense su Oracle: la lettura è molto interessante, e la consiglio per chi è interessato a questi argomenti.

Analisi forense su Oracle - LogMiner

Continuiamo la nostra carrellata sulle tecniche di analisi forense su un database Oracle. Dopo avere fatto conoscenza con l'elemento fondamentale per l'indagine, il Redo Log, e aver visto una tecnica di base, il dump del log, andiamo a incontrare un utile strumento fornito da Oracle stesso.

LogMiner è un'applicazione Oracle (edizione Enterprise) che consente di ispezionare direttamente i Redo Logs usando interrogazioni SQL. È scritto quasi tutto nel linguaggio procedurale PL/SQL di Oracle, e le sue funzionalità sono utilizzabili mediante l'interfaccia a linea di comando, oppure attraverso l’interfaccia grafica Oracle LogMiner Viewer (vedi figura), parte dell'Oracle Enterprise Manager, applicazione java per la gestione dei database Oracle.

LogMiner è stato pensato come strumento di ripristino in caso di problemi sul database. Per un'esauriente trattazione di LogMiner in quest'ambito si veda Expert One-on-One Oracle di Thomas Kyte.

Il principio di funzionamento è lo stesso della tecnica di dump che abbiamo visto nel post precedente, consentendo però l’accesso diretto ai file binari. LogMiner funziona all’interno di un’istanza del database, ma anche in questo caso può lavorare sui log di un'istanza diversa, soluzione da preferire sempre durante la fase investigativa.

L'uso di LogMiner in ambito forense è apertamente suggerito da Pete Finnigan, uno dei massimi esperti a livello mondiale di sicurezza su sistemi Oracle (autore dell'ottimo Oracle security step-by-step). Tuttavia recentemente un altro esperto del settore, Paul Wright, pur concordando sull'utilità come strumento di analisi forense, ha individuato un comportamento anomalo riguardo alla gestione delle date, che potrebbe inficiare i risultati delle analisi condotte con LogMiner su database a elevato numero di transazioni (i dettagli sono descritti in “Oracle database forensics using LogMiner”, intervento alla SANS Security 2004 Conference, Londra, giugno 2004).

Secondo Wright, quando LogMiner tratta e recupera dai log dati di tipo TIMESTAMP (mese, giorno, anno, ore, minuti, secondi, frazioni di secondo fino a 6 cifre decimali), in realtà li gestisce come dati di tipo DATE (mese, giorno, anno, ore, minuti, secondi), perdendo quindi le frazioni di secondo.

Lo stesso problema falsa le operazioni di ripristino dei dati di tipo TIMESTAMP, poiché vengono caricati con la parte decimale sempre pari a .000000, qualunque sia il reale valore memorizzato nei Redo Logs. A questo difetto sono soggette le versioni 9i e successive di Oracle, perché il formato TIMESTAMP è stato introdotto proprio con la 9i, e apparentemente nell'aggiornamento di LogMiner (nato con la versione 8) si è trascurata la differenziazione sul formato DATE.

Normalmente si tratta di un problema di poco conto per gli utilizzatori del database, ma i risultati ottenuti da LogMiner a fini investigativi potrebbero essere contestati in sede giudiziaria per l’intrinseca mancanza di precisione, almeno fino a quando il problema esposto non sarà risolto.

Nel frattempo accontentiamoci. Nel prossimo post analizzeremo la tecnica definitiva: l'analisi esadecimale dei log.

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!