Metodologie e tecniche per la sicurezza delle reti
Transcript
Metodologie e tecniche per la sicurezza delle reti
Corso di laurea in Scienze e tecnologie dell’informazione Metodologie e tecniche per la sicurezza delle reti aziendali RELATORE Prof. Ernesto Damiani TESI DI LAUREA DI Lorenzi Stefano CORRELATORE Matr. 754752 Dott. Claudio Agostino Ardagna Anno Accademico 2011/2012 Dedica La generazione dei numeri casuali è troppo importante per essere lasciata al caso. Robert R. Coveyou Ringraziamenti Sono diverse le persone che vorrei ringraziare, e che in modo diverso mi hanno aiutato a portare a termine questo ciclo di studi. Ringrazio innanzittutto Monica e Leonardo per la pazienza avuta in questi anni, e per avermi appoggiato in questo cammino. Ringrazio il Dott. Claudio Agostino Ardagna per la pazienza avuta nel correggere questo lavoro Ringrazio l’azienda Selex Elsag CyberLabs, per la quale lavoro, per la possibilità datomi di poter affrontare questa ricerca anche in ore lavorative, e tutti i colleghi, che in questi anni mi hanno aiutato a crescere professionalmente, e con i quali, quotidianamente c’è un piacevole confronto sulle tematiche affrontate in questo lavoro. Ringrazio gli amici Luca e Giusy, perchè questo percorso universitario ebbe inizio, quasi casualmente, da un invito a cena a casa loro. 2 Prefazione L’interdipendenza delle reti informatiche è in aumento, determinando nuove criticità e rischi tra i diversi sistemi, ormai fortemente integrati tra loro, interdipendenti e basati su piattaforme condivise. Oltre a disguidi tecnici, nuove minacce arrivano anche da tipologie di attacchi che fino a poco tempo fa sembravano solo teorici. Prendiamo come esempio Stuxnet, un worm informatico in grado di spiare e riprogrammare pc e plc industriali. E’ ormai evidente che è indispensabile proteggere tutte le nostre infrastrutture con nuove metodologie, con particolare attenzione a quelle informatiche. L’obiettivo di questo lavoro di tesi è l’analisi di un nuovo modello che possa fotografare nel modo più completo e dettagliato possibile il livello di sicurezza dell’infrastruttura presa in considerazione e, nel limite del possibile, di migliorarla. Il progetto di tesi propone un’analisi generale dell’ambiente partendo dall’applicazione e dall’infrastruttura, fino ad arrivare ai dati transitanti dalla rete, analisi che mette in evidenza le vulnerabilità in modo da identificare con precisione dove e perché intervenire, minimizzando i rischi per il business asset. La metodologia presentata in questo lavoro di tesi si caratterizza per la circolarità e la suddivisione del Vulnerability Assessment in 3 livelli: infrastrutturale, applicativo, policy aziendali. Per quanto riguarda l’analisi applicativa, in particolar modo per il mondo 3 web, OWASP rappresenta le fondamenta per questo tipo di analisi; essa sostiene che si raggiunge la sicurezza di un applicativo by design, ossia all’interno del ciclo di vita del software. L’analisi applicativa si suddivide in due parti, white e black box. La prima tecnica identifica le vulnerabilità a partire dal codice sorgente del componente, la seconda attraverso un insieme di test mirati. Nell’attività di VA è presente il problema di degradazione, in quanto nel tempo, sia nuovi asset che nuovi applicativi vengono aggiunti e nuove vulnerabilità vengono scoperte, modificando in questo modo la situazione analizzata precedentemente. La tesi mette in evidenza l’inadeguatezza di un approccio tradizionale con scansioni usando tool di vulnerability scanner (Nessus, Nikto etc..) e le possibilità date da un approccio complementare, come l’uso del passive vulnerability scanner (PVS), ossia il continuo monitoraggio del traffico di rete. In questo modo, verrebbe gestito almeno in parte il problema della degradazione del VA tradizionale. Inoltre, PVS osserva quali sistemi sono attivi, con quali protocolli comunicano e con chi comunicano, quale applicazione eseguono e quale vulnerabilità sono presenti. Queste informazioni vengono poi confrontate con le policy aziendali e l’Information Technology (IT) valuterà di conseguenza se bloccare o meno una determinata tipologia di traffico. E’ comunque fondamentale che la sicurezza di una struttura informatica non sia un’attività fine a se stessa, ma in continua evoluzione. Sarà quindi necessario, ciclicamente, analizzare la robustezza dell’infrastruttura e degli applicativi, affinché nuove vulnerabilità vengano scoperte. Sia i sistemi operativi che le applicazioni vengono continuamente aggiornate, con il rischio di introdurre nuove vulnerabilità. Il lavoro di tesi lascia spazio ad alcuni sviluppi futuri. Primo fra tutti, l’appro- 4 fondimento del vulnerability assessment nell’ambito delle basi di dati. Lavori futuri riguardano anche la ricerca di una metodologia atta a rilevare gli Advance Persistent Threat (APT). Tale metodologia permetterà di aggiungere le signature degli APT rilevati nelle regole dei sistemi di Intrusion Detection System (IDS), in modo da rendere l’infrastruttura ancora più sicura. 5 Indice Introduzione 13 1 Risk Analysis 21 1.1 Standard ISO 27001 . . . . . . . . . . . . . . . . . . . . . . . 22 1.2 La famiglia ISO 31000 . . . . . . . . . . . . . . . . . . . . . . 24 1.2.1 Standard ISO 31000 . . . . . . . . . . . . . . . . . . . 25 1.2.2 Standard ISO 31010 . . . . . . . . . . . . . . . . . . . 29 2 Progettare un vulnerability assessment 2.1 31 Definizioni della terminologia . . . . . . . . . . . . . . . . . . 31 2.1.1 Vulnerability scan . . . . . . . . . . . . . . . . . . . . . 32 2.1.2 Vulnerability assessment . . . . . . . . . . . . . . . . . 32 2.1.3 Risk assessment . . . . . . . . . . . . . . . . . . . . . . 33 2.1.4 Penetration Test . . . . . . . . . . . . . . . . . . . . . 34 2.1.5 Security assessment . . . . . . . . . . . . . . . . . . . . 35 2.1.6 Security Auditing . . . . . . . . . . . . . . . . . . . . . 35 2.2 Cos’è un vulnerability assessment . . . . . . . . . . . . . . . . 36 2.3 Le vulnerabilità . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.3.1 2.4 Le categorie delle vulnerabilità . . . . . . . . . . . . . . 42 Limitazioni di un VA . . . . . . . . . . . . . . . . . . . . . . . 49 6 3 Vulnerabilità infrastrutturali 3.1 51 Vulnerability scanner . . . . . . . . . . . . . . . . . . . . . . . 51 3.1.1 Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.2 Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.3 Microsoft baseline security analyzer . . . . . . . . . . . . . . . 55 3.4 Nikto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.5 Modalità d’uso di un vulnerability scanner . . . . . . . . . . . 57 4 Performance Analysis 62 4.1 Valutazione prestazionale e affidabilità di Sistemi Complessi . 62 4.2 RAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.2.1 Reliability - Affidabilità . . . . . . . . . . . . . . . . . 65 4.2.2 Availability - Disponibilità . . . . . . . . . . . . . . . . 69 4.2.3 Maintainability - Mantenibilità . . . . . . . . . . . . . 70 4.2.4 Safety - Sicurezza . . . . . . . . . . . . . . . . . . . . . 71 4.3 Tecniche di Analisi e Modellazione dei Sistemi Software . . . . 71 4.4 Tool per stress test . . . . . . . . . . . . . . . . . . . . . . . . 75 5 Owasp 78 5.1 Cos’è Owasp? . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.2 TOP 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.3 I tool di OWASP . . . . . . . . . . . . . . . . . . . . . . . . . 88 6 Vulnerabilità applicative 6.1 89 Vulnerabilità applicative . . . . . . . . . . . . . . . . . . . . . 89 6.1.1 SQL injection . . . . . . . . . . . . . . . . . . . . . . . 90 6.1.2 Cross-site scripting . . . . . . . . . . . . . . . . . . . . 94 6.1.3 Le Cross-Site Request Forgeries . . . . . . . . . . . . . 95 6.1.4 Buffer Overflow . . . . . . . . . . . . . . . . . . . . . . 97 7 7 Assessment applicativo 99 7.1 Analisi della web application . . . . . . . . . . . . . . . . . . . 101 7.2 Analisi dinamica (black box analysis) . . . . . . . . . . . . . . 103 7.2.1 IBM AppScan . . . . . . . . . . . . . . . . . . . . . . . 104 7.2.2 ZAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 7.2.3 Considerazioni . . . . . . . . . . . . . . . . . . . . . . . 105 7.3 Analisi statica (white box analysis) . . . . . . . . . . . . . . . 106 7.4 Extranet services . . . . . . . . . . . . . . . . . . . . . . . . . 107 7.5 Considerazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 7.6 Ciclo di vita del software . . . . . . . . . . . . . . . . . . . . . 110 8 Passive vulnerability scanner 115 8.1 Cos’è un passive vulnerability scanner . . . . . . . . . . . . . . 116 8.2 Vantaggi di un passive scanning . . . . . . . . . . . . . . . . . 117 8.3 PVS & vulnerability scanner . . . . . . . . . . . . . . . . . . . 119 9 Risk Exposure Analyzer 123 9.1 Risk Analisisys overview . . . . . . . . . . . . . . . . . . . . . 123 9.2 Skybox Security . . . . . . . . . . . . . . . . . . . . . . . . . . 125 9.2.1 Caso di studio . . . . . . . . . . . . . . . . . . . . . . . 129 10 Web Application Firewall 132 10.1 Caratteristiche dei WAF . . . . . . . . . . . . . . . . . . . . . 132 10.2 WAF e scansione applicativa . . . . . . . . . . . . . . . . . . . 134 11 Conclusioni 139 A Raccolta dati e reportistica 143 A.1 MagicTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 8 Elenco delle figure 1 Processo per la messa in sicurezza di una infrastruttura . . . . 17 2 Suddivisione in livelli della messa in sicurezza di una rete . . . 18 1.1 Shema Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . 22 1.2 ISO 31000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.3 Framework ISO 31000 . . . . . . . . . . . . . . . . . . . . . . 29 1.4 ISO 31010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.1 Suddivisione dei processi . . . . . . . . . . . . . . . . . . . . . 38 2.2 SANS Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . 43 2.3 Finestra temporale di una vulnerabilità. Fonte [5] . . . . . . . 47 2.4 Controllo remoto di un prompt dos . . . . . . . . . . . . . . . 49 3.1 Creazione di un policy con Nessus . . . . . . . . . . . . . . . . 54 3.2 Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.3 Microsoft baseline security analyzer . . . . . . . . . . . . . . . 56 3.4 Nikto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.5 Schema di rete . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.1 Classificazione dei guasti all’interno di un sistema. . . . . . . . 65 4.2 Andamento caratterisco di Z(t) . . . . . . . . . . . . . . . . . 68 4.3 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 9 4.4 Sistema in serie . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.5 Sistema in parallelo . . . . . . . . . . . . . . . . . . . . . . . . 70 4.6 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.1 Sicurezza - Costi . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.2 Modello di Metodologia di Test . . . . . . . . . . . . . . . . . 85 5.3 Finestra temporale di una vulnerabilità . . . . . . . . . . . . . 87 6.1 Owasp Zap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.1 SDLC OWASP Guidelines e tools . . . . . . . . . . . . . . . . 100 7.2 Struttura Web Application . . . . . . . . . . . . . . . . . . . . 101 7.3 Tipologie di security test . . . . . . . . . . . . . . . . . . . . . 102 7.4 Esplorazione e analisi di una web application . . . . . . . . . . 104 7.5 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.6 Zap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.7 Distribuzione delle vulnerabilità in modalità statica e dinamica 108 7.8 SLDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 8.1 cattura del traffico Firefox . . . . . . . . . . . . . . . . . . . . 118 9.1 Risk Exposure Analysis . . . . . . . . . . . . . . . . . . . . . . 127 9.2 CIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 9.3 Mappa di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 9.4 Skybox prima del bilanciamento CIA . . . . . . . . . . . . . . 130 9.5 Skybox dopo del bilanciamento CIA . . . . . . . . . . . . . . . 131 10.1 Riscontro scansione applicativa e WAF . . . . . . . . . . . . . 135 10.2 WAF in modalità offline . . . . . . . . . . . . . . . . . . . . . 137 10.3 WAF in modalità inline . . . . . . . . . . . . . . . . . . . . . 138 10 A.1 MagicTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 11 Elenco delle tabelle 5.1 Security web tool . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.1 tool per analisi statica . . . . . . . . . . . . . . . . . . . . . . 102 7.2 Caso specifico dell’intersezione . . . . . . . . . . . . . . . . . . 110 10.1 Visualizzazione vulnerabilità, scanner applicativo e un WAF . 137 A.1 MagicTree tool riconosciuti . . . . . . . . . . . . . . . . . . . . 144 12 Introduzione I computer si sono diffusi moltissimo in questo ultimo ventennio, e le reti informatiche stanno diventando ogni giorno sempre più complesse. Anche la loro accessibilità e la loro interdipendenza è in aumento, ed è proprio quest’ultima a determinare nuove criticità e rischi tra i diversi sistemi, ormai fortemente integrati ed interdipendenti, basati su piattaforme condivise. Un esempio è certamente quello accaduto nel 1998 al ”Galaxy IV”, il satellite per telecomunicazioni in orbita geo-stazionaria sulla costa occidentale degli Stati Uniti. Il suo guasto comportò ritardi di diverse ore per una ventina di voli della United Airlines in fase di decollo a causa della mancata comunicazione del clima in quota; alcune emittenti radiofoniche rimasero oscurate. Ma la cosa più sorprendente furono le conseguenze sul sistema di trasporto viario. Infatti, per l’impossibilità di trattare le carte di credito nelle aree di servizio lungo le autostrade, che utilizzavano le comunicazioni satellitari per la connessione con i circuiti degli enti emettitori, ci furono notevoli difficoltà nell’effettuare anche i rifornimenti di carburante ai veicoli. [12] La qualità della vita, la sicurezza e lo sviluppo nei paesi industrializzati dipendono ormai fortemente dal funzionamento continuo e sempre più coordinato di un insieme di infrastrutture che, per la loro importanza e strategicità, sono definite Infrastrutture Critiche, come ad esempio: • le varie reti di comunicazione; 13 • le reti e le infrastrutture di trasporto persone e merci (aereo, navale, ferroviario e stradale); • il sistema elettrico ed energetico; • le reti a supporto del Governo, delle Regioni ed enti locali; • i circuiti economico finanziari. Un altro caso si è verificato il 28 settembre del 2003, quando la rete elettrica italiana è stata separata dalla rete europea portando cosı̀ ad un collasso del sistema elettrico. Non è semplice valutare il danno economico di questo black-out, ma una stima è stata valutata intorno ai 640 milioni di Euro. [11] Oltre ai disguidi tecnici, da cui bisogna ad ogni modo proteggersi, altre minacce arrivano da nuove tipologie di attacchi che fino poco tempo fa sembravano solo teorici. Prendiamo come esempio Stuxnet, un worm informatico in grado di spiare e riprogrammare pc e plc industriali. Tale worm è stato scoperto a metà del 2010; pare che la sua implementazione risalga a inizio 2009. Symantec afferma che la maggior parte di pc infetti si trova in Iran: da qui le speculazioni in base alle quali l’obiettivo del virus potrebbero essere le centrali nucleari in costruzione nel paese asiatico. La contaminazione è iniziata tramite una chiavetta USB (presente praticamente in tutti i pc) per poi diffondersi attraverso la rete. La complessità di Stuxnet è insolita per un virus informatico in quanto l’attacco richiede la conoscenza dei processi industriali e mira all’attacco a infrastrutture industriali. Considerata la complessità del virus, per la sua realizzazione si sarebbe dovuto impiegare un team di programmatori di diverse discipline e la verifica di sistemi reali per evitare di bloccare il funzionamento del PLC. Secondo i tecnici Siemens, la creazione di questo malware avrebbe richiesto mesi se non anni di lavoro se 14 eseguita da una sola persona. Nonostante la sua giovane età, questo worm ha già subito diverse varianti: questo indica come gli sviluppatori di stuxnet siano attivi sul loro progetto. [15] Un nuovo modello per mettere in sicurezza una rete E’ ormai evidente che dobbiamo iniziare a proteggere tutte le nostre infrastrutture anche con nuove metodologie, con particolare attenzione a quelle informatiche ed è per questo motivo che questo lavoro vuole analizzare un nuovo modello, il cui obiettivo è quello di fare una fotografia il più completa e dettagliata possibile del livello di sicurezza dell’infrastruttura presa in considerazione. • Approccio - Il focus in questo genere di iniziativa è quello di valutare il livello di sicurezza di un ”Core Business Service” nel suo complesso, o quanto meno di tutte le componenti tecnologiche che lo compongono; • ”Check-up”completo - Oggi i budget a disposizione della security vengono normalmente dispiegati su perimetri molto estesi ma estremamente verticali; es. su tutta l’infrastruttura perimetrale, oppure su tutti i server dell’infrastruttura interna, oppure su tutta la rete, oppure ancora solo su diverse applicazioni web, solo sui client, ecc. Come detto sopra, focalizzando l’assessment su un unico ”Core Business Service”, possiamo permetterci di analizzare in maniera minuziosa tutte le componenti tecnologiche che lo abilitano (infrastruttura perimetrale, infrastruttura interna, applicazioni, DB, client, ecc.) in modo da individuarne eventuali vulnerabilità tecniche e organizzative e/o di sicurezza fisica 15 afferenti allo specifico servizio di business. Il concetto di fondo è che individuate 100 vulnerabilità sul ”Core Business Service”, verosimilmente l’80%, o più di queste saranno sicuramente presenti anche sulle componenti che abilitano tutti gli altri Business Service. In ultima analisi, l’approccio di questo lavoro consente all’ente interessato, a fronte dell’esito dell’assessment svolto su uno dei suoi servizi di business e messo a conoscenza dei propri processi interni usati per mettere in sicurezza tutti gli altri servizi, di andare ad applicare per analogia le evidenze emerse sul servizio analizzato agli altri componenti. Quello che si vuole proporre è un’analisi generale dell’ambiente partendo dall’applicazione e dall’infrastruttura, fino ad arrivare ai dati transitanti dalla rete. Tale analisi metterà in evidenza le vulnerabilità in modo da identificare con precisione dove e perché intervenire, al fine di minimizzare il più possibile il livello di rischio del proprio business asset. Possiamo quindi pensare che il processo utile per mettere in sicurezza una rete, possa i seguenti passi 16 Fig. 1: Processo per la messa in sicurezza di una infrastruttura In prima analisi, un’azienda deve valutare i propri rischi, a seconda del suo core bussiness, e valutare anche quanto investire nella sicurezza della sua infrastruttura. Successivamente, con l’esecuzione di Vulnerability Assessment, è possibile avere una prima fotografia della sicurezza, ed essere a conoscenza di eventuali vulnerabilità presenti nel sistema operativo,applicazione o db. Successivamente, attraverso l’uso di un IDS, sarà possibile valutare cosa transita nella rete, e attraverso pattern match, valutare se il traffico passante possa considerarsi lecito o meno. La figura 2 vuole mostrare come si potrebbe suddividere la gestione della messa in sicurezza di una infrastruttura. 17 Fig. 2: Suddivisione in livelli della messa in sicurezza di una rete Come vedremo nei capitoli successivi, i punti chiave da prendere in considerazione sono 3, ossia controlli di tipo 1. Infrastruturale: prende in considerazione la parte hardware del mondo IT, come i server, client, firewall etc; 2. Applicativo: prende in considerazione gli applicativi presenti sull’infrastruttura, dall’implementazione alla configurazione; 3. Policies: prende in considerazione le regole imposte dall’azienda, tipicamente gestite dal Security Manager aziendale. In questo lavoro si vuole analizzare una metodologia per mettere in sicurezza una rete aziendale di grandi dimensioni. Per fare questo, è necessario prima fare una analisi dei rischi in modo da valutare il grado di Confidentiality, Integrity, Availability (CIA) che si vuole dare all’azienda. Successivamente verrà fatta una fotografia della rete attraverso un approccio semitradizionale di Vulnerability Assessment (VA). Questo permetterà di dare un 18 primo output al cliente in tempi rapidi. Come vedremo, l’approccio tradizionale oltre a generare un alto traffico di rete, soffre del problema di degradazione. Per ovviare, almeno in parte, a questi problemi, l’integrazione di un sistema di Intrusion Detection System (IDS) può essere d’aiuto. La tesi è organizzata come segue: • Capitolo 1: breve riassunto dei principali standard che riguardano gli aspetti del mondo ICT; in particolare vengono prese in considerazione famiglie ISO 27001 [6] - 31000 [7] - 31010 [8]. • Capitolo 2: si imposteranno le basi di un’attività di VA, chiarendo la terminologia, troppo spesso usata a sprosito. Verrà illustrato il concetto di vulnerabilità e il suo ciclo di vita. Infine, verranno discussi alcuni limiti di questa attività. • Capitolo 3: in maniera sicuramente non esaustiva, verranno presi in considerazione i principali tool usati nelle attività di vulnerability scan. • Capitolo 4: verrà introdotto il concetto dell’acronimo Reliability (affidabilità), Availabity (disponibilità), Maintainability (manutenibilità), Safety (sicurezza) conosciuto con l’acronimo Rams con valutazioni delle prestazioni dell’infrastruttura analizzata. • Capitolo 5: viene descritta la metodologia OWASP [10], standard de facto nella sicurezza applicativa. Vengono anche discussi alcuni tool messi a disposizione dall’associazione OWASP per questo tipo di analisi. 19 • Capitolo 6: vengono discusse le principali vulnerabilità applicative, con particolare attenzione al mondo web, e come quest’ultime possono essere sfruttate da malintenzionati. • Capitolo 7: assessment applicativo, differenza tra analisi white box e black box. Verranno discusse queste due modalità, che viste sotto due insiemi differenti, ma con una parte di intersecazione aiuterà ad una eliminazione veloce dei falsipositivi. • Capitolo 8: verrà introdotto l’uso di un Intrusion Detection System (IDS), per la ricerca di vulnerabilità. Analizzando in maniera passiva il traffico passante in una rete è possibile trovare alcune vulnerabilità, oppure vedere violazioni di policy aziendali. Questa attività non genererà traffico aggiuntivo come dimostrato nel capitolo precedente e si rivelerà complemetare al vulnerability assemente tradizionale. • Capitolo 9: pesare correttamente le vulnerabilità trovate è fondamentale. Come vedremo, i tool usati danno spesso una classificazione del tipo alta, media o bassa. La stessa vulnerabilità trovata su un server web non può avere lo stesso peso della stessa vulnerabilità trovata su server di stampa. • Capitolo 10: si approfondirà l’uso di un WAF (Web Application Firewall) per mediare le vulnerabilità. A seguito di un alto numero di vulnerabilità trovate, non sempre è possibile sistemarle tutte in tempi brevi, mentre con l’uso di questi strumenti alcune possono essere mediate, per essere sistemate successivamente. 20 Capitolo 1 Risk Analysis Quando si gestisce una grande infrastruttura informatica e si lavora quotidianamente per la sua sicurezza è indispensabile avere ben chiaro quale tipo di sicurezza si vuole raggiungere (visto che è impossibile pensare alla sicurezza al 100%). Deve essere chiaro a quale rischio l’azienda è esposta, e a seconda del proprio core bussiness, valutare anche quali sono le priorità di remediation. Tipicamente, a seconda delle proprie esigenze e della disponibilità economica aziendale, viene anche predisposto un certo budget per trovare il giusto bilanciamento tra necessità e disponibilità. Nei capitoli successivi vedremo come trovare eventuali vulnerabilità presenti nell’infrastruttura o nelle applicazioni. Ma deve essere chiaro fin da subito che ogni vulnerabilità, andrà valutata in base al contesto, e quindi ripesata rispetto al risultato che avremo. E’ il caso ad esempio, di una vulnerabilità presente sia su un server web che su un server di stampa, probabilmente, daremo priorità al server web, in quanto contiene dati più sensisibili rispetto al server di stampa. Come mostrato in [1], nella pratica, nel risk analysis è necessario valutare i seguenti punti: 21 • esigenze in termini di sicurezza; • tipologia del dato trattato; • traffico di rete; • hardware a disposizione; • software utilizzato; • Servizi che si vogliono offrire. Fig. 1.1: Shema Risk Analysis Negli anni sono state implementate diverse best practice, per la gestine dell’analisi dei rischi, nel paragrafo successivo, vuole mostrare un breve riassunto su alcuni standard International Standard Organization (ISO). Si demanda naturalmente alla documentazione ufficiale per maggiori dettagli. 1.1 Standard ISO 27001 Lo Standard ISO 27001, è stata scritto nel 2005, riporta una serie di linee guida al fine di gestire un Sistema di Gestione della Sicurezza delle Informazioni (SGSI o ISMS dall’inglese Information Security Management System), 22 questa linee guida includono aspetti relativi alla sicurezza logica, fisica ed organizzativa. Come vedremo in questo lavoro, i dati possono essere fortemente a rischio, infatti violazioni dei sistemi informatici, come sostengono molte statistiche sono fortemente in aumento. L’obiettivo della ISO 27001 è proprio quello di proteggere le informazioni/dati, al fine di garantire l’integrità, la riservatezza e la disponibilità, e fornire al tempo stesso,i requisiti per adottare un adeguato sistema di gestione della sicurezza delle informazioni (SGSI) finalizzato ad una corretta gestione dei dati sensibili dell’azienda. Come la maggior parte delle ISO, anche la 27001, è stata scritta per poter essere applicata alla maggior parte dei settori commerciali. Inoltre questo standard, stabilisce i requisiti per il Sistema di Gestione della Sicurezza delle Informazioni (ISMS). L’obiettivo principale è quello di creare un sistema per la gestione del rischio e la protezione delle informazioni e degli asset ICT. La norma non è business oriented, ed è quindi applicabile a diverse tipologie di imprese, siano esse private o pubbliche. E’ fondamentale però l’adozione e gestione di un ISMS che a sua volta richiede un impegno di risorse significativo, per questo motivo spesso è un ufficio specifico che in genere coincide con l’ufficio Organizzazione e Qualità. Essa specifica i requisiti per impostare, mettere in opera, utilizzare, monitorare, rivedere, manutenere e migliorare un sistema documentato all’interno di un contesto di rischi legati alle attività centrali dell’organizzazione. Dettaglia inoltre i requisiti per i controlli di sicurezza personalizzati in base alle necessità di una singola organizzazione o di una sua parte. Il sistema è progettato per garantire la selezione di controlli di sicurezza adeguati e proporzionati. Riassumento lo standard 27001 prevede: • pianificazione e progettazione; – identificazione dei rischi; 23 – analisi e valutazione; – selezione degli obiettivi di controllo e attività di controllo per la gestione dei rischi; – assunzione del rischio residuo da parte del management; • implementazione; • monitoraggio; • mantenimento e il miglioramento. All’interno dello standard ISO 27001 è presente l’Annex A Control objectives and controls che contiene oltre 100 controlli a cui, l’organizzazione che intende applicare la norma, deve attenersi. Questi controlli spaziano su diversi argomenti, dalla politica e l’organizzazione per la sicurezza alla gestione dei beni e alla sicurezza delle risorse umane, dalla sicurezza fisica e ambientale alla gestione delle comunicazioni e dell’operativo, dal controllo degli accessi fisici e logici alla gestione di un monitoraggio e trattamento degli incidenti (relativi alla sicurezza delle informazioni). La gestione della Business Continuity e il rispetto normativo, completano l’elenco degli obiettivi di controllo. L’organizzazione deve motivare quali di questi controlli non sono applicabili all’interno del suo ISMS, per esempio un’organizzazione che non attua al suo interno ’commercio elettronico’ può dichiarare non applicabili i controlli 1-2-3 del A.10.9 che si riferiscono appunto all’e-commerce. 1.2 La famiglia ISO 31000 La famiglia ISO 31000 (che comprende la 31000 e la 31010) è stata pubblicata nel 2009, con l’intento di fornire uno standard per l’attuazione della gestione 24 dei rischi. Lo scopo di tale norma è quello di essere applicabile e adattabile per qualsiasi impresa pubblica, privata, associazione, gruppo o individuo, ne consegue che come una famiglia di standard di gestione del rischio, non è sviluppato per un particolare gruppo di settore, ma piuttosto vuole fornire la struttura delle best practice da seguire nelle operazioni che si occupano di gestione del rischio. Lo scopo della norma ISO 31000 è quello di fornire principi e orientamenti generali sulla gestione del rischio. questo standard mira a fornire un paradigma universalmente riconosciuto per i professionisti e le società che si occupano nei processi di gestione del rischio per sostituire la miriade degli standard presenti prima del 2009, anno di stesura dell’ISO 31000. Attualmente la famiglia ISO 31000 si suddivide principalmente in due parti: 1. ISO 31000: Implementazione di principi e linee guida; 2. ISO 31010: Risk Management - Risk Assessment Techniques. 1.2.1 Standard ISO 31000 L’introduzione alla nuova norma UNI ISO 31000 riporta: Le organizzazioni di tutti i tipi e dimensioni si trovano ad affrontare fattori ed influenze interni ed esterni che rendono incerto il raggiungimento dei propri obiettivi. Il rischio è l’effetto che questa incertezza ha sugli obiettivi dell’organizzazione. Ovviamente qualsiasi attività di un’organizzazione comporta un rischio: la loro gestione può essere applicata in qualsiasi momento a un’intera organizzazione, alle sue numerose aree e livelli, cosi come alle specifiche funzioni, progetti e attività. Applicabile a qualunque tipo di rischio, la UNI ISO 31000 Gestione del rischio - Principi e linee guida può essere utilizzata da imprese pubbliche, private o 25 sociali, associazioni, gruppi o individui e, pertanto, non è specifica per alcuna industria o settore. Per far sı̀ che la gestione del rischio sia efficace, un’organizzazione dovrebbe, a tutti i livelli, seguire gli 11 principi riportati nella norma, la figura 1.2 ne mostra il framework; 26 Fig. 1.2: ISO 31000 27 il successo della gestione del rischio dipende inoltre dall’efficacia della struttura gestionale di riferimento, che definisce le basi e gli assetti organizzativi per progettare, attuare e migliorare in continuo la gestione del rischio, nonchè per integrare la stessa all’interno dell’organizzazione. A tal fine, la norma fornisce indicazioni relative a: • l’impegno costante da parte della direzione per l’introduzione di una efficace gestione del rischio e per la relativa definizione di politica e obiettivi; • la progettazione della struttura di riferimento per gestire il rischio; • la definizione delle responsabilità; • l’integrazione della gestione del rischio nei processi organizzativi; • l’assegnazione delle risorse; • i meccanismi di comunicazione e reporting (interni ed esterni); • l’attuazione della gestione del rischio; • il monitoraggio, il riesame e il miglioramento continuo della struttura di riferimento. Il processo di gestione del rischio comprende, come indicato nella norma, un piano per la comunicazione e consultazione degli stakeholder, la definizione del contesto, l’identificazione e l’analisi del rischio, la sua ponderazione, trattamento, monitoraggio e riesame e la registrazione del processo stesso. La UNI ISO 31000 è l’adozione nazionale, in lingua italiana, della norma internazionale elaborata dal comitato tecnico ISO/TMB WG Risk management. 28 Per definire invece i termini di base relativi alla gestione del rischio, nel catalogo UNI è presente la norma UNI 11230 Gestione del rischio - Vocabolario che costituisce un riferimento generale applicabile a tutte le organizzazioni, al fine di promuovere un approccio coerente per la descrizione della gestione del rischio e l’utilizzo della terminologia pertinente. Fulcro di questa ISO è naturalmente il framework. Fig. 1.3: Framework ISO 31000 1.2.2 Standard ISO 31010 La presente norma internazionale è uno standard di supporto per ISO 31000 e fornisce indicazioni sulla selezione e applicazione di tecniche sistematiche per la valutazione del rischio. La valutazione del rischio fornisce ai responsabili, di comprendere come i rischi potrebbero compromettere il conseguimento degli obiettivi dei controlli già in atto. Questo fornisce una base per le decisioni sul metodo più idoneo da utilizzare per trattare i rischi. L’output del risk 29 assessment diventerà l’input ai processi decisionali dell’organizzazione. Come mostrato in figura 1.2, la valutazione dei rischi è quel processo globale che permette di: • identificare i rischi; • analisi dei rischi • valutazione dei rischi. Il modo in cui viene applicato il processo dipende non solo dal contesto del processo di gestione del rischio, ma anche sui metodi e le tecniche utilizzati per effettuare la valutazione del rischio. Fig. 1.4: ISO 31010 30 Capitolo 2 Progettare un vulnerability assessment Nel capitolo precedente abbiamo sottolineato l’importanza del risk analisys, e la necessità da parte dell’azienda di conoscere e valutare la propria esposizione al rischio. Una volta identificata quest’ultima, allora sarà possibile valutare quale tipo di Vulnerability Assessment sarà necessario applicare, considerando quale grado di dettaglio, e di conseguenza di costo, si vuole affrontare. 2.1 Definizioni della terminologia Ci sono diversi termini per identificare diverse attività di IT security, purtroppo però, non sempre vengono usate correttamente. E’ quindi importante mettere chiarezza fin da subito alle definizioni usate, come : • vulnerability scan, • vulnerability assessment, 31 • risk assessment, • penetration test, • security audit, • security assessment. 2.1.1 Vulnerability scan Viene generalmente indicata un’attività, completamente automatizzata delle vulnerabilità presenti in un sistema. Tipicamente vengono usati tool automatici, come Nessus o Iss Scanner. Il risultato di questa attività è generalmente un’informazione del tipo: Il server con indirizzo 192.168.1.10 ha il sistema operativo X versione y ha una vulnerabilità di questo tipo ... 2.1.2 Vulnerability assessment In questa attività, oltre a eseguire un vulnerability scan, è necessaria anche una verifica umana delle vulnerabilità presenti nel contesto. L’analista, dovrà pesare le vulnerabilità trovate e dare una priorità della sistemazione. Questa attività, grazie al lavoro umano, ha un valore aggiunto rispetto al vulnerability scanner. Infatti, l’analista si occuperà anche di: • depurazione di falsi positivi; • capire bene la topologia della rete; • potrebbe avere le regole dei firewall; • potrebbe essere a conosceza delle policy aziendali. 32 In questa attività, non si simula il malintenzionato, quindi, è necessario facilitare il più possibile l’attività di VA. Ad esempio, se la rete presa in considerazione ha un firewall, le varie scansioni è preferibile farle oltre il firewall. Questo perchè, come vedremo nel capitolo 3, farle prima dell’apparato genererebbe molti falsi positivi, in quanto il firewall blocca le richieste. In linea di massima, questa attività è poco invasiva: il security group si limita a ricercare le vulnerabilità e le segnala al cliente; alla fine si trova la soluzione migliore, cercando di mediare le vulnerabilità trovate e eventuali costi per un remediation plain. Tuttavia, in questa attività non vengono considerate alcune componenti importanti come: • componenti fisiche; • componente umana; • componenti procedurali. Un altro limite di questa attività è che essa soffre del problema della degradazione: infatti, periodicamente vengono aggiunti nuovi servizi, cambiate le installazioni, aggiunte o rimosse patch. 2.1.3 Risk assessment Questa attività segue una metodologia di analisi del rischio (nel mondo IT ci sono ISO 27001, 31000 e 31010) e vengono spesso usati tool BIA (Businnes Impact Analyst). Questi tool sono utili per quantificare il rischio e dimostrare l’importanza dell’investimento in sicurezza. 33 2.1.4 Penetration Test Questa attività richiede di simulare l’attività di un maleintenzionato e cerca di sfruttare almeno una vulnerabilità per raggiungere il suo fine, ossia prendere possesso della macchina remota, anche con metodologie e strumenti non convenzionali. Questa attività può essere condotta sia dall’interno che dall’esterno della rete analizzata. Tipicamente le attività eseguite dall’interno hanno lo scopo di verificare se esistono possibilità di accedere a file e/o dispositivi in modo inappropriato. Nei pentest, potrebbe essere richiesto di testare non solo le macchine, ma di valutare anche le persone addette a tali macchine; quindi tipicamente si suddivide in test di tipo: • overt o evidente: i dipendenti, con particolare attenzione all’IT, sono a conoscenza dell’attività in corso. In un contesto siffatto non ha senso l’utilizzo di metodologie di social engineering; • covert o nascosto: si esegue l’attività, con l’autorizzazione dei manager, e all’insaputa dello staff IT. In questa attività, ha senso testare anche la capacità e affidabilità degli addetti alla sicurezza durante un’emergenza e la reale validità delle politiche di sicurezza dell’azienda. Naturalmente, non è scontato che tale attività porti a garanzie positive. Potrebbe infatti accadere che il tecnico non penetri la macchina in questione, ma questo non significa che la macchina sia al sicuro da attacchi. Anche questa attività, come i Vulnerability assessment, soffre del problema della degradazione. Da un punto di vista teorico, ma non troppo, come dimostrato in [9], attraverso il social engineering, è possibile penetrare una rete o una macchina con ottimi livelli di sicurezza. In una attività del genere, non siamo interessati 34 a come una rete è stata progettata, ma nemmeno capire qual’è il suo stato attuale. Siamo interessati solo alla ricerca di una vulnerabilità, e qualora non la trovassimo, possiamo sempre basarci sul social engineering. 2.1.5 Security assessment Il security assesment è un’attività più ampia rispetto alle precedenti, comprende molte delle attività descritte in precedenza. Essa prende in considerazione: • sicurezza logica; • sicurezza informatica; • sicurezza infrastrutturale; • sicurezza sociale. Tale attività deve comprendere elementi di stato e di processo per evitare la degradazione. La metodologia di riferimento è proposta da OSSTMM (www.osstmm.org) 2.1.6 Security Auditing Quest’attività si preoccupa di identificare il livello di sicurezza aziendale e confrontarlo con le policy o con le best practice aziendali, entrambi prese come elemento di paragone. Quest’attività dovrebbe essere parte integrante dei processi aziendali e non una consulenza saltuaria. 35 2.2 Cos’è un vulnerability assessment Quando si parla di sicurezza informatica s’intende sempre la capacità di un sistema informativo di resistere, con un determinato livello di confidenza, agli incidenti o alle azioni illecite atte a compromettere disponibilità, autenticità, integrità e riservatezza dei dati presenti nel sistema stesso, o trasmessi a servizi o a rete informatiche. L’obiettivo di un VA è appunto quello di poter trovare, eventuali vulnerabilità presenti nella rete, in modo da poter successivamente proteggere al meglio l’organizzazione, tenendo in considerazione le differenti dimensioni della sicurezza: • disponibilità: riduzione a livelli accettabili del rischio di impedimento agli utenti autorizzati di fruire del sistema informativo e di accedere e utilizzare le informazioni, sia a seguito di fatti accidentali e/o naturali che di atti dolosi di soggetti non autorizzati; • integrità: riduzione a livelli accettabili del rischio di cancellazioni o modifiche di informazioni a seguito sia di fatti accidentali e/o naturali, che di atti dolosi di soggetti non autorizzati; • autenticità: che non esista dubbio di chi è responsabile di una informazione o della prestazione di un servizio, tanto al fine di avere fiducia di lui come di poterlo perseguire dopo eventuali inadempimenti o errori. In detrimento all’autenticità possono esserci sostituzioni ed inganni mirati a realizzare una frode. L’autenticità è la base per poter lottare contro il ripudio e, in quanto tale, fondamento per il commercio elettronico o per l’amministrazione elettronica, permettendo di avere fiducia senza bisogno di documenti cartacei né di presenzia fisica; 36 • riservatezza: riduzione a livelli accettabili del rischio di accesso improprio e dell’utilizzazione dell’informazione da parte di soggetti non autorizzati. Come molte attività, la pianificazione del lavoro è fondamentale, ed eseguirla bene è davvero complesso. Sono infatti molti i punti da sincronizzare in un’attività siffata, occorre perciò una pianificazione accurata del lavoro, coadiuvato insieme al cliente, anche per poter tener conto del livello di CIA (Confidentiality - Integrity - Availability) da lui richiesto. Per fare ciò, come spesso accade nel mondo informatico, di fronte a problemi complessi si cerca sempre di suddividere il problema in sottoproblemi (divide et impera). Nel caso specifico si suddivide in tre processi il lavoro: 1. preparazione; 2. analisi; 3. gestione; processi di questo genere, vengono successivamente organizzati in attività che, alla fine, si suddividono in compiti da espletare. 37 Fig. 2.1: Suddivisione dei processi In ogni compito si indica quello che si deve fare cosı̀ come le possibili difficoltà per poterlo eseguire al meglio, nonché il modo per affrontare con successo tale compito. Come detto sopra, è fondamentale, che nella fase di pianificazione sia coinvolto anche il cliente, per poter capire bene cosa si vuole fare nell’attività di VA e come farla. Di solito viene effettuato un kickoff meeting per organizzare il lavoro individuando: • scopo ed obiettivi: in questa fase si va alla ricerca degli asset da analizzare; • parti coinvolte: viene determinato quali uffici/aree vengono coinvolte nell’attività; • modalità: tipicamente si cerca di essere il meno invasivi possibile, quindi si concorda ad esempio, quanti asset vengono analizzati in parallelo, maggiore saranno gli asset, maggiore sarà il traffico di rete generato; 38 • tecniche ed approcci: si valuta il tipo di verbosità desiderata dal cliente; • tempistica di esecuzione. Più dettagliamente, ma in maniera non esplicativa, al fine di poter pianificare al meglio l’attività di VA è importante che nella parte di kickoff si possa rispondere ai punti seguenti, questo anche per avere delle informazioni iniziali che riguardano la struttura da analizza: • E’ possibile consultare gli schemi di rete? • Capire il perimetro della rete che si vuole analizzare; • La rete su quante sedi/filiali è strutturata? – Nel VA si vuole prendere in considerazione tutte le sedi/filiali? – Come avviene il collegamento tra le filiali? – Con quali regole (firewall,...) • Le macchine sono fisiche o anche virtuali? • La rete è mista (windows/linux)? • Quanti sono i server? E i client? • E’ possibile avere le regole dei firewall (questo è utile per pesare meglio eventuali vulnerabilità poi mediate dai firewall) • Esiste un sistema di backup? – Come avviene il backup? • Esiste una gestione dei log (fw e dei sistemi)? – Di quanti giorni? 39 – E’ centralizzato? – Come avviene il trasferimento dei dati (in chiaro o cifrato)? • Che tipologia di server sono presenti? (mail server, web server...) • Che tipo di applicazioni si usano in azienda? – Compilate o web? – Si vuole analizzare anche le applicazioni? – Si hanno i sorgenti di queste applicazioni? – Si vuole analizzare anche il loro comportamento? • Che impatto ha l’attività di VA sull’infrastruttura analizzata? • Valutare la sensibilità dei dati; • C’è qualche attività che il cliente non vuole che sia fatta? Come detto sopra, questa lista non vuole essere autoesplicativa, ma a seconda del contesto analizzato può essere perfezionata. Durante l’attività, solo una piccola parte dei dipendenti deve sapere che è in atto l’assessment, tipicamente managment e IT, i primi perchè hanno commissionato il lavoro, i secondi perchè dovranno dare supporto all’analista. Questo è dovuto al fatto che non devono esserci comportamente diversi dalla quotidianità, al fine di non sfalsare il risultato finale. 2.3 Le vulnerabilità Quando si parla di sicurezza di una rete informatica occorre prendere in considerazione l’ambiente esterno in cui il sistema viene a trovarsi. Cio’ permette di proteggere quest’ultimo da: 40 • accessi non autorizzati; • modifica o cancellazione di dati fraudolenta; • perdita di dati o introduzione di inconsistenze. Considerando che una rete è un insieme di apparati, occorre verificare periodicamente che tali apparati siano aggiornati, perchè sistemi operativi e firmware sono in continua evoluzione, nuove vulnerabilità vengono scoperte e quindi sistemate. Le vulnerabilità sono molte migliaia e riguardano sia servizi di rete, che applicazioni specifiche (IIS, Oracle, etc) e periodicamente i produttori rilasciano patch per le vulnerabilità note. In rete sono presenti molti siti che mettono a disposizione database con le vulnerabilità note, il loro stato e gravità. Seppur questa scelta sia stata in parte contestata dai produttori di software, essa rappresenta sicuramente un’opportunità per l’utente che viene cosı̀ messo a conoscenza dei potenziali rischi a cui è esposto e possa valutarne le contromisure. Alcuni siti che offrono questo servizio sono: • SANS; • Secunia; • Security Focus. Seppur ogni vulnerabilità è classificata con un indice di gravità (alta, media, bassa), come vedremo nel capitolo 9, di fatto queste gravità, come già detto in 1 veranno poi ”pesate”, perchè la gravità dipende dal contesto (la stessa gravità su un server web e su pc che gestisce una stampante ha peso differente); è importante sottolineare inoltre che non esiste una lista di vulnerabilità dalle quali sia necessario o sufficiente proteggersi. Per queste motivazioni occorre: 41 • monitorare gli annunci di nuove vulnerabilià inerenti ai propri sistemi; • adottare le contromisure suggerite (installazione di patch, riconfigurazione dei servizi, filtraggio di rete); • disporre di un’architettura di sicurezza e di policy adatte a minimizzare l’impatto di nuove vulnerabilità. 2.3.1 Le categorie delle vulnerabilità Poter categorizzare le vulnerabilità è importante per poter fissare delle priorità nelle contromisure da adottare. Ci sono situazioni, però, nelle quali non risulta conveniente installare la nuova patch che elimina una determinata vulnerabilità: è il caso di una macchina in produzione, dove eventuali patch al sistema operativo non sono state testate con una determinata applicazione. In questo caso è auspicabile testare prima il sistema in una situazione di laboratorio. Non esiste nemmeno una metrica standard per misurare la gravità di una vulnerabilità. Ogni organizzazione ha adottato criteri propri per indicare la gravità associata a ogni vulnerabilità. In questo lavoro viene preso come riferimento la classificazione CVSS, uno ”standard” comunemente accettato. La figura 2.2 prende in considerazione il sito di SANS, il quale suddivide le vulnerabilità in quattro classi: 1. Critical; 2. High; 3. Moderate; 4. Low. 42 Fig. 2.2: SANS Vulnerability Sono molti i fattori chiave presi in considerazione per valutare il grado della vulnerabilità. SANS prende in considerazione i seguenti punti: • diffusione del prodotto; • valutazione dell’asset: si tratta di un server o client? A che livello di privilegio? • il problema è stato trovato nelle configurazioni di default? • hanno un alto valore gli asset interessati (ad esempio database, ecommerce server)? • codice di exploit è pubblicamente disponibile? • quanto è difficile sfruttare la vulnerabilità? Remoto o locale? Senza credenziali o accesso fisico? 43 • quanto è complesso per un attaccante informato, realizzare il proprio exploit? Sono disponibili dettagli tecnici della vulnerabilità? Riporto dal sito Sans come loro catalogano le vulnerabilità: CRITICAL vulnerabilities are those vulnerabilities that typically affect default installations of very widely deployed software, result in root compromise of servers or infrastructure devices, and the information required for exploitation (such as example exploit code) is widely available to attackers. Further, exploitation is usually straightforward, in the sense that the attacker does not need any special authentication credentials, knowledge about individual victims, and does not need to social engineer a target user into performing any special functions. HIGH vulnerabilities are typically those that have the potential to become CRITICAL, but have one or a few mitigating factors that make exploitation less attractive to attackers. For example, vulnerabilities that have many CRITICAL characteristics but are difficult to exploit, do not result in elevated privileges, or have a minimally sized victim pool are usually rated HIGH. Note that HIGH vulnerabilities where the mitigating factor arises from a lack of technical exploit details will become CRITICAL if these details are later made available. Thus, the paranoid administrator will want to treat such HIGH vulnerabilities as CRITICAL, if it is assumed that attackers always possess the necessary exploit information. MODERATE vulnerabilities are those where the scales are slightly tipped in favor of the potential victim. Denial of service vulnerabilities are typically rated MODERATE, since they do not result in compromise of a target. Exploits that require an attacker to reside on the same local network as a 44 victim, only affect nonstandard configurations or obscure applications, require the attacker to social engineer individual victims, or where exploitation only provides very limited access are likely to be rated MODERATE. LOW vulnerabilities by themselves have typically very little impact on an organization’s infrastructure. These types of vulnerabilities usually require local or physical system access or may often result in client side privacy or denial of service issues and information leakage of organizational structure, system configuration and versions, or network topology. A questo punto, potrebbero sorgere un paio di domande: perchè la grande maggioranza delle intrusioni avviene sfruttando vulnerabilità note, per le quali esistono patch/upgrade da lungo tempo? Perchè alcune tecniche di intrusione (es. buffer overflow), pur essendo tecnicamente complesse da implementare, riescono ad essere utilizzate cosı̀ frequentemente? Per poter rispondere a queste domande è necessario introdurre due concetti: 1. ciclo di vita di una vulnerabilità; 2. finestra temporale di esposizione di un sistema. Ciclo di vita di una vulnerabilità Come ampiamente discusso in [5,16] una vulnerabilità attraversa fasi diverse della sua evoluzione che ne determinano la criticità e la diffusione. 1. Creazione: durante la fase di sviluppo viene introdotto nel codice un errore; 2. Scoperta: un esperto di sicurezza scopre l’errore all’interno del codice, intuisce che questo ha una o più conseguenze negative sulla sicurezza 45 del sistema. Da questo momento si parla di vulnerabilità e non più di errore nel codice; 3. Condivisione: la conoscenza della vulnerabilità scoperta viene fatta prima circolare in ambito ristretto, poi si diffonde anche grazie allo sviluppo di tool automatici che ne fanno uso; 4. Pubblicazione Patch/Upgrade: il produttore del sistema viene a conoscenza della vulnerabilità, quindi corregge l’errore emettendo una patch o una nuova versione del codice. La presenza di tale vulnerabilità, insieme alla presenza della patch disponibile viene resa pubblica. Finestra temporale di una vulnerabilità Come visibile dalla figura 2.3 tutti i sistemi sono soggetti a una finestra di esposizione, anche se gestiti al meglio. Infatti la scoperta di nuove vulnerabilità è impredicibile. Inoltre, la conoscenza dell’individuazione delle nuove vulnerabilità circola velocemente su chat, mailing list, ecc... e altrettanto velocemente la disponibilità di tool automatici atti all’utilizzo delle vulnerabilità trovate. Purtroppo, le patch rappresentano una soluzione spesso inefficace in quanto: • scarsa consapevolezza di molti sistemisti; • frequenza di emissione troppo elevata; • spesso causa di malfunzionamenti o nuovi problemi. 46 Fig. 2.3: Finestra temporale di una vulnerabilità. Fonte [5] E’ interessante notare che la curva di figura 2.3 cresce rapidamente nonostante il fatto che sfruttare alcune vulnerabilità sia complesso. Questo è dovuto principalmente a due fattori: 1. scripting: dopo le prime intrusioni, compiute da esperti, la tecnica per realizzarle viene automatizzata (scrittura di script, descrizione delle procedure); 2. script Kiddies: la disponibilità di exploit (tool automatici) permette di sfruttare con successo vulnerabilità nei sistemi anche a persone dotate di scarse competenze tecniche, aumentando drasticamente il numero dei potenziali attaccanti. Un esempio pratico è il seguente: installare un Windows Server 2003 con una installazione di default e analizzare come sia possibile attaccare questa macchina. Successivamente si lancia uno scanner (che vedremo nel paragrafo 47 3.1 e si osservano le vulnerabilità presenti sul server (nel caso specifico 9 vulnerabilità Alte). Si può notatare subito la presenza di vulnerabilità legate al buffer overflow, nel caso specifico del problema di RPC (vulnerabilità storica su questo sistema operativo), sarà relativamente semplice sfruttare questa vulnerabilità: in pochi minuti sarà possibile avere a disposizione un prompt di dos, da dove sarà poi possibile creare, modificare ed eliminare files. La semplicità e la velocità con cui è possibile sferrare il seguente attacco convince sempre più dell’utilità di un security assesment a livello infrastuturale. 48 Fig. 2.4: Controllo remoto di un prompt dos 2.4 Limitazioni di un VA E’ importante, mettere subito in chiaro che questo genere di attività, pur portando sicuramente un valore aggiunto alla sicurezza attuale dell’infrastruttura aziendale presa in considerazione, ha anche delle limitazioni. Come detto a inizio capitolo, questa attività soffre del problema di degradazione, ossia, nel tempo nuove vulnerabilità verranno scoperte, nuove macchine verranno aggiunte o tolte dalla rete, nuove patch verranno installate sulle macchine, nuovi servizi pure. Inoltre è importante sottolineare che il VA, è una fotografia della situazione del momento, è quindi fondamentale che i vari apparati, che si vuole analizzare, siano accesi e collegati alla rete. 49 Spesso le workstation sono multi-utente, ed ogni utente abilita servizi personali, ovviamente durante l’attività di VA essendo attivo un solo utente, solo quest’ultimo verrà analizzato. E’ quindi fondamentale, che l’attività di analisi, la macchina sia loggata con l’utenza più usata, o comunque di maggior interesse. Inoltre a volte è possibile che alcune workstation, abbiano installata una o più macchine virtuali, e anche quest’ultime potrebbero essere messe in rete, queste macchine, se non sono attive, non saranno analizzate. 50 Capitolo 3 Vulnerabilità infrastrutturali In questo capitolo sono elencati i principali tool per le scansioni a livello infrastrutturale, come vedremo nel seguito, un aspetto fondamentale è dove posizionarsi all’interno dell’infrastruttura al fine di trovare le vulnerabilità. 3.1 Vulnerability scanner Sono molti i tool di vulnerability scanner presenti sul mercato. In questo lavoro verrà preso in considerazione Nessus. Questa scelta è dovuta al fatto che è sicuramente il tool più noto per questa tipologia di attività, inoltre, rilascia il report finale in diversi formati, tra cui il formato xml. Questo formato, è molto malneabile, e ci permette di gestirlo nel tool che vedremo nel capitolo 9 e nell’appendice A, infatti, questo formato ci permetterà di poter correlare una serie di vulnerabilità trovate nelle diverse fasi dell’assessment. E’ importante sottolineare che il focus di questa parte del lavoro è quello di riuscire, tramite questa metodologia di vulnerability assessment, di assegnare un peso alle vulnerabilità trovate. Questo ci permetterà di concentrarsi meglio sulle vulnerabilità realmente critiche per l’azienda. Supponiamo che 51 il tool di vulnerability scanner usato rilevi una stessa vulnerabilità critica a diverse macchine. Pur avendo la stessa vulnerabilità, è probabile che peseremo in maniera differente la criticità trovata sul server web, rispetto al server di stampa. Oppure, se abbiamo una vulnerabilità alta, ma siamo certi che tale vulnerabilità non possa essere sfruttata in quanto bloccata dal firewall, probabilmente ci concentreremo su altre vulnerabilità trovate. 3.1.1 Nessus Nessus è un progetto che ha come scopo quello di fornire alla comunità uno strumento potente e facile da usare, per poter scoprire e analizzare le vulnerabilità presenti in una rete, al fine di evitarne lo sfruttamento da parte di utenti maliziosi. E’ probabilmente il più completo ed evoluto strumento di vulnerability scanning disponibile nel mondo free-ware. Come riportato in [4], Nessus è un software proprietario del tipo client/server sviluppato da Tenable Network Security. Il client è basato su un’interfaccia web sviluppata in Flash. Periodicamente vengono rilasciati dei nuovi plugin che coprono i diversi protocolli, backdoor, applicazioni e vulnerabilità locali: in questo modo è possibile rilevare le reali applicazioni in esecuzione su ogni porta aperta. Alla base del suo funzionamento vi è un sistema di abilitazione di plugin, al fine di creare le cosiddette policy. Al momento dell’esecuzione di una scansione, è necessario creare una policy adatta alla scansione in atto. Tale prodotto è installabile sui seguenti sistemi operativi: • Microsoft Windows; • Mac OS X; • Linux; 52 • FreeBSD; • Solaris. Sono possibili scansioni diverse: dall’interno della rete (per ottenere quante più informazioni è possibile su potenziali vulnerabilità o debolezze del sistema target) e dall’esterno. In questo modo è possibile valutare quali vulnerabilità sono presenti e a seconda del contesto sarà possibile capire ciò che un malintenzionato (interno o esterno) è in grado di poter fare. E’ prassi fare un’approfondita analisi dei server a livello di interfaccia tra la rete locale e internet, ovvero quell’insieme di server che viene normalmente definito come DMZ (zona demilitarizzata). Quest’ultimo termine specifica una sottorete inserita come zona neutrale tra la rete privata di un’organizzazione e internet, zona che permette connessioni esclusivamente verso l’esterno: server di posta elettronica, server HTTP con applicazioni web o server VPN. Nessus, inizialmente lancia una scansione sulle porte per verificare quali sono i servizi attivi e la tipologia di sistema operativo presente sulla macchina o presenti nella sottorete target. La fase di scansione delle porte è fondamentale: questo ci permette di stabilire la tipologia del target e, di conseguenza, ci permette di sapere quali plugin sono pertinenti a quel target (ad esempio Apache o ISS plugin per un server web o vulnerabilità del sistema operativo) e quale servizio è attivo su tale porta. Naturalmente, questo tool è anche in grado di rilevare servizi anche su porte non standard. Qualora fosse necessario eseguire una scansione su una rete di grande dimensioni, sarebbe opportuno posizionare un server Nessus per ogni segmento di rete. Inoltre, qualora fossero note alcune caratteristiche della macchina sulla quale si esegue la scansione, come ad esempio il sistema operativo o servizi in esecuzione, allora è possibile impostarli al momento della creazione della 53 policy. Ciò permette di fare scansioni molto mirate e più performanti. Finita la scansione, Nessus genera un report indicante una lista di tutte le porte aperte e i potenziali rischi associati. Sarà poi possibile esportare tali report in vari formati, come ad esempio HTML o PDF, oppure un formato nativo (un file xml che viene poi importato successivamente in un tool di risk analysis che vedremo nel capitolo 9). Fig. 3.1: Creazione di un policy con Nessus 3.2 Nmap E’ probabilmente il port scanning più famoso al mondo è molto affidabile e versatile, ormai presente in tutte le distribuzioni linux, sistemi windows e mac. E’ capace di effettuare scansioni delle porte ad un computer, o ad un’intera rete allo scopo di rilevare i servizi attivi; ipotizza il sistema operativo del computer remoto, in maniera molto affidabile. Permette inoltre di trovare applicazioni server installate su una macchina. Le scansioni possono 54 essere eseguite in diverse modalità, al fine di non farsi rilevare dai vari apparati presenti nella rete, o per non generare troppo traffico, è infatti possibile effettuare scansioni tcp (con handshake completo), con scansioni syn, XMAS e molte altre modalità. Fig. 3.2: Nmap 3.3 Microsoft baseline security analyzer La piattaforma più utilizzata, almeno nell’ambito workstation, è senza dubbio quella Microsoft, questo comporta un maggior interesse, da parte dei malintenzionati, a trovare vulnerabilità su tale piattaforma. Per questo motivo, è fondamentale, avere tali macchine aggiornate con tutte le patch di sicurezza, che Microsoft rilascia regolarmente il primo martedi di ogni mese. Inoltre Microsoft, mette a disposizione di tutti, gratuitamente un prodotto che si chiama Microsoft baseline security analyzer. Tale prodotto, fa una scansione di tutti i software microsoft installati come: 55 • Microsoft Windows; • Internet Explorer; • IIS web server; • Microsoft SQL Server; • Microsoft Office. E’ fondamentale, fare un controllo con questo tool, in un contesto di macchine Microsoft. Fig. 3.3: Microsoft baseline security analyzer 3.4 Nikto Nikto è uno web server scanner open source, che esegue test completi e approfonditi contro i vari elementi di un server Web, potenzialmente pericolosi, come CGI, verifiche di versioni obsolete di server, e problemi specifici di una determinata versione di server. Inoltre, controlla alcuni parametri di configurazione del web server, come ad esempio alcune parametri di default che 56 potrebbero essere modificati, per rendere meno lasche le regole; ricerca anche eventuali plugin installati (spesso le vulnerabilità sono presenti proprio nei plugin). Non tutti i controlli riguardano la sicurezza, seppur lo siano la maggioranza, ma ci sono alcuni verifiche che sono solo informazioni. Nikto, non è concepito come uno strumento furtivo, ma al contrario, uno strumento per valutare il livello di sicurezza del proprio server web. Permette infatti di testare un server web nel minor tempo possibile. Tuttavia, vi è il supporto anti-IDS, ossia metodi nel caso in cui si desidera fare un tentativo di penetrazione al server, ma questo deve essere visto, come una possibilità di mettere alla prova il vostro sistema IDS. Fig. 3.4: Nikto 3.5 Modalità d’uso di un vulnerability scanner I tool di scansione delle vulnerabilità sono sicuramente utili, tuttavia è richiesto una modalità d’uso adeguata al contesto, e un lavoro manuale, a fine scansione, per poter eliminare eventuali falsi positivi. Infatti, questi tool in alcune circostanze possono portare a esiti non corretti: 57 • un firewall o un altro dispositivo di sicurezza possono aver rilevato la scansione in corso. Ad esempio, se il nostro firewall è in grado di rilevare la scansione, dopo pochi secondi, esso blocca tutto il traffico generato dallo scanner usato. Il rapporto mostrerebbe un sacco di porte aperte che non esistono sul target, perché ha travisato la perdita di pacchetti; • alcuni controlli di vulnerabilità sono troppo superficiali. A volte, un plugin cerca la versione solamente nel banner. Questo potrebbe non essere sufficiente per sapere se il servizio è a tutti gli effetti vulnerabile. In generale, possiamo sostenere che i risultati della scansione riportano potenziali problemi che dovrebbero successivamente essere controllati uno ad uno. Ovviamente, Nessus è in grado di fare scansioni complete, che naturalmente richiedono un tempo di esecuzione maggiore. Per questo motivo, è preferibile personalizzare le aree che dovrebbero essere controllate. Infatti, riducendo il numero dei controlli che vengono fatti e configurando le impostazioni normalmente di default, è possibile sia ridurre la durata della scansione sia migliorare la sua accuratezza. Tutte queste impostazioni sono associate alla policy. Questo significa che ogni target che richiede particolari impostazioni (password diverse per esempio), impone la propria policy. Una volta creata e impostata la policy d’interesse, è possibile settare tutte le credenziali della macchina target conosciute. Nessus dispone di molti plugin, attualmente sono oltre 45.000; per una migliore organizzazione sono raggruppati in poco più di 40 famiglie di plugin (ad esempio CISCO, FTP, Web Servers ecc). Per ogni plugin è disponibile una breve delucidazione, contenete questi campi: • Synopsis; 58 • Description; • Solution e See Also. La figura 3.5 vuole rappresentare uno schema di esempio di come potrebbe essere una rete informatica, e di come e cosa uno scanner deve lavorare. Fig. 3.5: Schema di rete Come visibile dalla figura 3.5 sono diversi gli apparati hardware presenti nell’infrastruttra. Nello specifico, l’infrastruttura è composta da : • 3 Server; • 1 router; 59 • 1 firewall; • 2 switch; • 2 workstation; • 1 portatile. Troppo spesso, la manutenzione dell’infrastruttura, è basata pensando ai soli server, a volte i client, ma difficilmente viene fatta, la dovuta manutenzione, su alcuni apparati hardware. Ad esempio, spesso i router, vengono dati in comodato d’uso dall’ISP, ma nessuno si occupa dell’installazioe delle patch. Spesso, aziende esterne, preparano e configurano la rete, fornendo in prima persona il materiale (ad esempio switch), e non sempre il materiale è recente, a volte vengono installati apparati hardware presenti in magazzino, e con configurazioni di default. Sono appunto queste configurazioni che spesso vengono sfruttate da malintenzionati. A titolo di esempio, riporto alcuni dati riscontrati in attività di questo genere su una rete di recente creazione: • CVE-1999-0186: Vulnerabilità trovata sul router, questa vulnerabilià, permette ad un attaccante remoto, di mandare in esecuzione un codice arbitrario con privilegi di root. E’ interessante notare, che questa vulnerabilità, ha un valore di 10 (su una scala da 0 a 10), e tale vulnerabilità è nota dal 1999. Dopo 12 anni, questa vulnerabilità, è ancora sfruttabile; • sullo switch: The remote device is missing a vendor-supplied security patch; • sullo switch: The remote Cisco router has a default password set; • molto altro. 60 In maniera analoga, troppo spesso si riscontrano regole sui firewall di chiusura totale verso l’interno, totale apertura verso l’esterno. E’ evidente che una regola di firewall sifatta, permette ad un troian, di mandare fuori dei dati, inoltre, se si vuole fare una fotografia, alla rete aziendale, anche le regole dei firewall hanno la loro valenza. Come vedremo infine, nel capitolo 9, un firewall ben configurato, potrebbe anche mediare una vulnerabilità presente. Prendiamo come esempio i sistemi XP/2003, hanno vulnerabilità gravi sulla porta 445, ma se il firewall chiude la porta 445, allora si potrebbe ripesare tale vulnerabilità. Come scritto sopra, spesso gli scanner automatici riportano dei falsi positivi, questi possono essere dovuti alla presenza di un firewall. E’ fondamentale quindi la scelta della posizione dello scanner; nella figura 3.5 ad esempio, avrebbe senso posizionarlo all’interno delle 2 sottoreti, in questo modo però bisogna ricordarsi del router. Anche questo apparato fa parte della rete, e essendo perimetrale, probabilmente è il più importante, ma nonostante tutto troppo spesso viene dimenticato. 61 Capitolo 4 Performance Analysis Nel capitolo precedente, è stato descritto come rilevare le vulnerabilità all’interno dell’infrastruttura, in questo capitolo sarà invece discusso un altro problema importante ossia avere la disponibilità dell’infrastruttura stessa. Un tipico esempio, sono i server web presenti nelle grandi aziende, generalmente sono più di uno, in modo tale da poter suddividerne il carico di lavoro, o nel caso in cui un server si dovesse guastare, il servizio può continuare a essere erogato. 4.1 Valutazione prestazionale e affidabilità di Sistemi Complessi Come anticipato nell’Introduzione, la nostra società è fortemente basata sull’utilizzo di architetture critiche, le quali spesso eseguono complesse elaborazioni, e dal punto di vista della sicurezza, devono garantire continuità del servizio erogato. Un elevato livello di qualità, senza guasti nè periodi di inattività che porterebbero a conseguenze catastrofiche, deve essere garantito. Inoltre, a causa della sempre maggiore interdipendeza e dell’evoluzione tec62 nologica dei sistemi informatici, la natura dei sistemi attualmente utilizzati diventa sempre più articolata. Ne consegue che è aumentata la difficoltà nel garantire elevati livelli di comportamento del sistema in termini di affidabilità e continuità del servizio. Diventa quindi fondamentale la continua verifica di alcune proprietà del servizio offerto, come: • qualità, • disponibilità, • affidabilità, • tolleranza ai guasti, • intrusioni. Queste proprietà del sistema devono quindi essere garantite durante tutto il ciclo di vita, dalla fase di progetto, attraverso il suo uso e manutenzione, fino alla sua dismissione. Diventa cosı̀ fondamentale dover fare degli stress test alle applicazioni e al sistema, per valutare quale livello di carico di lavoro questi ultimi supportano. 4.2 RAMS Come Fulvio Corno e i suoi collaboratori del Politecnico di Torino discutono in un loro articolo [13], quando si parla di sistemi elettronici sicuri, l’acronimo RAMS indica Reliability (affidabilità), Availabity (disponibilità), Maintainability (manutenibilità), Safety (sicurezza), queste proprietà devono sempre essere garantite nei vari sistemi sia hardware che software. All’interno dei vari sistemi possiamo avere le seguenti anomalie: 63 • Fault: stato improprio dell’hardware o del software del sistema, causato dal guasto di un componente, da fenomeni di interferenza o da errori di progettazione. • Error: è quella parte dello stato del sistema esposta a provocare successivi fallimenti. Un errore nel servizio è un’indicazione che un guasto è in atto, ovvero la causa ipotizzata di un errore è un guasto. Uno stesso fault può generare più errori (multiple related error). • Failure: evento in corrispondenza del quale i servizi offerti non corrispondono più alle specifiche preventivamente imposte al sistema. Quando si parla di Fault, si prendono in considerazione le seguenti proprietà del seguente stato: • Fault tolerance: tecniche orientate alla minimizzazione delle conseguenze dei guasti e che tendono ad evitare che essi possano degenerare in un failure. Quindi si occupano di come garantire un servizio che si mantenga conforme alle specifiche, nonostante i guasti. Tipicamente, esse si articolano in due fasi: error detection ed error treatment. • Fault removal: tecniche orientate all’individuazione degli errori e alla rimozione dei guasti durante lo sviluppo o in fase operativa; per ridurre l’occorrenza (numero, gravità) dei guasti. • Fault avoidance: tecniche orientate a minimizzare la probabilità di occorrenza dei fallimenti. Tali tecniche, implicano l’utilizzo di componenti altamente affidabili che, pertanto, comportano un incremento dei costi. Sono tecniche relative alla fase di definizione delle specifiche, progettazione e codifica. La figura 4.1 mostra come sono classificati i guasti all’interno di un sistema. 64 Fig. 4.1: Classificazione dei guasti all’interno di un sistema. 4.2.1 Reliability - Affidabilità Come discusso in [14], i primi a studiare i problemi legati alla scarsa affidabilità, sono stati gli americani negli anni ’60, seppur all’epoca riguardassero gli equipaggiamenti militari in generale (e non solo gli apparati elettronici), emerse che: • gli equipaggiamenti elettronici erano operativi solo per il 50% del tempo; • 2/3 degli equipaggiamenti dell’esercito erano in riparazione. L’affidabilità dell’hardware, è la probabilità che il sistema sia funzionante al tempo t sapendo che lavori al tempo t0 , mentre l’affidabilità del SW è il numero di errori presenti nel codice, o meglio la probabilità che non funzioni 65 nell’eseguire un set di istruzioni con errori. Se si vuole ottenere un prodotto affidabile è fondamentale partire da un progetto affidabile attraverso: • linee guida in progettazione; • previsione di affidabilità ed analisi del rischio; • miglioramento dell’affidabilità. Il calcolo dell’affidabilità di un sistema comporta in generale l’applicazione di regole di decomposizione gerarchica di un sistema in sotto-sistemi.In altre parole, l’affidabilità del sistema dipenderà dall’affidabilità dei singoli componenti e da come essi interagiscono tra loro SW compreso (studiando i relativi moduli e da come essi sono collegati). La probabilità è un numero compreso tra 0 (evento impossibile) e 1 (evento certo). Ne consegue che l’affidabilità può essere vista come: R(t) = nO (t) nO (t)+nF (t) dove per nO sono i componenti operativi e per nF sono i componenti nello stato Fault. Quindi R(t) è la probabilità che il componente sia sopravvissuto all’intervallo (t0 , t), è ovvio che prolungando il tempo, il numero di componenti funzionanti NO diminuisce e conseguentemente la funzione d’affidabilità diminuisce. In maniera analoga, la probabilità di un guasto può essere vista come: Q(t) = 1 − R(t) = 1 − nO (t) nO (t)+nF (t) Q(t) è la probabilità che un componente non sia sopravvissuto all’intervallo (t0 , t), chiamata anche funzione di densità di malfunzionamento. Esempio 1: Si effettua un test di 10 dispositivi dello stesso tipo, misurando 66 per ciascuno il tempo in cui si verifica un guasto in modo approssimato se 1000 ore è il tempo di vita desiderato per un determinato progetto, se solo 6 pezzi hanno avuto una durata maggiore di 1000 ore, allora R(1000) = 6 / 10 = 0,6 La formula dell’inaffidabilità è invece: Q(t) = nF (t) nO (t)+nF (t) E’ possibile calcolare il ritmo del cedimento di un componente calcolando la derivata di R(t) rispetto al tempo R(t) = 1 − Q(t) = 1 − dR(t) 1 dNf (t) = − dt N dt dNF (t) dt dove dNF (t) dt NF (t) N = (−N ) dR(t) dt si può interpretare come il numero di componenti che subiscono un guasto per l’intervallo di tempo dt compreso tra t e t+dt; che equivale alla velocità di guasto al tempo t. dNF (t) dt = (−N ) dR(t) dt Dividendo entrambi i membri per NO (t) si ottiene z(t), detta funzione di pericolo, o tasso di guasto, o tasso di fallimento (probabilità di guasto nell’unità di tempo). z(t) = Essendo R = NO N 1 dNF (t) NO (t) dt = − NON(t) dR(t) dt il tasso di guasto si può scrivere: dR(t) dt z(t) = − R(t) 67 integrando z(t) si ottiene: z(t)dt = − dR(t() R(t) R R(t) dR(t) R R Rt z(t)dt = R(0) R(t) = 1 0 Rt z(t)dt = −lnR(t) 0 R t R(t) = exp − 0 dt dR(t) R(t) Quindi z(t) non è costante nel tempo, ma evolve attraverso 3 fasi: 1. mortalità infantile (o periodo di rodaggio); 2. vita utile; 3. invecchiamento. Nella regione di vita utile: z(t) ∼ costante = λ (failure rate) Fig. 4.2: Andamento caratterisco di Z(t) 68 4.2.2 Availability - Disponibilità Nel caso di sistemi riparabili è necessario considerare anche l’evento riparazione o sostituzione. Si definisce disponibilità la quantità : A= MT T F M T T F +M T T R dove per MTTF si intende Mean TimeTo Failure e per MTTF si intende il Mean Time To Repair. Fig. 4.3: Availability E’ importante sottolineare che nei sistemi in serie, il guasto di un’unità pregiudica il funzionamento dell’intero sistema. Fig. 4.4: Sistema in serie Nei sistemi in serie, assumendo guasti indipendenti, possiamo sostenere : R(t) = QN Ri (t) Q A= N i=1 Ai (t) i=1 Mentre nei sistemi in parallelo, il sistema è guasto se tutte le n unità sono guaste 69 Fig. 4.5: Sistema in parallelo quindi in questo caso particolare possiamo sostenere che: R(t) = 1 − 4.2.3 QN i=1 (1 − R1 (t)) Maintainability - Mantenibilità Rappresenta la relazione alla capacità di essere sottoposto a modifiche e/o riparazioni, un sistema dependable è mantenibile. Esso rappresenta la probabilità M(t) che il sistema malfunzionante possa essere riportato al suo corretto funzionamento entro il periodo t. Il tasso di riparazione µ è definito attraverso la relazione: µ= 1 MT T R La distribuzione di M(t) è: M (t) = POP (t) = 1 − e−µt 70 4.2.4 Safety - Sicurezza Per Safety, in ingegneria, si intende la distribuzione S(t), essa esprime la probabilità che un sistema sia funzionante o sia in uno stato sicuro (fail-safe) al tempo t. Il sistema sarà safety se, a fronte di un guasto, si porta in uno stato di fallimento NON catastrofico. Fig. 4.6: Safety 4.3 Tecniche di Analisi e Modellazione dei Sistemi Software Le archittetture software ricoprono un ruolo importante nella progettazione di un sistema moderno. La complessità e la criticità di tali applicazioni e gli stringenti requisiti di qualità del servizio fanno si che le prestazioni dell’intero sistema dipendano fortemente da tutte le componenti: • hardware; • rete; • software. 71 Lo studio prestazionale dei sistemi software si differenzia dalle tecniche classiche per molteplici motivi: l’elevata complessità del software, le interazioni tra differenti componenti (software applicativi, sistemi operativi, macchine virtuali, ecc.) e tra software e utenti (con conseguenti comportamenti aleatoristocastici), i processi di debugging, testing, la presenza di componenti non sempre open source (ad es. software proprietari). E’ fondamentale, durante i vari step del ciclo di vita del software poter eseguire dei stress test. Infatti è importante valutare periodicamente l’impatto del software anche in condizioni di cambiamento hardware, ad esempio: • cosa succede se la topologia di una rete cambia? • cosa succede ad una infrastruttura se cambia il tipo di carico? (e.g. DNSSEC) • cosa succede se cambio una politica di gestione delle risorse? • cosa succede se aumento la capacità del sistema o parte di esso? Per osservare un sistema reale occorre utilizzare strumenti di misura e monitoraggio (non invasivi) e collezionare informazioni rappresentative del suo comportamento (in relazione all’oggetto dello studio): • livello di sistema: uso della CPU, disk I/O, NIC I/O; • livello di applicazione: tipi di richieste, tassi di arrivo; • livello di rete: traffico IP, traffico TCP, traffico DNS. Tra i problemi tipici dell’ambito di rete ci sono i ritardi e le interruzioni di comunicazione. Queste disfunzioni possono essere determinate da vari fattori: 72 • traffico nella rete; • algoritmi inefficienti; • errori di trasmissione; • hardware non adeguato. E’ importante stabilire se un’applicazione sia in grado di interagire con l’utente in tempi accettabili nella maggior parte dei casi. In caso opposto, è utile valutare quali siano i limiti che non è consigliato oltrepassare. I test di performance, load e stress, sono legati tra loro e si distinguono più che altro per le diversa interpretazione dei risultati ottenuti: i test di performance mirano ad individuare una strategia per ottenere buone prestazioni dall’applicazione; i test di load puntano a valutare le performance con vari livelli di caricamento e utilizzo, per determinare oltre quale livello scadono sostanzialmente. Gli stress test infine hanno lo scopo di provare l’applicazione in condizioni di utilizzo estreme, quali l’utilizzo contemporaneo da parte di un elevato numero di utenti. I test sono costituiti da simulazioni di un utilizzo tipico dell’applicazione da parte di centinaia o migliaia di utenti. Essendo inpraticabile l’impiego di un tale numero di utenti umani, diventa essenziale l’uso dei tool di testing automatico, i quali provvedono ad eseguire contemporaneamente le operazioni svolte da molti utenti virtuali. Il risultato di questi test può essere positivo se le performance si mantengono accettabili rispetto ai livelli di utilizzo previsti, o negativo se invece l’applicazione (o l’ambiente nel quale si trova) è in difficoltà anche con un numero non esagerato di utilizzi concorrenti. Con i test di stress è possibile individuare quale tra le seguenti risorse hardware tende ad esaurirsi prima: • memoria; 73 • tempo di CPU; • banda passante. e dove invece si manifestano delle insufficienze software come: • fallimenti causati da interrupt hardware; • fallimenti legati alle operazioni in memoria; • deadlock; • problemi di multithreading. In tal senso diversi sono gli approcci attuati nella valutazione qualitativa e quantitativa di aspetti di prestazioni e affidabilità, dalle tecniche euristiche e metaeuristiche, ai metodi statistici, o a quelli stocastici e/o analiticosimulativi, considerando anche tecniche di soluzione approssimata. Tali approcci, anche sulla base delle recenti filosofie di software performance engineering (test driven development e model driven development) possono essere applicati sia in fase di testing/manteinance che in una fase antecedente allo sviluppo del software stesso ed il più possibile vicino alla fase progettuale. In tal modo, errori o prestazioni insoddisfacenti potrebbero essere evidenziati valutando differenti alternative con un conseguente risparmio sia in termini di tempo che di denaro. A tal fine sono necessari strumenti (analitici e/o simulativi) in grado di catturare i requisiti e le caratteristiche di un’architettura software, di riprodurne i molteplici casi d’uso e di valutarne le prestazioni e l’affidabilità. Tali strumenti dovranno inoltre avere elevate caratteristiche di scalabilità in modo tale da affrontare la crescente complessità delle architetture moderne. 74 4.4 Tool per stress test Sono diversi i tool di monitoraggio disponibili sul mercato (sia commerciali che free), ad ogni modo, seppur con caratteristiche diverse, questi tool sono in grado di verificare la disponibilità dei servizi e dei processi, realizzati dalle singole applicazioni, oltre che l’affidabilità e le prestazioni delle infrastrutture hardware e software. Le principali peculiarità di questi prodotti sono: • il monitoraggio orientato alla end-user experience, simulando la reale interazione tra utente e applicazione attraverso la creazione di Virtual Transaction che verificano il funzionamento di tutta l’architettura tecnologica che sta alla base dell’erogazione di un servizio o di una applicazione; • la possibilità di ridurre i tempi di intervento per la risoluzione dei problemi, fornendo in modo efficace e semplice indicazioni sulle anomalie e sui degradi di performance in maniera centralizzata, rilevando eventuali diminuzioni nei livelli di servizio attesi e consentendo quindi un intervento rapido e proattivo dei gruppi di esercizio per la risoluzione delle anomalie; • l’analisi storica dei dati raccolti, che agevola le attività di pianificazione degli adeguamenti infrastrutturali e anticipa (gestione proattiva) il verificarsi di anomalie dovute alla saturazione delle risorse; • la visualizzazione in real-time dello stato dell’infrastruttura tecnologica, in termini semplici ed intuitivi, tramite quadri sinottici in grado di evidenziare le problematiche di fault e performance della soluzione monitorata. 75 L’utilizzo di questi tool, permettono il monitoraraggio di tutte le attività (a livello applicativo, traffico di rete e performance del singolo sistema) coinvolte nell’erogazione del servizio di business. L’attività di monitoraggio permette a sua volta di avere una visione dinamica (dynamic view) di come viene espletato il ”servizio di business” permettendo di individuare eventuali anomalie causate da nuove funzionalità software non opportunamente testate o dovute ad errori di configurazione che potrebbero causare rallentamenti all’intero servizio web, oppure errori a livello infrastrutturale dovuti ad errate configurazioni/errori hardware di router/switch (instradamento di traffico non corretto, errori sulle interfacce di rete) oppure rallentamenti di performance sui sistemi dei Web Server, DB Server dovuti a mancanza di memoria RAM, saturazione del File System e a processi di sistema ”bloccati”. Questa attività è molto importante perché permette di capire come interagiscono le diverse componenti, applicative e di sistema, nell’erogazione del ”servizio di business”. L’attività di monitoraggio, attraverso i diversi plugin e probe, permette di: • verificare la corretta configurazione dei servizi applicativi offerti, sui diversi Server dell’infrastruttura (Web Server, Application Server e Database Server), scoperti in fase di Assessment. In fase di monitoraggio potremmo riscontrare alcune attività, più o meno lecite che sfruttino determinati servizi (ad esempio FTP, P2P, ecc), non emerse in fase di assessment; Questa attività permette di identificare eventuali servizi superflui all’erogazione del servizio di business che possono introdurre nuove vulnerabilità o comunicazioni non previste; • identificare le vulnerabilità più critiche determinate in fase di assessment. Le vulnerabilità su cui porre maggiore attenzione saranno quelle presenti sui servizi chiave (HTTP e DB) del servizio di business; 76 • verificare la corretta configurazione degli apparati di rete come router e switch. E’ possibile monitorare il traffico per determinare, ad esempio, che un Load Balancer bilanci correttamente il traffico su più Web Server e verificare che le ACL dei firewall sia configurata correttamente evidenziando la presenza di eventuali politiche aperte; • individuare eventuali comunicazioni sospette riconducibili ad una botnet. E’ possibile verificare la presenza di canali chat (attraverso il protocollo IRC), Skype (protocollo P2P) utilizzati come mezzo di comunicazione verso il botmaster. Queste comunicazioni possono essere associate ad attacchi DDoS in corso e/o all’intercetto di password e altre informazioni sensibili; • verificare il carico di CPU e l’utilizzo di RAM sui sistemi chiave dell’infrastruttura, come web server/application server e DB server e la bandwith utilizzata tra i diversi sistemi. Questi controlli permettono di individuare eventuali errori software, rallentamenti del sistema operativo, o a livello di DB, che possono rallentare lo end-user experince. Una breve lista di tool disponibili sono: • XSpotter: tool commerciale per windows; • JMeter: tool open source, scritto in java, con interfaccia grafica, il suo vantaggio è che è multipiattaforma; • Siege: tool open source, scritto in python, è da riga di comando, anche lui multipiattorma. 77 Capitolo 5 Owasp Se diamo uno sguardo al web e ricerchiamo le statistiche in merito alle vulnerabilità presenti in internet, notiamo come i criminali stiano puntando sempre più alle masse attraverso questi attacchi. Innanzitutto, i siti web sono diventati il vero tallone d’Achille per la sicurezza IT aziendale. I malintenzionati si concentrano intensamente sull’attacco delle web application, in modo tale da infettare successivamente le macchine degli utenti finali. Allo stesso tempo, molte aziende utilizzano applicazioni standard disponibili sul mercato, piene di vulnerabilità, oppure applicazioni personalizzate che possono ospitare numerose vulnerabilità ignote, impossibili da correggere con una patch. Come riportato dal rapporto X-Force [3] nel 2009, più di metà di tutte le vulnerabilità divulgate era correlata ad applicazioni web e, di queste, più del 74 percento non disponeva di patch. Pertanto, le vulnerabilità da iniezione di codice SQL automatizzate e su grande scala emerse nei primi mesi del 2008, sono proseguite senza tregua. Alcune statistiche degne di nota sostengono che: • il 97% dei siti web sono a rischio immediato di attacchi informatici a causa delle loro vulnerabilità; 78 • il 69% delle vulnerabilità sono attacchi Client-Side; • il 64% degli sviluppatori non è confidente nelle proprie abilità nello scrivere applicazioni sicure (fonte Microsoft Developer Research); • ogni 1000 linee di codice sono presenti in media 15 falle di sicurezza critiche. Nonostante tutto, la figura 5.1 evidenzia come la ripartizione delle spese aziendali non sia in linea con i rischi. Fig. 5.1: Sicurezza - Costi 5.1 Cos’è Owasp? Open Web Application Security Project (OWASP) è un’organizzazione no profit dedicata alla realizzazione e diffusione di best practice per lo sviluppo su Web, ma anche di documentazione e software di supporto a sistemisti ed architetti di rete, sviluppatori e security manager. OWASP promuove e aiuta gli utenti a costruire un Web più sicuro. L’organizzazione mette a disposizione una checklist dei vari controlli da eseguire in attività di verifica della sicurezza nelle applicazioni. 79 Promuovendo tale checklist, Owasp propone chiaramente anche una metodologia per effettuare test ripetibili. Sebbene non è compito primario di questa checklist fornire una metodologia. Chi effettua il test delle vulnerabilità applicative, troverà utile seguire le tecniche di test descritte da Owasp. E’ importante notare come i livelli dell’infrastruttura per la verifica dell’applicazione lasciano la possibilità di agire sia in modalità superficiale che approfondita. In alcuni casi, i sistemi possono essere esplorati in base ai permessi che l’utente ha ricevuto dall’amministratore del sistema dove risiede l’applicazione web. L’uso della metodologia Owasp, è diventato uno standard de facto, è quindi fortemente consigliato seguire le loro checklist, che è in continua evoluzione. Alcuni punti della checklist suggerita da Owasp sono: • Information Gathering – Search Engine Discovery/Reconnaissance; – Identify application entry points; – Testing for Web Application Fingerprint; – Application Discovery; – Analysis of Error Codes - Information Disclosure; • Configuration Management Testing – SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity) - SSL Weakness; – DB Listener Testing - DB Listener weak; – Infrastructure Configuration Management Testing - Infrastructure Configuration management weakness; 80 – Application Configuration Management Testing - Application Configuration management weakness; – Testing for File Extensions Handling - File extensions handling; – Old, backup and unreferenced files - Old, backup and unreferenced files; – Infrastructure and Application Admin Interfaces - Access to Admin interfaces; – Testing for HTTP Methods and XST - HTTP Methods enabled, XST permitted, HTTP Verb. • Authentication Testing – Credentials transport over an encrypted channel - Credentials transport over an encrypted channel; – Testing for user enumeration - User enumeration; – Testing for Guessable (Dictionary) User Account - Guessable user account; – Brute Force Testing - Credentials Brute forcing; – Testing for bypassing authentication schema - Bypassing authentication schema; – Testing for vulnerable remember password and pwd reset - Vulnerable remember password, weak pwd reset; – Testing for Logout and Browser Cache Management - - Logout function not properly implemented, browser cache weakness; – Testing for CAPTCHA - Weak Captcha implementation; – Testing Multiple Factors Authentication - Weak Multiple Factors Authentication; 81 – Testing for Race Conditions - Race Conditions vulnerability; • Session Management – Testing for Session Management Schema - Bypassing Session Management Schema, Weak Session Token; – Testing for Cookies attributes - Cookies are set not HTTP Only, Secure, and no time validity; – Testing for Session Fixation - Session Fixation; – Testing for Exposed Session Variables - Exposed sensitive session variables; – Testing for CSRF - CSRF; • Authorization Testing – Testing for Path Traversal - Path Traversal; – Testing for bypassing authorization schema - Bypassing authorization schema; – Testing for Privilege Escalation - Privilege Escalation; • Business logic testing – Testing for Business Logic - Bypassable business logic; • Data Validation Testing – Testing for Reflected Cross Site Scripting - Reflected XSS; – Testing for Stored Cross Site Scripting - Stored XSS; – Testing for DOM based Cross Site Scripting - DOM XSS; – Testing for Cross Site Flashing - Cross Site Flashing; 82 – SQL Injection; – LDAP Injection; – ORM Injection; – XML Injection; – SSI Injection; – XPath Injection; – IMAP/SMTP Injection; – Code Injection; – OS Commanding; – Buffer overflow; – Incubated vulnerability; – HTTP Splitting, Smuggling; • Denial of Service Testing – Testing for SQL Wildcard Attacks; – Locking Customer Accounts; – Testing for DoS Buffer Overflows; – User Specified Object Allocation; – User Input as a Loop Counter; – Writing User Provided Data to Disk; – Failure to Release Resources; – Storing too Much Data in Session; • Web Services Testing 83 – Web Server Information Gathering; – Testing WSDL; – XML Structural Testing ; – XML content-level Testing; – HTTP GET parameters/REST Testing; – Naughty SOAP attachments; – Replay Testing - WS Replay Testing; • Ajax Testing; – AJAX Vulnerabilities; – AJAX Testing - AJAX weakness; La figura 5.2 mostra la proposta di Owasp, affinchè sia possibile avere un modello tale che i test siano ripetibili. 84 Fig. 5.2: Modello di Metodologia di Test la figura 5.2 vuole evidenziare le segenti cose: 1. La ricerca delle vulnerabilità inizia solo dopo avere a disposizione tutte le informazioni per analizzare il sistema. Questa fase è fondamentale; senza informazioni le attività successive non possono essere svolte; 85 2. Il test deve seguire tutti i passi indicati in Figura 5.2; 3. I tester dovrebbero tentare di sfruttare tutte le vulnerabilità conosciute. Anche se il test non avrà il successo sperato, si acquisirà una maggiore comprensione della materia. Ogni informazione rilevata dal test di vulnerabilità (ad esempio, errori di programmazione, recupero di codice sorgente, e altre informazioni riservate) dovrebbe essere utilizzata per comprendere e migliorare la sicurezza in ambito applicativo. 5.2 TOP 10 Uno dei tanti progetti di Owasp ha come scopo è quello di aumentare la sensibilità sulla sicurezza applicativa attraverso l’identificazione dei principali rischi ai quali sono esposte le organizzazioni IT. Il progetto Top 10, è una lista, stilata ogni anno, che prende in considerazione i 10 maggiori rischi, questo non significa che siano le 10 vulnerabilità più diffuse. Questa lista è presa come riferimento da numerosi standard, libri, tool e organizzazioni come MITRE, PCI DSS, DISA, FTC, e molte altre. OWASP incoraggia l’uso della Top 10 affinché la vostra organizzazione inizi a prendere in considerazione la sicurezza applicativa. Gli sviluppatori possono apprendere dagli errori commessi dalle altre organizzazioni. Questa è la TOP 10 dell’aano 2010: 1. Injection; 2. Cross-Site Scripting (XSS); 3. Broken Authentication and Session Management; 4. Insecure Direct Object References; 86 5. Cross-Site Request Forgery (CSRF); 6. Security Misconfiguration; 7. Insecure Cryptographic Storage; 8. Failure to Restrict URL Access; 9. Insufficient Transport Layer Protection; 10. Unvalidated Redirects and Forwards. Nel capitolo 6 verrano descritte in dettaglio alcune di queste vulnerabilità, come possono essere sfruttate e il loro rimedio. Ad ogni modo, come riportato nalle parte 8.3 di questo lavoro, è interessante sottolineare, come un ipotetico attaccante abbia diverse strade per raggiungere i suoi fini, usando le diverse vulnerabilità presenti nell’applicazione. In alcuni casi, questi percorsi sono individuabili e sfruttabili molto facilmente e in altri casi, possono essere, molto complessi. Allo stesso modo il danno che può essere causato può essere da nullo fino a distruttivo per il proprio business. Fig. 5.3: Finestra temporale di una vulnerabilità 87 5.3 I tool di OWASP Owasp, oltre a stilare la lista delle TOP 10, suggerisce anche i tool per un remediating di ciascuna vulnerabilità presente nella TOP 10. Nella fattispecie: Vulnerability tool Injection ZAP Cross-Site Scripting (XSS) BeEF Broken Authentication and Session Management; HackBar Insecure Direct Object References Burp Suite Cross-Site Request Forgery (CSRF) Tamper Data Security Misconfiguration Watobo Insecure Cryptographic Storage N/A Failure to Restrict URL Access Nikto/Wikto Insufficient Transport Layer Protection Calomel Unvalidated Redirects and Forwards Watcher Tabella 5.1: Security web tool Alcuni di questi tool sono implementati direttamente da loro, e sono molto validi e saranno visti nei capitoli succesivi. 88 Capitolo 6 Vulnerabilità applicative Nel capitolo 3 è stato mostrato come rilevare le vulnerabilità infrastrutturali, purtroppo questa tipologia non è l’unica esistente, in questo capitolo si discuteranno le vulnerabilità a livello applicativo e come esse possono esere facilmente sfruttate da malintenzionati. 6.1 Vulnerabilità applicative Considerata l’alta accessibilità al web e la sua praticità, in questi anni c’è stata una vera proliferazione di applicazioni web. E’ evidente che rispetto alle applicazioni tradizionali, che richiedono l’installazione su tutti i client, il web permette di accentrare in un unico server web l’applicazione, eliminando una serie di problemi legati alle diverse configurazioni dei client (sistemi operativi differenti, diverse patch installate, etc). Tuttavia esiste il rovescio della medaglia: nascono infatti nuove problematiche, ad esempio chiunque può accedere all’applicazione anche a fini non proprio onesti, i firewall tradizionali possono fare ben poco e banalmente la porta 80 è aperta o chiusa. Come ho scritto sopra, molti problemi sono legati ad una cattiva programmazio- 89 ne: spesso non viene validato l’input, permettendo cosı̀ a malintenzionati di inoltrare dati volutamente dannosi, sfruttando i form, o i parametri di una determinata pagina; l’attacante potrà in questo modo accedere ai dati di un database, o ottenere i privilegi di un utente. 6.1.1 SQL injection Praticamente tutti i siti fanno uso di un database, dove vengono raccolte le informazioni (dall’anagrafica, ai servizi offerti). Spesso questi dati possono anche essere sensibili, come carte di credito o credenziali d’accesso, e questo li rende molto appetibili agli attacanti. Per SQL injection si intende come la manipolazione della stringa SQL, rendendola legittima dal punto di vista del linguaggio, ma permettendo di bypassare determinare controlli. s q l = SELECT ∗ FROM u t e n t i WHERE u s r = ’ ’ + username + ’ ’ AND pwd = ’ ’ + password + ’ ’ ; Un codice siffato sarebbe vulnerabile ad attacchi di sql injection in quanto basterebbe mettere nel campo password la dicitura ’ OR 1 = 1 – e la query risultante sarebbe: SELECT ∗ FROM U t e n t i where u s r = ’ ’ u t e n t e r e a l e ’ ’ AND pwd= ’ ’ OR 1 = 1 −− In questo modo verrà bypassato il controllo sulla password, ovviamente sarebbe stato possibile inserire anche ”; drop database”, con esito ben più preoccupante... La figura 6.1 mostra come poter accorgersi di tale vulnerabilità con il tool Zap messo a disposizione da OWASP. 90 Fig. 6.1: Owasp Zap Blind Sql Injection Un’importante variante di SQL injection è il blind, ossia quella tecnica atta a ricevere maggiori informazioni possibili sulla struttura di un database come nomi delle tabelle o dei campi. Uno dei modi per ottenere queste informazioni è quello di sfruttare i messaggi di errore che restituisce il DBMS a seguito di query errate. E’ fondamentale in fase di sviluppo avere gli errori del DBMS: questo ci permette infatti di arrivare alla risoluzione dell’errore. Tuttavia, in fase di rilascio queste informazioni sono rimosse, impedendo cosı̀ a un ipotetico attaccante di carpire le informazioni sul database. Di seguito riportiamo un esempio di Blind Sql Injection. Supponiamo di avere il seguente URL: h t t p : / / m i o s i t o . com/ miapagina . php? i d=3 e di modificare la request in questo modo: h t t p : / / m i o s i t o . com/ miapagina . php? i d=3 and 1=1 h t t p : / / m i o s i t o . com/ miapagina . php? i d=3 and 1=2 91 Supponiamo che la pagina sia vunerabile alla SQL injection. Nei nostri due casi sarebbero eseguite le seguenti query: SELECT campo1 , campo2 , FROM i t e m s where ID=3 AND 1=1 SELECT campo1 , campo2 , FROM i t e m s where ID=3 AND 1=2 Evidentemente la prima darà lo stesso risultato della query originale, la seconda invece non darà alcun risultato. Dunque se il primo URL darà come risultato la pagina originale, mentre il secondo no, allora il malfattore potrà derivarne che l’espressione AND verrà eseguita in una query, e che quindi la pagina contiene una vulnerabilità di SQL injection. Questo è solo un esempio delle informazioni che un attacante cerca, ma altre informazioni potrebbero essere preziose come: • fingerprinting DBMS: consiste nell’inserimento di una stringa sql funzioni strettamente legate ad un particolare DBMS con lo scopo di individuarne appunto il tipo. Alcuni esempi sono funzione dell’ora, che in MySQL, MS SQL e Oracle sono rispettivamente now(), getdate() e sysdate()); • timing attack: consiste nell’inserire all’interno di una query, un’espressione che, al verificarsi di una determinata condizione, esegue un comando particolarmente time-consuming; il malfattore potrà capire se la condizione si è verificata o meno dal tempo che impiega il web server a rispondere. 92 Un esempio interessante è il seguente: SELECT IF (SUBSTRING( password , 1 , 1 ) = CHAR 9 3 ) , ( BENCHMARK( 5000000 , ENCODE( ’MSG ’ , ’ by 5 s e c o n d s ’ ) ) , n u l l ) FROM u s e r s WHERE u s e r i d = 1 ; che esegue l’istruzione: BENCHMARK( 5000000 , ENCODE( ’MSG ’ , ’ by 5 s e c o n d s ’ ) ) , se verificata la condizione: SUBSTRING( password , 1 , 1 ) = CHAR 93 ) ovvero se il primo carattere del campo password dell’utente con user id=1 è la lettera ”a”. Ripetendo questa procedura l’intruso può arrivare a conoscere l’intera password di qualsiasi utente. 93 6.1.2 Cross-site scripting Questo tipo di attacco non è complesso e quindi richiede molta attenzione. Contrariamente al solito, questo attacco non è diretto al server web, ma verso l’utente; certo che, se l’utente fosse un amministratore, allora lo scenario sarebbe molto interessante. Come competenze tecniche richiede una minima conoscenza del linguaggio JavaScript e un sito web che registri gli input dell’utente per stamparli successivamente a video, senza applicare un filtro: ad esempio forum, blog, il form di commento ad un articolo. Un classico esempio è il forum. Generalmente un utente si logga per entrare nel sito, successivamente entra in una discussione e inserisce il seguente messaggio: Ciao r a g a z z i ! ! < s c r i p t l a n g u a g e =”j a v a s c r i p t ” type =”t e x t / j a v a s c r i p t ”> a l e r t ( ’ I l s e g u e n t e forum è s t a t o s p o s t a t o , v e n i t e a t r o v a r c i s u l nuovo URL’ ) ; document . l o c a t i o n = r e l o a d ( ’ h t t p : / /www. i l m i o s i t o f a r l o c c o . com ’ ) ; </ s c r i p t > Quando gli utenti vanno a leggere il messaggio appena inserito, verranno reindirizzati verso ilmiositofarlocco.com, non appena avranno premuto il pulsante ”ok” del pop-up informativo. Ora cosa faccia il sito nessuno (attacante escluso) lo può immaginare. Un ipotetico scenario sarebbe quello di inserire delle funzioni per il logging degli indirizzi ip. 94 Quanto fatto in questo esempio è fin troppo ”buonista”, basterebbe infatti una semplice aggiunta come Ciao r a g a z z i ! ! < s c r i p t l a n g u a g e =”j a v a s c r i p t ” type =”t e x t / j a v a s c r i p t ”> a l e r t ( ’ I l s e g u e n t e forum è s t a t o s p o s t a t o , v e n i t e a t r o v a r c i s u l nuovo URL’ ) ; document . l o c a t i o n = r e l o a d ( ’ h t t p : / /www. i l m i o s i t o f a r l o c c o . com/ i n d e x . php ’ + document . c o o k i e ) ; </ s c r i p t > per ottenere una password che ci consenta di fare scalata di privilegi sul sito attaccato o di ottenere l’identificativo di sessione, che sarebbe equivalente a rubare la login del malcapitato. 6.1.3 Le Cross-Site Request Forgeries Le Cross-Site Request Forgeries (CSRF) è l’opposto del cross-site scripting; si tratta di una vulnerabilità che sfrutta un ignaro utente per attaccare a sua insaputa un’altra applicazione sfruttandone i diritti dell’utente attaccato. L’attacco avviene nel momento in cui un utente che possiede diritti su un server A (server attaccato) visita una pagina su un server B (di proprietà dell’attaccante e dove egli può introdurre una CSRF liberamente. La pagina costruita dall’attaccante contiene solitamente dei tag che permettono di eseguire operazioni GET al browser come src in img, iframe etc. Senza che l’utente se ne accorga possono essere eseguite operazioni su un altro server (o anche sul server stesso). 95 L’utente non si accorgerà di nulla, se non di non riuscire a visualizzare alcune immagini. L’attacco può essere eseguito anche inviando mail in formato HTML (come per il cross-site scripting), permettendo di attaccare specifici utenti che si trovano dietro un firewall. 96 <img s r c =”h t t p s : / / example1 . com/ x f e r ? from=MSFT&t o=RHAT”> <img s r c =”h t t p s : / / example2 . com/ c l i c k b u y ? book=ISBN&qty =100”> Sono particolarmente vulnerabili ai CSRF le applicazioni web che eseguono operazioni ”importanti” attraverso semplici richieste GET utilizzano sistemi di auto-login (...utenti che non eseguono il log-out). 6.1.4 Buffer Overflow Il buffer overflow è un vulnerabilità di sicurezza che può essere presente all’interno di un qualsiasi programma software. Esso consiste nel fatto che il programma in questione non controlla anticipatamente la lunghezza dei dati in input, ma si limita a trascrivere il loro valore all’interno di un buffer di lunghezza prestabilita, non pensando che il mittente (utente o altro software) possa inserire più dati di quanti esso ne possa contenere: ad esempio, potrebbe accadere che il programma è stato scritto usando funzioni di libreria di input/output che non fanno controlli sulle dimensioni dei dati trasferiti ad esempio la funzione strcpy() del linguaggio C. Questo fatto potrebbe provocare un blocco dell’applicazione che può sfociare nell’esecuzione del codice arbitrario e dare in questo modo un accesso al sistema. Il codice seguente mostra un esempio di buffer overflow, l’uso della funzione gets(), è considerata a tutti gli effetti come una funzione pericolosa presente nella libreria standard del linguaggio C. Tale funzione difatti legge dallo standard input la stringa che dopo verrà messa nel buffer specificato con l’unica accortezza di sostituire il carattere line-feed (l’invio a capo che abbiamo digitato per terminare l’immissione dati) con un byte NULL. La particolarità e la pericolosità della funzione sta nel fatto che non controlla se la stringa 97 che ha immesso l’utente è più grande del buffer di destinazione. E’ evidente che i buffer overflow creano cosı̀ tanti problemi: infatti possono essere sfruttati per eseguire codice arbitrario sulla macchina che esegue il programma vulnerabile. #i n c l u d e <s t d i o . h> void l e g g i s t r i n g a ( void ) ; int main ( void ) { leggistringa (); return ( 0 ) ; } void l e g g i s t r i n g a ( void ) { long num = 0 ; char buff [ 8 ] ; gets ( buff ) ; } E’ ovviamente possibile proteggersi da questo tipologia di attacco in diversi modi, ad esempio sarebbe preferibile utilizzare dei linguaggi di programmazione evoluti, i quali si occupano loro della memoria destinata oppure, qualora la scelta ricadesse su linguaggi di basso livello facendo, sarebbe opportuno usare librerie che contengono funzioni“sicure”(ad esempio le funzioni strncpy() del linguaggio C). 98 Capitolo 7 Assessment applicativo Per le motivazioni sopra citate, la verifica delle debolezze applicative, attraverso attività di Application Vulnerability Assessment e/o Code Analysis, dovrebbe essere eseguita periodicamente. In una condizione ideale, dovrebbe essere eseguita sistematicamente all’interno delle varie fasi del SDLC (Software Development Life Cycle) e comunque prima di ogni rilascio di modifiche in produzione: questo perché la tecnologia progredisce velocemente e con essa anche le tecniche per attaccare un sistema, che sono basate su nuove vulnerabilità scoperte. Il Ciclo di Vita del Software, comprende i seguenti step: • Define; • Design; • Develop; • Deploy; • Maintain. I processi da implementare nella SLDC sono i seguenti: 99 • Awareness; • Secure Code Guidelines; • Code Review; • Application Testing. Come mostrato in figura 7.1 OWASP suggerisce l’uso di alcuni tool da usare nei vari processi Fig. 7.1: SDLC OWASP Guidelines e tools L’analisi puntuale e dettagliata delle applicazioni web che costituiscono il ”servizio di business” deve anche consentire di rilevare come eventuali criticità legate allo strato applicativo possano essere sfruttate per arrecare danno all’infrastruttura ospitante, e/o consentire l’accesso a reti/sottoreti in cui possano trovarsi dati critici. 100 7.1 Analisi della web application Al fine di verificare eventuali criticità rilevanti che può avere il ”servizio di busines”, è indispensabile analizzare l’applicazione web dal punto di vista dell’utente finale. La Figura 7.2 mostra com’è strutturata un’applicazione web evidenziando i flussi di input/output che attraversano ogni livello della stessa. L’analisi deve essere svolta su ciascuno dei livelli indicati; la presenza di vulnerabilità anche solo su uno di essi potrebbe propagare effetti negativi sugli altri. Fig. 7.2: Struttura Web Application La Figura 7.3, mostra tutti i possibili test che possono essere eseguiti per effettuare un’analisi precisa di una web application e determinare tutte 101 le possibili vulnerabilità. In genere sulle applicazioni web possono essere eseguiti due tipi di test di sicurezza: analisi dinamica (black box analysis) e analisi statica (white box analysis). Fig. 7.3: Tipologie di security test Queste attività possono essere svolte con diversi tool presenti sul mercato, sia open source che commerciali, come abbiamo visto dalla figura 7.1 OWASP suggerisce i suoi, ma tuttavia ce ne sono anche altri. La tabella 7.1 ne evidenzia alcuni. Tool Tipologia IBM AppScan commerciale Web Inspect commerciale Orizon free Lapse free Tabella 7.1: tool per analisi statica 102 7.2 Analisi dinamica (black box analysis) L’analisi dinamica, comporta la ricerca di vulnerabilità, senza conoscere il codice. Questo viene fatta lanciando una istanza dell’applicazione e studiando il suo comportamento dinamicamente. Nel caso di applicazioni web, il test prevede che siano inviate alcune richieste (HTTP request) all’applicazione e che siano osservate le risposte (HTTP response) per verificare se esiste una qualsiasi indicazione che possa essere riconducibile alla presenza di una vulnerabilità. L’analisi dinamica è un metodo efficace per testare le applicazioni, ma è importante sapere che esistono alcune limitazioni. 1. Poiché il test è basato sull’analisi di modelli di domanda e risposta, i risultati ottenuti sono soltanto un’ipotesi sulla situazione interna dell’applicazione (in genere, il tester non è a conoscenza del codice sorgente che sta alla base dell’applicazione e di quello che effettivamente è l’attuale stato interno dell’applicazione stessa); 2. Il tester sta solo valutando il comportamento osservabile dell’applicazione e non può conoscere ciò che accade sull’intera superficie di attacco, esiste la possibilità che certe aree dell’applicazione e certe componenti delle sue funzionalità siano escluse dalla prova; 3. Per altro anche determinate risposte, ovviamente, non potrebbero indicare se è presente una vulnerabilità di sicurezza; 4. Questi fattori portano alla possibilità di individuare ”falsi negativi”, ossia situazioni in cui vi è una vulnerabilità di sicurezza che passa inosservata e non è dichiarata. L’esecuzione di questi test può essere fatta attraverso dei tool automatici, sia semiautomatici. Questi tool consentono di individuare molte delle più diffuse 103 vulnerabilità, come l’SQL injection e il cross-site scripting (XSS), e spesso sono anche usati per cercare noti problemi di sicurezza. Naturalmente anche l’analisi dinamica delle applicazioni web, può essere affrontata con diversi tool. In questo contesto, prendiamo come esempio due tool: 1. AppScan: metodologia completamente automatica; 2. Zap: metodologia semiautomatica. 7.2.1 IBM AppScan L’analisi black box con questo tool, può essere completamente automatica, gli viene dato come input l’indirizzo web ed esso, attraverso delle chiamate, come un link presente in una determinata pagina, inizia a registrare le request e le response, in altre parole, esso naviga sull’applicazione e costruisce il ”site model” individuando i tipi di attacchi a cui l’applicazione è esposta in base a ”test policy” selezionate. Fig. 7.4: Esplorazione e analisi di una web application 7.2.2 ZAP Questo tool, altro non è che un proxy, il browser web deve essere configurato in modo tale da passare dal proxy, ed esso registra tutte le response e le request che manualmente vengono fatte dal browser. 104 Fig. 7.5: Proxy naturalmente, il proxy potrebbe anche collassare sulla macchina host, l’importante è configurare opportumante il browser. La figura 7.6 mostra come viene registrata la chiamata e la response, e successivamente è possibile tentare degli attacchi, modificando la request. Fig. 7.6: Zap 7.2.3 Considerazioni La differenza sostanziale tra le due metodologie, è che la prima è sicuramente più veloce, tuttavia è probabile che una serie di request non vengono fatte. 105 Pensiamo ad esempio ad una applicazione dove è richiesto di riempire un campo e a seguito della pressione di un pulsante, viene fatta la request, nella modalità automatica non è banale impostare un input nel campo. Inoltre ci si scontra con librerie grafiche usate dal programmatore, non riconosciute dal tool. In maniera opposta, un tool semiautomatico come Zap, non ha problemi di librerie grafiche usate dal programmatore, ma è richiesta una persona che sappia usare molto bene l’applicativo, in tutte le sue funzioni (oltre che al security man, che difficilmente conosce l’applicativo), inoltre sicuramente questa metodologia richiede un tempo maggiore rispetto la prima. 7.3 Analisi statica (white box analysis) A seguito dell’attività di analisi dinamica dell’applicazione web vista nel paragrafo 7.2, e in base ai risultati ottenuti, si valuterà se effettuare una revisione totale o parziale del codice con lo scopo di approfondire l’analisi delle principali vulnerabilità riscontrate o di potenziali vulnerabilità che possono essere presenti nel codice. L’analisi statica, nota anche come white box analysis o code review, prevede il riesame degli asset di tale applicazione, come il codice sorgente, i file di configurazione e cosı̀ via. Perché l’analisi venga effettuata bisogna accedere al codice sorgente (source code). In questo caso non si dovrà osservare il comportamento di un’applicazione, ma l’accesso alle effettive istruzioni che il software eseguirà quando sarà messo in produzione. Questo può aiutare a limitare i ”falsi positivi” e i ”falsi negativi”. Uno svantaggio inerente l’analisi statica è che può fallire nell’individuazione dei problemi di sicurezza legati in modo specifico alla configurazione del sistema implementato: per esempio, l’analisi statica non è in grado di individuare i problemi che potrebbero sorgere a causa della dimenticanza da parte degli amministratori 106 di installare le patch nel Web Server o nel sistema operativo. L’analisi statica permette di analizzare quando le istruzioni di una web application del ”servizio di business” sono state coperte eseguendo dei controlli run-time in fase di esecuzione. Questo tipo di analisi fornisce ulteriori informazioni sulle possibili criticità presenti nel ”servizio di business” sotto esame e permette di notificare al development dell’azienda che eroga il servizio di business i punti di attenzione dove porre rimedio attraverso funzioni di patching software. 7.4 Extranet services Il ”servizio di business” in esame potrebbe appoggiarsi, oltre che sull’applicativo del cliente, su altre applicazioni (web o meno) erogate e gestite da business partner, che comunicano tra loro attraverso Web Service (ad esempio, nel caso di acquisto online di biglietti per il cinema, il teatro ecc., nel momento in cui si effettua un pagamento con carta di credito, si viene dirottati sul sito di Banca Sella; altro esempio, in ambito assicurativo può capitare che l’applicazione ”core” della compagnia debba colloquiare, sempre attraverso extranet, con servizi esposti da ANIA, Associazione Nazionale fra le Imprese Assicuratrici). In questo caso, il Vulnerability Assessment del ”servizio di business” non si estende ai servizi erogati dal business partner, a meno di averne espressa autorizzazione, ma si limiterà alla rilevazione delle vulnerabilità associate alla componente di sistema del nostro cliente che si interfaccia con le applicazioni esterne del business partner che vengono invocate, ossia web service. In particolare si effettuerà la validazione dei dati ricevuti in input dai partner che erogano i servizi web. 107 7.5 Considerazioni I vantaggi di fare la doppia scansione (white e black box) sono diversi, a seguito di alcuni esperimenti è stato constatato che: 1. eliminazione dei falsi positivi: I falsi positivi rilevati nella fase di code review. Infatti, durante un esperimento, la scansione white box aveva rilevato diverse vulnerabilità di tipo Sql Injection; a seguito di un’analisi approfondita fatta insieme al programmatore, il quale aveva confermato che erano falsi positivi, è stata lanciata una scansione black box, ed effettivamente abbiamo notato che nessun attacco di tipo Sql Injection era andato a buon fine; 2. Maggior visibilità: Le due analisi, come mostrato in figura 7.7, sono in parte sovrapposte e in parte complementari, questo ci permette di dire che dati due insiemi di vulneravilità B e W, dove B è l’insieme delle vulnerabilità di tipo black box e W è l’insieme delle vulenerabilità di tipo white box, e conoscendo [B] , e [W ]; e conoscendo y vulnerabilità con y <= min{ [B] , [W ]} trovate in entrambe le scansioni, con la doppia scansione siamo in grado di trovare le vulnerabilità totali [B] ∪ [W ] − [B] ∩ [W ] (ovviamente saranno da scorporare i falsi positivi) Fig. 7.7: Distribuzione delle vulnerabilità in modalità statica e dinamica questo ci permette di allargare la visibilità delle vulnerabilità, infatti, l’analisi statica non è in grado di individuare i problemi che potrebbero sorgere a 108 causa della dimenticanza da parte degli amministratori di installare le patch nel Web Server o nel sistema operativo. Dall’altra parte, l’analisi dinamica, valuta il comportamento osservabile dall’applicazione e non può conoscere ciò che accade sull’intera superficie di attacco, esiste la possibilità che certe aree dell’applicazione e certe componenti delle sue funzionalità siano escluse dalla prova. La tabella sottostante riassume cosa è possibile trovare dalle singole analisi White Box (W) Black Box (B) W∩B null pointer dereferen- problemi di configura- SQL injection ce zione problemi di qualità del problemi di patch level cross site scripting codice problemi di dead code problemi di privilegi HTTP response splitting crypto functions non problemi di autentica- OS commanding sicure zione problemi in external LDAP injection 3rd party components Se analizziamo la tabella emerge che: • dalla colonna che rappresenta l’insieme W difficilmente avremo falsi positivi; • dalla colonna che rappresenta l’insieme B difficilmente avremo falsi positivi; 109 • i falsi positivi possono essere nell’intersezione, però, se entrambe le scansioni rilevano la vulnerabilità, allora la vulnerabilità esiste, se è rilevata solo dalla black box allora è probabile che esiste (c’è stata una simulazione d’attacco), se è riscontrata solo dalla white box allora potrebbe essere un falso positivo, in quanto l’analisi dinamica non è stata in grado di sfruttare tale vulnerabilità (oppure tale attacco non è contemplato, ma è improbabile visto che i 2 tool sono della stessa casa produttrice). Analizzando l’intersezione (e solo l’intersezione) posso sostenere quindi, con una certa probabilità di poter avere la seguente tabella di verità. Static Dinamic Result 0 0 0 0 1 1 1 0 0 1 1 1 Tabella 7.2: Caso specifico dell’intersezione Da un punto di vista insiemistico possiamo sostenere che: P D = (D ∧ ¬S) ∨ (D ∧ S) analogamente P C = (D ∨ S) ∧ (D ∨ ¬S) 7.6 Ciclo di vita del software Il ciclo di vita di un software o Sofware Development Life Cycle (SDLC) si suddivide in 6 punti chiavi: 110 1. define; 2. design; 3. develop; 4. develop; 5. deploy; 6. maintain. Inoltre, come abbiamo visto, le vulnerabilità vengono rilevate tramite: • Manual Inspections & Reviews; • Threat Modeling; • code review; • VA - penetration testing. Ad ogni modo bisogna tener conto che: • se un PT da esito positivo allora l’azienda sa che ci sono dei seri problemi; • se un PT da esito negativo allora l’azienda ha un falso senso di sicurezza; Inoltre i WAF non coprono tutte le vulnerabilità e per niente quelle logiche! Implica un drammatico innalzamento dei costi , inoltre normalmente implica solo black-box testing! Al fine di costruire software migliore, è necessario costruire un migliore processo di sviluppo del software (SDLC) Alcuni principi di testing sono i seguenti: 111 • non esiste la soluzione; • la chiave è il SDLC; • testare nella fase iniziale e spesso; • Mindset: pensare out of the box; • Use the Right Tool for the Right Job; • usare source code review quando è disponibile; • metriche e miglioramento continuo; Owasp, come riportato in figura 7.8, propone una guida sull’unione di SDLC e security, elencando come procedere ad ogni step del SLDC Fig. 7.8: SLDC Prima che inizi lo sviluppo dell’applicativo è necessario: • assicurarsi che esista un SDLC adeguato e che la sicurezza sia inerente in ogni fase; 112 • creare le policy e standard necessarie per il team di sviluppo; • sviluppare criteri di metrica per assicurare il miglioramento continuo del ciclo; • documentare tutto per assicurare la tracciabilità. Durante il define e design e necessario: • security requirements review: – User Management (password reset etc.), Authentication, Authorization, Data Confidentiality, Integrity, Accountability, Session Management,Transport Security, Privacy; • design and architecture review; • create and review UML models; – come funziona l’applicativo; • create and review threat models; – sviluppare uno scenario di minacce realistiche; durante la fase di sciluppo, è necessario: • code walkthrough: – ispezione ad alto livello del codice in cui gli sviluppatori posso spiegare la logica ed il flusso; • Code Review: – Revisione statica del codice al fine di validare il codice nei confronti di una serie di checklist: 113 ∗ CIA triade; ∗ OWASP Top10, OWASP Code Review; ∗ Sox, ISO 17799; • application penetration testing; – test black-box dell’applicazione; • configuration management testing: – controllo di come l’infrastruttura è stata messa in campo e come resa sicura. Infine, durante la fase di manutenzione: • operational management reviews; • health check periodici; • assicurare il change verification. 114 Capitolo 8 Passive vulnerability scanner Nella nella seconda parte di questo lavoro, abbiamo visto come è possibile, tramite un vulnerability scanner, trovare le vulnerabilità presenti e i vari servizi attivi su un determinato asset. Avevamo anche sottolinato il fatto che i VA soffrono del problema della degradazione, ma anche il fatto che il VA prende in considerazione solo l’utente loggato in quel momento. Abbiamo anche visto, che le vulnerabilità potrebbero essere presenti in una macchina virtuale, non presa in considerazione, e successivamente tale macchina viene messa in rete. In questa parte, vedremo come trovare le vulnerabilità analizzando il traffico passante in una rete, in questo modo, monitorando nel tempo tale traffico, potremmo risolvere, almeno in parte, il problema della degradazione. E’ evidente che, l’analisi del traffico di rete, occupa una arco temporale maggiore rispetto all’attività di vulnerability assessment. Per questo motivo, è preferibile eseguire prima il VA tradizionale, anche per poter avere una fotografia della situazione in tempi rapidi e per poter effettuare un primo piano di remediation plan, magari installando le patch mancanti. Successivamente, con l’ausilio di un sistema di IDS è possibile analizzare il traffico passante 115 e valutare se altre vulnerabilità vengono trovate, o se ci sono violazione di policy. 8.1 Cos’è un passive vulnerability scanner Attraverso un sostema di Passive Vulnerability scanner (PVS), è possibile monitorare il traffico di rete, ed in base alla sessione passante, costruirsi un modello delle varie attività dei vari host e dei loro servizi. Il traffico passante tra ciascun host o server, verrà analizzato per scoprire host al momento sconosciuti (come le macchine virtuali), nuove applicazioni e le relative vulnerabilità in real-time. Per fare questo, il sistema di IDS scelto deve essere connesso ad un segmento della rete tramite tramite hub, spanned port, virtual spanned port network o tap e monitorerà continuamente i dati che passano, in modalità passiva. In questo modo, l’IDS osserva quali sistemi sono attivi, con quali protocolli comunicano, e con chi comunicano, quale applicazione eseguono e quale vulnerabilità sono presenti. Queste informazioni vengono poi confrontate con le policy aziendali e l’IT valuterà di conseguenza se bloccare o meno una determinato tipologia di traffico. Poniamo l’esempio che l’IDS veda un pacchetto TCP, con porta 25 e FLAG SA da un host monitorato, questo comporterà che potremmo rivalutare il modello. Sarà quindi possibile memorizzare che un determinato server ha la porta 25 aperta come nuova informazione, e su questa informazione verrà aggiornato il modello. In questo modo è possibile monitorare il traffico in maniera passiva, scoprendo nuove informazioni in merito alla topologia, e alle relazioni tra varie macchine, valutando se sono da considerare trust o meno. Analizzando i vari pacchetti con flag S è possibile determinare il 116 sistema operativo, questo è dovuto al fatto che i vari OS presenti, gestisono in maniera differente la creazione dei pacchetti. I dati verranno successivamente analizzati da un apposito client, e verrà ricostruita ciascuna parte di comunicazione di rete. I vari protocolli come HTTP, SMTP e FTP hanno stringhe specifiche che identificano la versione del servizio. In questo modo PVS identificherà ciascuna associazione tra la versione del protocollo usata e le specifiche vulnerabilità presenti. Per altri protocolli DNS, windows file sharing e SNMP richiedono molti step per determinare la versione del protocollo usato. Si potrebbe anche usare diversi pattern matching e tecniche di analisi di protocollo per l’identificazione. Con la creazione di un database ricco di informazioni, sarebbe possibile scoprire le applicazioni che sono installate sull’host e le relative vulnerabilità. Lo stesso database potrebbe anche contenere un indice dei diversi exploits publici usabili per le vulnerabilità trovate, questo semplificherebbe di molto, in caso di attività come il penetration test. 8.2 Vantaggi di un passive scanning Sono diversi i vantaggi di un VA fatto anche tramite l’uso dell’IDS, innanzi tutto è possibile trovare vulnerabilità 24x7, quindi un ipotetico client spento in determinato momento, prima o poi verrà analizzato, stessa cosa con il client appena installato. Inoltre, non ha impatti nella rete aziendale, in quanto non genera nuovo traffico come la scansione, ma è semplicemente in ascolto. Un ulteriore vantaggio, è portato dal fatto che può trovare vulnerabilità a livello applicativo, infatti ha le seguenti possibilità: • verifica il client in uso per la mail, come Outlook, Thunderbird, Mail.app; • il web browser usato come internet Explorer, firefox e opera; 117 • programmi di chat come trillian o skype; • Media streaming usato come iTunes, RealPlayer, e Apple QuickTime. Nella figura 8.1, si vede che il campo User-Agent del protocollo HTTP, mostra la versione del browser utilizzato, nell’esempio Firefox 10.0.2. Fig. 8.1: cattura del traffico Firefox Avendo questa informazione, e avendo il database, aggiornato delle varie vulnerabilità, si può vedere quali vulnerabilità sono presenti in questa versione del browser. Analizzando il traffico di rete, è inoltre possibile monitorare la tipologia del traffico come ad esempio: • Facebook: Tutti i login di facebook verrebbero intercettati e analizzati, e l’userID potrebbe essere identificato; • FTP: è possibile vedere chi fa delle get o post; • IM: Tutti gli instant messaging vengono loggati e identificati gli userID; 118 • SMB: tutti i file scaricati via dominio p cartelle condivise vengono loggati; • SQL: Le stringhe SQL (dei prindipali DB) sarebbero salvate nei log; • SMTP: tutte le email verrebbero siffate e catalogate; e valutare se tale traffico è permesso dalle policy aziendali. Il continuo uso di un sistema di IDS, riduce la necessità di attività di scansioni automatiche, riducendo notevolmente il traffico di rete. 8.3 PVS & vulnerability scanner Nel paragrafo precedente, abbiamo visto i vantaggi di PVS, tuttavia questa metodologia risulta essere complementare al vulnerability scanner. Non è possibile prescindere da una di queste due motodologie. Come abbiamo visto nel capitolo 3, Nessus rileva le vulnerabiità presenti, dovute a patch mancanti del sistema operativo, non sarebbe possibile con PVS avere la stessa informazione. Infatti dai pacchetti di rete, potremmo capire il sistema operativo presente sulla macchina, ma non il livello di patching installato. Analogamente, come già discusso, Nessus non rileva vulnerabilità dovute ad un applicativo, come il client di una chat. Questo porta a sostenere che facendo entrambe le attività, si può trovare un maggior numero di vulnerablità presenti. Inoltre, come mostrato in figura 2, attraverso un IDS è possibile verificare se le policies aziendali vengono rispettate. Poniamo un esempio pratico, molti dipendenti, installano software di controllo remoto sul computer in ufficio, in maniera tale che possono controllare il pc personale che hanno a casa. Un ottimo applicativo che fa questo è teamviewer, la peculiarità di questo tool, è che usa la porta 80 e questa porta è 119 ovviamente aperta. L’uso di tale software in una grande azienda, salvo casi particolari, è tipicamente vietato dalle policies aziendale, in particolar modo se l’utente non è un amministratore di sistema. E’ possibile quindi, configurare l’IDS in modo tale da accorgersi se passa traffico verso il sito di teamviewer, in quanto tutte le chiamate tra il client e il server, passano dal server di teamviewer. Regola per traffico teamviewer a l e r t t c p any any −> any [ 8 0 , 8 0 8 0 , 3 1 2 8 ] ( msg : ’ ’ remote c o n t r o l h o s t : teamviewer . com ’ ’ ; f l o w : e s t a b l i s h e d ; c o n t e n t : ’ ’ . teamviewer . com ’ ’ ; n o c a s e ; h t t p h e a d e r ; r e f e r e n c e : u r l , nomeazienda . i t ; r e f e r e n c e : u r l , nomeazienda . com ; c l a s s t y p e : p o l i c y −v i o l a t i o n ; s i d : 1 2 4 4 5 0 1 5 ; r e v : 1 ; ) Altre regole di IDS (nell’esempio specifico è stato preso snort) potrebbero essere le seguenti: Regola per vedere traffico su IP sospetti a l e r t i p [XXX.XXX.XXX.XXX] any <> any any ( msg : ”IP b l a c k l i s t : APT” ; r e f e r e n c e : u r l , nomeazienda . com ; t h r e s h o l d : type l i m i t , t r a c k b y s r c , s e c o n d s 6 0 , count 1 ; c l a s s t y p e : ip−drs− l i s t ; s i d :92345599; rev : 3 ; ) Regola per vedere se nella rete è usato psexec Psexec è un tool prodotto da Microsoft, è tipicamente usato dagli amministratori di rete per poter lanciare comandi su macchine remote. E’ evidentemente un tool del tutto legittimo, ma spesso è anche usato da malintenzionati, che 120 essendosi già impossessati delle credenziali della macchina (magari attraverso un keylogger), ne approffitano per eseguire comandi dalla macchina. Potrebbe essere interessante valutare chi usa questo o altri programmi simili al fine di capire se la macchina è sotto attacco o meno. a l e r t t c p any any −> any [ 1 3 9 , 4 4 5 ] ( msg : ’ ’ s e r v i c e c r e a t e d : p s e x e c ’ ’ ; f l o w : e s t a b l i s h e d ; c o n t e n t : ’ ’ 5 c 00 50 00 53 00 45 00 58 00 45 00 53 00 56 00 43 00 2 e 00 45 00 58 00 45 ’ ’ ; r e f e r e n c e : u r l , xinn . o r g / Snort−p s e x e c . html ; r e f e r e n c e : u r l , doc . e m e r g i n g t h r e a t s . n e t / 2 0 1 0 7 8 1 ; c l a s s t y p e : dua l us e −t o o l −apt ; s i d : 2 0 1 0 7 8 1 ; r e v : 3 ; ) Immagginiamo una macchina, installata recentemente, quindi regolarmente aggiornata di tutte le patch necessarie. Immaginiamo anche che, l’attaccante, attraverso social engineering riesce ad installare un keylogger (tipicamente avviene tramite posta elettronica, l’utente in buona fede si installa il malware e lo esegue, magari camuffato da screen saver). Un VA tradizionale, non rileverebbe nulla, in quanto la macchina è regolarmente aggiornata, e non sono presenti vulnerabilità note. Analogamente, l’antivirus potrebbe non accorgersi di nulla. Ma l’attaccante, quando usa psexec, o altri hacking tool noti, verrebbe visto dal traffico di rete. Nel caso specifico di psexec, passerebbe il seguente pattern in esadecimale 5c 00 50 00 53 00 45 00 58 00 45 00 53 00 56 00 43 00 2e 00 45 00 58 00 45. Analizzando i diversi tool usati nel mondo hacking, è possibile costruirsi una serie di firme atte a riconoscere questi tool. Ovviamente questo richiede una forte conoscenza dei tool esistenti, e a volte è anche necessario scovare quelli non noti, perchè creati ad hoc. 121 Regola per vedere traffico RDP rigirato sulla porta 80 Altro attacco tipico, è quello di ridirigere il traffico su porte non standard, ad esempio a volte viene ridiretto il traffico rdp (tipicamente sulla porta 3389) sulla porta 80 (porta tipicamente aperta). a l e r t t c p any any <> any 80 ( msg : ’ ’ h a c k i n g t o o l : RDP o v e r 80/ t c p ’ ’ ; c o n t e n t : ’ ’ rdpdr ’ ’ ; c o n t e n t : ’ ’ c l i p r d r ’ ’ ; c o n t e n t : ’ ’ rdpsnd ’ ’ ; r e f e r e n c e : u r l , nomeazienda . com ; c l a s s t y p e : m a l i c i o u s −t r a f f i c −apt ; s i d :20020124; rev : 3 ; ) 122 Capitolo 9 Risk Exposure Analyzer Nei capitoli precedenti è stato discusso su come rilevare le vulnerabilità, sia a livello infrastrutturale sia a livello applicativo. Usando due metodologie differenti (VA e PVS). In questo capitolo verrà discusso un metodo per poter assegnare una priorità delle vulnerabilità rilevate. Non è scontato che sia necessario partire da quelle considate più gravi, infatti potrebbe essere che si sistemi prima una una vulnerabilità classificata come media, presente su un server web, rispetto a una vulnerabilità classificata come alta presente su un server di stampa. 9.1 Risk Analisisys overview Come abbiamo visto nei vari capitoli le minacce informatiche sono fortemente presenti nel mondo IT, e queste provocano gravi problemi sia da un punto di vista della sicurezza, sia dal punto di vista economico; non solo a livello aziendale ma come discusso nel capitolo , il problema è presente anche a livelli nazionali; ne consegue che tali problemi, non possono più essere ignorati dall’IT. Abbiamo visto come individuare, prevedere e prevenire gli attacchi 123 alla sicurezza informatica; i responsabili IT devono avere una visione globale delle loro reti, devono avere modo di visualizzare rapidamente ed individuare problemi di sicurezza e vulnerabilità della rete. Una volta identificati i problemi, hanno bisogno di sapere le migliori opzioni da intrapprendere, azioni preventive per ridurre o eliminare i rischi per la sicurezza. Nel campo IT, quando si parla si analisi dei rischi, è fondamentale avere approfondite conoscenze tecniche, come ad esempio: • sistemi informatici; • servizi utilizzati; • networking; • information security. Il raggiungimento degli obiettivi di qualsiasi iniziativa passa necessariamente attraverso l’individuazione e la valutazione dei rischi ad essa connessa. La gestione del rischio non è un’attività a costo zero e pertanto richiede competenze e approcci metodologicamente coerenti che da una parte garantiscano il risultato e dall’altro ne contengano i costi. E’ quindi necessario, un’analisi preliminare dove viene impostata un’analisi in base al contesto in cui ci si trova, in base ai processi aziendali, al valore delle informazioni trattate etc. Da un punto di vista pratico, questo comporta conoscere alcuni dettagli del contesto, come: • esigenze in termini di sicurezza; • tiplogia del dato trattato; • traffico di rete; 124 • hardware a disposizione; • software utilizzato; • servizi che si vogliono offrire. Ad ogni modo, per quanto riguarda la gestione del rischio nel mondo IT esistono standard internazionali (che vedremo nel capitolo 1). E’ evidente che a questo punto, dopo aver effettuato il Vulnerability Assessment, ed aver trovato un certo numero di vulnerabilità, bisogna pesare adeguatamente quest’ultime. Una parte di esse, potrebbero essere mitigate tramite regole dei firewall, mentre altre no. In un caso siffatto, al di là delle gravità rilevate dai vari tool utilizzati (alte, medio, basse), come ho scritto nel capitolo 10, potrei avere una vulnerabilità grave a livello applicativo, ma mitigata dal WAF, ne consegue che potrei concentrarmi su un’altra vulnerabilità, che magari è meno grave, ma non mitigata. 9.2 Skybox Security Quando si esegue un VA in una rete complessa, potrebbe essere oneroso valutare se le vulnerabilità sono mediate o meno dalle regole dei firewall. In questo caso esistono strumenti che permettono di disegnare la rete con gli asset presenti come ad esempio: • server; • client; • router; • firewall, con le rispettive regole. 125 e tramite automatismi, riescono a valutare se la vulnerabilità presente su un determinato asset è sfruttabile o meno, questo è possibile grazie a delle simulazioni di attacchi. Skybox View è un tool sviluppato da Skybox Security, questo tool permette di avere una visione completa del livello di esposizione al rischio dei vari asset presenti all’interno del perimetro di analisi. E’ possibile preparare il modello della rete aziendale, inserire le regole dei firewall presenti, inserire le vulnerabilità presenti sui sistemi (trovate sia al livello infrastrutturale che applicativo), ha la possibilità di simulare attacchi noti, suggerendo come mitigare alcune problematiche (es. installazione patch, modifiche alle configurazioni di rete, introduzione IPS). I tool analizzati nei vari capitoli, hanno il grosso vantaggio di restituire un report (generalmente in formato xml), e Skybox View, è in grado di leggere quei formati, questo ci permette di avere un reale riscontro sulla situazione della rete e degli applicativi nella realtà presa in considerazione e di pesare meglio la gravità della singola vulnerabilità. Con gli strumenti Risk Exposure Analyzer (REA) vengono acquisiti dati di diversa natura: report di VA, configurazione apparati del network, policy dei Firewall, configurazioni di IPS, report di scansioni applicative (ed esempio da Rational Appscan visto nel capitolo 7), ecc.. 126 Fig. 9.1: Risk Exposure Analysis Sulla base dei dati raccolti viene costruito un modello fedele alla propria infrastruttura IT. Il modello viene poi completato, con il supporto del cliente, con informazioni relative alla funzione e il valore degli asset critici. Vengono quindi configurate ipotetiche minacce in grado di colpire gli asset critici indicando skill e privilegi di partenza. Sulla base dei fattori di vulnerabilità, valore asset, minaccia, SkyboxView calcola il livello di Rischio della infrastruttura IT. Evidenzia inoltre le vulnerabilità critiche esposte ai potenziali attacchi che dovranno avere la massima priorità di remediation. SkyboxView fornisce inoltre utili suggerimenti sulle azioni da apportare per sanare la vulnerabilità (applicazione patch, modifica ACL, abilitazione firma IPS, ecc). REA produce un report integrabile con quello di VA infrastrutturale e VA applicativo. Prima di procedere con l’analisi e la gestione del rischio del servizio di business in esame è necessario definire, insieme al cliente, i tre parametri fondamentali 127 di Confidenzialità, Integrità e Disponibilità (CIA, Confidentiality, Integrity, Availability) relativi alla sicurezza dell’informazione e sull’impatto che può avere verso gli attacchi informatici. La definizione di questi parametri indica quali sono gli elementi di rete più importanti all’interno dell’infrastruttura di rete e dove vengono memorizzati i dati sensibili (Numeri di Carte di Credito, Stato di salute degli utenti, ecc) relativi al servizio di business. Fig. 9.2: CIA Questi parametri devono essere definiti con estrema cura, poiché una errata definizione porterebbe ad un risultato distorto nel calcolo della finestra d’esposizione al rischio con l’utilizzo di strumenti automatici. 128 9.2.1 Caso di studio E’ stato eseguito il seguente test: scansionando con Nessus alcune macchine Linux interne ad una rete, e una macchina pubblica. La rete era impostata come da figura 9.3 Fig. 9.3: Mappa di rete Sostanzialmente l’unica vulnerabilità alta presente in molte macchine (ma solo quelle interne) erano la credenziale di default user root e psw root. Il firewall ha un’unica regola, ossia accettare tutto da tutti, in questo modo skybox mi solleva giustamente che l’impatto della vulnerabilità è alta. 129 Fig. 9.4: Skybox prima del bilanciamento CIA Modificando l’impatto al bussiness aziendale, si può notare come l’impatto al rischio si riduca (a seconda della configurazione data). 130 Fig. 9.5: Skybox dopo del bilanciamento CIA Naturalmente, lasciando un impatto alto, ma isolando la rete con opportune regole di firewall, allora l’impatto al rischio si azzera. mv 131 Capitolo 10 Web Application Firewall Possono essere diversi i metodi di remediation, e tutti devono essere contestualizzati alla rete analizzata. Considerato però, che come è stato detto nell’introduzione il mondo web, è ormai il mondo preferito degli attaccanti, si è voluto dedicare questo capitolo ai benefici del Web Application Firewall (WAF). 10.1 Caratteristiche dei WAF I Web Application Firewall (WAF) rappresentano una nuova generazione di tecnologie dell’IT, atta a tutelare i siti web da eventuali attacchi e lavorano al layer 7. Sono soluzioni in grado di prevenire attacchi che i tradizionali network firewall e IDS non potrebbero rilevare. In particolare, i firewall tradizionali sono a livello network, quindi possono aprire o chiudere determinate porte, filtrando per indirizzi IP, mentre i tradizionali IDS possono fare poco o nulla con il traffico cifrato. Come vedremo in seguito, i WAF possono sopperire a queste carenze: infatti, sempre più spesso, per proteggere le comunizioni tra client e server si usa 132 il protocollo HTTPS. Considerando che quest’ultima tipologia di protezione ha come obiettivo quello di ottenere la cifratura dei dati in transito, questo implica, come detto sopra, che i tradizionali IDS non sarebbero in grado di rilevare le anomalie di questo genere di traffico. Considerando la forte diffusione del protocollo SSL, è indispensabile che un WAF possa ricostruire il traffico cifrato e lo possa analizzare. Questo viene fatto simulando un attacco di tipo man in the middle (MITM), generando una coppia di chiavi tra web server e WAF e rigirando le chiavi al client. In questo modo, sarà possibile la ricostruzione dell’intero traffico SSL. Un’altra peculiarità importante dei WAF è che non richiedono modifiche al codice sorgente dell’applicazione che vogliamo proteggere. Questi strumenti proteggono le applicazioni, le infrastrutture web e le risorse di back-end dagli attacchi applicativi, sia attraverso i canali standard sia attraverso canali cifrati. Come pubblicato dal Web Application Security Consortium [2], le principali caratteristiche di un WAF sono: • il traffico viene ispezionato dal WAF sia in modalità attiva che passiva; • in caso d’installazione in modalità attiva è possibile bloccare le connessioni del protocollo di rete, in modo da non essere inoltrati al server web; • il traffico è controllato e in caso di anomalie non viene bloccato il servizio, ma potrebbe essere bloccata la connessione alla destinazione. Questo può avvenire sia prima che i pacchetti arrivano a destinazione (ad esempio un singolo attacco-packet) sia dopo che una connessione parziale è stata tamponata, ma non completato la destinazione (ad esempio nel caso di pacchetti segmentati); 133 • l’ispezione HTTPS è in grado di bloccare gli attacchi incorporati nei pacchetti crittografati con SSL; • le misure anti-evasione normalizzano le richieste (ad es. standardizzando i set di caratteri o i nomi di percorso codificati o sospetti) prima dell’analisi. 10.2 WAF e scansione applicativa L’utilità del WAF è evidente a tutti, ma questi strumenti usati insieme a scanner applicativi possono dare dei valori aggiunti non indifferenti. Come detto sopra, il WAF, se installato in modalità attiva, può bloccare determinate request HTTP, mentre se installato in modalità passiva rileva cosa avrebbe bloccato. Questa seconda modalità d’installazione permette di avere un primo riscontro, ossia, se il WAF è installato in modalità offline, e contemporaneamente lanciamo una scansione applicativa vista nel capitolo 6, abbiamo immediatamente un riscontro su quelle che dovrebbero essere immunità ”certe” (con tutte le precauzioni del caso), o meglio, quali attacchi falliscono sulla nostra applicazione. Infatti, i tool di scansione applicativa mettono in evidenza quali attacchi possono compromettere la nostra applicazione. Il WAF, invece, rileva cosa avrebbe bloccato (se fosse stato installato in modalità online). Il confronto dei due esiti può invece mettere in evidenza, cosa avrebbe bloccato il WAF, ma sapendo che l’attacco è fallito, allora troviamo le vulnerabilità che vengono mediate dal WAF. 134 Fig. 10.1: Riscontro scansione applicativa e WAF Questo ci permette di dire che, dato un insieme V di vulnerabilità usate dal software di scansione delle applicazioni, come visto nel capitolo 6, e un insieme B di pacchetti bloccati dal WAF, ∀v ∈ V con pacchetto nella forma b ∈ B, qualora il WAF segnalasse che avrebbe bloccato tale pacchetto, allora possiamo affermare che seppur l’applicazione testata è vulnerabile a tale attacco, il WAF media tale vulnerabilità. Esempio 1: supponiamo che l’applicazione non sia vulnerabile all’attacco v ∈ V ; il software di scansione applicativa prova l’attacco v, che naturalmente fallisce; il software di scansione applicativa generalmente segnala come output solo le vulnerabilità con esito positivo, mentre in questo caso il WAF segnala che avrebbe fermato i pacchetti di quell’attacco. Apparentemente questo risultato potrebbe sembrare la ”prova del nove”: infatti è noto che un tool di scansione riconosce un determinato numero di attacchi, quindi tutti gli attacchi falliti potrebbero essere immunità ”certe”. 135 Questo, però, è vero fino ad un certo punto, in quanto il numero di signature testate dal software di scansione applicativa, variano a seconda dei settaggi di configurazione, impostati prima della scansione. Non è immediato stabilire quale sottoinsieme di test case abbia lanciato lo scanner applicativo. Usando contemporaneamente i due moduli abbiamo invece velocemente le immunità ”certe” (con tutte le precauzioni del caso). Esempio 2: supponiamo che l’applicazione sia vulnerabile all’attacco v ∈ V ; in questo modo, se il WAF fosse configurato in modalità inline, bloccherebbe l’attacco. Questo ci permetterebbe di pesare meglio la gravità di tale vulnerabilità che di fatto non andrebbe a buon fine. Dall’esempio 2 emerge un ulteriore vantaggio dell’uso dei due prodotti in parallelo: il WAF esegue una serie di statistiche su cosa blocca (o su cosa avrebbe bloccato, a seconda della modalità d’installazione). Parallelamente lo scanner si limita a dire quali vulnerabilità sono presenti su determinate pagine (supponendo un’applicazione web) e quest’ultimo stima le gravità delle vulnerabilità, secondo opportuni standard, come CVE. Quindi, rilevate n vulnerabilità, si potrebbe generare una funzione weight f : F (v)|{v ∈ V } → x atta a ripesare le vulnerabilità, a seconda delle statistiche rilevate dal WAF. Quindi, ∀v ∈ V viene associato un valore, detto costo C. Tale costo potrebbe a sua volta essere funzione in base al numero di occorenze di v ∈ V , oppure essere funzione al valore di CVE, etc. Il valore di ritorno della funzione F verrà utilizzato nella fase di analisi del rischio che vedremo nel capitolo 9. 136 Application Scan WAF Vulnerabilità A pagina 1 Vulnerabilità A = 15 (10 pg 1 - 5 pg 2) Vulnerabilità A pagina 2 Vulnerabilità B = 3 (3 pg 1) Vulnerabilità B pagina 1 Tabella 10.1: Visualizzazione vulnerabilità, scanner applicativo e un WAF Un ulteriore vantaggio, se il WAF è installato prima in modalità offline (in caso di assessment il buon senso vuole che prima sia offline), dallo scan applicativo sappiamo quali sono le vulnerabilità presenti nell’applicazione; sappiamo anche che impostando successivamente il WAF in modalità inline possiamo sicuramente fermare un sottoinsieme di vulnerabilità senza modificare il codice. Questo ci permette ancora di modificare il valore del costo C, concentrandoci prima su quelle che magari un WAF non potrebbe bloccare. Il WAF infatti, non è in grado di bloccare tutte le vulnerabilità trovate in un’applicazione: ad esempio, non potrebbe fare nulla nei seguenti casi: • applicazione installata in modalità debug; • scambio di dati in chiaro. Fig. 10.2: WAF in modalità offline 137 Fig. 10.3: WAF in modalità inline 138 Capitolo 11 Conclusioni Attraverso questo lavoro, ho potuto mettere in evidenza l’importanza della messa in sicurezza delle reti aziendali e della sensibilizzazione rispetto ai pericoli che le aziende moderne sono esposte ai gioni nostri. Tuttavia, se analizziamo bene il framework visto nel’ISO 31000 1.2 emerge come sia fondamentale il ciclo continuo all’interno del framework. Abbiamo anche visto come i vulnerability assessment tradizionali soffrano del problema della degradazione, in quanto la realtà della rete aziendale è in continua evoluzione. Per questo motivo, l’uso prolungato di un IDS ci permetteva di avere un monitoraggio continuo; tuttavia, le vulnerabilità trovate con queste metodologie rappresentano due insiemi, intersecati in parte tra loro, la cui unione permette sicuramente di avere un valore aggiunto e quindi un maggiore controllo sulle vulnerabilità presenti. Comunque, rimane utile eseguire anche il VA tradizionale con una certa periodicità. In maniera del tutto analoga,anche l’esecuzione dell’analisi applicativa white e black box, anche queste ultime rappresentate da due insiemi differenti di vulnerabilità riconosciute e con una parte di intersezione, consiste in un valore aggiunto nello specifico per ciò che riguarda la facilitazione dello scorporo dei falsi positivi. 139 Visto l’insieme continui di questi processi, è fondamentale un controllo e attenzioni sistematici sugli aspetti sopraesposti, tenendosi aggiornati sulle nuove modalità che i malintenzionati sfruttano per violare le infrastrutture e le applicazioni, e studiare quali possibili metodoligie di difesa possono essere attuate contro i nuovi attacchi. Il lavoro di tesi lascia spazio a sviluppi futuri, oltre ad affrontare in maniera più approfondita il mondo del vulnerability assessment, sarà necessario implementare una ricerca per una metodologia atta a rilevare advance persistent threat (APT) in modo tale da poter rilevare, magari tramite sistemi di Intrusion Detection System (IDS) i pattern di questi binari rendendo cosi, l’infrastruttura ancora più sicura. 140 Bibliografia [1] 2006. http://leotardi.no-ip.com/download/manuali/manuale_ riskanalisys.pdf. [2] Web Application Firewall Evaluation Criteria. Web Application Security Consortium, January 2006. http://www.webappsec.org. [3] 2009. http://www-03.ibm.com/press/it/it/pressrelease/26644.wss. [4] PhD thesis, 2010. [5] Prof. Marco Cremonini Università degli Studi di Milano. Lezioni in Sicurezza nelle reti. 2010. [6] ISO27001, 2005. hhttp://www.iso27001security.com/html/27001.html. [7] ISO31000, 2009. hsec.ir/file/pdf/ISO-31000.pdf. [8] ISO31010, 2009. www.previ.be/pdf/31010 FDIS.pdf. [9] Kevin Mitnick. L’arte dell’inganno. 2006. [10] OWASP. https://www.owasp.org/index.php/Main Page. [11] ProgettoEnea, 2003. http://dgerm.sviluppoeconomico.gov.it/ dgerm/news/rapportoblackout28092003.asp. 141 [12] ProgettoEnea, 2008. http://progettoreti.enea.it/rassegna/ Protezione_infrastrutture.pdf. [13] RAMS. www.mobilab.unina.it/tesi/Tesi [14] RELIABILITY. www.cad.polito.it/~sonza/diistp03/lucidi/ 2008/3_reliability.pdf. [15] wikipedia. http://it.wikipedia.org/wiki/Stuxnet. [16] John McHugh William A. Arbaugh, William L. Fithen. http://www.cs.umd.edu/w̃aa/pubs/Windows of Vulnerability.pdf. 142 Appendice A Raccolta dati e reportistica Durante l’attività di VA, vengono raccolti dati rdelle scansione eseguite, il numero di macchine analizzate possono variare da poche unità a diverse centinaia. E’ evidente che se la rete è grande, non è possibile analizzare a mano i singoli report generati dai vari tool visti in precedenza, ma è necessario un raccoglitore in modo da avere sotto mano tutte le vulnerabilità rilevate dai diversi tool. A.1 MagicTree MagicTree è un’applicazione open source atta a raccogliere i vari output dei diversi tool nominati in questo lavoro (e molti altri) per raccoglierli, analizzarli nella loro globalità, e stampare i report da consegnare al cliente. La tabella A.1, mostra tutti i tool compatibili con questo software. 143 Infrastrutturale Nexpose Infrastrutturale Nessus Infrastrutturale OpenVas Infrastrutturale Nikto Infrastrutturale nmap Applicativo ZAP Applicativo Burp Tabella A.1: MagicTree tool riconosciuti Questo tool, come mostra la figura A.1, e come suggerisce il suo stesso nome, mostra l’alberatura dei vari asset analizzati durante tutta l’attività. MagicTree potrebbe essere configurato in modo tale che ogni fosse un indirizzo IP, oppure ogni nodo potrebbe essere una subnet. Allinterno del nodo host, vengono automaticamente creati i sottonodi delle varie informazioni raccolte nell’attività di VA. Tali informazioni possono essere vulnerabilità o solo informazione raccolta, ad esempio: • versione di sistema operativo (trovate con Nmap o Nessus); • elenco delle porte aperte (trovate con nmap); • elenco delle vulnerabilità (trovate con Nessus); • elenco delle cattive configurazioni (trovate con Nikto). 144 Fig. A.1: MagicTree Essendo organizzato ad alberatura, qualora considerassimo una vulnerabilità rilevata un falso positivo, allora basterà semplicemente eliminare il nodo presente (automaticamente verranno eliminati tutti i sottonodi). Quindi a depurazione ultimata basterà selezionare un template di reportistica ed automaticamente verranno generati dei report. I template presenti sono circa una una decina, ma sono facilmente personalizzabili attraverso XSLT, che legge ed interpreta i file xml avuti in ouptut dai diversi tool. Il vantaggio di questo prodotto, non è solo la reportistica, ma tramite l’uso di XPATH, è possibile interrogare i vari dati raccolti creando, di fatto, delle query. Inoltre, per i tool usabili da command line, è possibile inserire il comando dall’interfaccia di MagicTree (è fatto in java quindi è multipiattaforma), con la possibilità, di lanciare il comando su un server remoto (ovviamente avendone le credenziali, e sul server deve essere installato il tool usato). 145