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