1. UNIVERSITÀ DEGLI STUDI DI TRIESTE
FACOLTÀ DI INGEGNERIA
Corso di laurea magistrale in Ingegneria Informatica
Tecniche di Test-driven development
in ambito sicurezza informatica
e rilevazione vulnerabilità
Laureando Relatore
Federico Cecutti chiar.mo prof. Alberto Bartoli
Correlatore
Enrico Milanese
anno accademico 2011/2012

2. Contesto preesistente
Analisi delle vulnerabilità
● Software di analisi delle vulnerabilità informatiche
● Vulnerabilità di applicazioni remote
● Rilevate interagendo con il servizio remoto
● analisi della prima risposta (banner)
● analisi di contenuti di pagina web
● analisi dei numeri di versione
2

3. Contesto preesistente
Base di conoscenza
● Schemi da ricercare
● spesso con espressioni regolari
Base di conoscenza
● Dati da inviare
Continuamente nuove minacce
aggiornamento continuo 3

4. Contesto preesistente
Problemi
● Aggiornamento manuale, difficilmente automatizzabile
● Eventuali errori di aggiornamento hanno conseguenze gravissime:
● non si rileva una vulnerabilità presente
● si dichiara vulnerabile una situazione corretta
● Possono esserci conseguenze molto tempo dopo l'aggiornamento
● Espressioni regolari spesso complesse
● Errori per nulla evidenti 4

5. Obiettivo
● Diminuire la probabilità di errori di aggiornamento
● Strumenti:
● campagna di test per validare i nuovi inserimenti
PRIMA FASE DI LAVORO
● generatore di espressioni regolari da esempi
SECONDA FASE DI LAVORO
● Vincoli: Python 2.4.1, sviluppo test-driven 5

6. PARTE PRIMA
Campagna di test
6

7. client server
Vulnerabilità di app. remote
Scenario di base
Handshake:
Apertura della connessione
(richiesta del client) ATTORI
● Client (C) e server (S)
● C: conosce la situazione vulnerabile
● C: vuole verificare se il server è vulnerabile
r
anne
n e il b
c onti e
INTERAZIONE
● C: invia richiesta che scatena lo scenario vulnerabile
Handshake:
Chiusura della connessione
● S: risponde, rendendo evidente la sua vulnerabilità
● C: ha scoperto che il server è vulnerabile
7

8. Vulnerabilità di applicazioni remote
Analisi di vulnerabilità
● In pratica, nell'analisi di vulnerabilità:
● una situazione del genere per ogni vulnerabilità nota
● il client è il sistema di analisi di vulnerabilità
● per ogni vulnerabilità individuata, si memorizzano
alcune informazioni rilevanti
8

9. Tipi di test
● Tutti i test riguardano le vulnerabilità di applicazioni remote
nell'analisi di vulnerabilità
● Due livelli di test:
● Test di integrazione: riproducono l'interazione tra gli endpoint
● Test specifici: si limitano ad analizzare un aspetto della risposta
● Ogni futuro aggiornamento della base di conoscenza sarà test-driven 9

10. Test di integrazione
nell'analisi di vulnerabilità
● Solo in alcuni casi noti
● Si testa la corretta individuazione di queste informazioni
● Si valida la logica aziendale di rilevazione delle vulnerabilità
10

11. Test di integrazione
Problematiche
● È necessario riprodurre in locale lo scenario vulnerabile
● Il test deve utilizzare un simulatore del server:
● deve restare in attesa di connessioni dai client
● deve rispondere ai client come un endpoint vulnerabile
● Lato client, si utilizza la funzione del sistema di analisi di vulnerabilità
● Ma: la funzione utilizza degli oggetti per riportare le vulnerabilità trovate
● necessari oggetti mock con la stessa interfaccia di quelli reali
11

12. lato server
12
lato client

13. Analisi specifica
● In generale, legame complesso tra risposta e vulnerabilità
● Spesso una vulnerabilità riguarda soltanto nodi o software con certe
caratteristiche
● Spesso, fase preliminare di analisi delle caratteristiche
● output: un dizionario consuntivo per ogni endpoint analizzato
● Le vulnerabilità sono scoperte in base alle caratteristiche rilevate
13

14. Test specifici
● In tre ambiti: banner, contenuto pagina web, numeri di versione
● Per banner e pagine web, si testa l'analisi delle caratteristiche
● Alcuni test su singoli sistemi
● verificano la corretta individuazione delle caratteristiche/vulnerabilità
● Altri test applicati a tutti i file della base di conoscenza
● verificano la coerenza interna dei file
14

15. Test specifici
Test su singoli sistemi
● Si attiva l'analisi di vulnerabilità su alcuni sistemi di interesse
● Per banner e pagine web:
● si verifica che il dizionario consuntivo contenga chiavi e valori attesi
● Per numeri di versione:
● si testano i casi limite delle espressioni regolari
● asserzioni positive dentro ai range e negative fuori 15

16. Test specifici
Test di coerenza interna XML
● Si analizza ciascun file XML
● Obiettivo ideale: garantire assenza di alterazioni accidentali e ripetizioni
● In pratica:
● Test di correttezza sintattica
● Test di coerenza tra parti
16

17. Base di conoscenza
File XML per banner e pagine web
● La base di conoscenza è formata da file XML con questa struttura:
esempio
filtro (unico)
blocco
caratteristica
caratteristica
input
esempio
filtro (unico)
output
blocco
caratteristica funzionamento 17

18. Base di conoscenza
File XML per numeri di versione
● La base di conoscenza è formata da file XML con questa struttura:
blocco
filtri
input '7.0.0'
blocco
filtri Rileva la 18272 e la 18395
output
funzionamento 18

19. Test specifici
Test di coerenza interna XML
19

20. Test-driven development
● Ciclo continuo di sviluppo e test:
● eventuali errori nella codifica sono individuabili subito
● Strategie per sviluppare i test:
● per stesure successive
● con segnaposto: pass, TestCase.fail
● schema assertivo: pochi metodi, standardizzazione dei messaggi
20

21. PARTE SECONDA
Generazione di espressioni regolari
21

22. Problema
● Test precedenti:
● la coerenza di un'espressione regolare con un commento lascia
troppi gradi di libertà
esempio
blocco
filtro (unico)
caratteristica
● Espressioni regolari spesso complesse
● Espressioni regolari inserite a mano
22

23. Soluzione
● Strumento di generazione automatica
● Aiuto nei nuovi inserimenti
esempio
blocco
filtro (unico)
esempi (INPUT)
espressione regolare (OUTPUT) 23

24. Soluzione
● Il risultato:
● deve essere conforme a tutte le stringhe di esempio
FACILE
● deve riflettere le caratteristiche delle stringhe di esempio
DIFFICILE
esempi (INPUT)
espressione regolare (OUTPUT) 24

25. Soluzione
● deve riflettere le caratteristiche delle stringhe di esempio
DIFFICILE
● In pratica:
● si analizza la struttura delle espressioni regolari già presenti
● si generano poche tipologie di soluzioni, simili a quelle presenti
● si lasciano molte scelte all'operatore
– in base a considerazioni semantiche, complementari alla
struttura delle stringhe
25

26. Tipi di soluzione
● Gerarchia di tipologie, a livelli successivi di specificità
● cws – common word solution
● Riporta le parole comuni a tutte le stringhe
● Tra di esse, pattern generico '.*'
● Esempio: '^.*(?<!w)Print(?!w).*(?<!w)Server(?!w).*$'
● Nei due tipi di soluzione derivati si riscrivono i '.*' di cws
26

27. Tipi di soluzione
●
ftscw – frequent token solution from cws
● '.*' sostituiti con sottostringhe frequenti
● Si definiscono 4 tipologie di pattern:
● S (spaziature): 's+'
● D (cifre): 'd+'
● W (parola): 'w+'
● P (punteggiatura): '[^sw]+'
● Ogni stringa è conforme a una sequenza di questi 27

28. Tipi di soluzione
● ps – pattern solution
● '.*' sostituiti con sequenze di pattern
● Esempio: '.*' → 'w+s+w+'
●
ftsp – frequent token solution from ps
● Ogni pattern di ps è sostituito con le sottostringhe frequenti
● Esempio: 'w+s+w+' → '(?:Server|Service|w+) w+'
28

29. Workflow
Problematiche principali
● Sottosequenza comune più lunga
● Per trovare lo scheletro di parole comuni a tutte le stringhe
● Risolto con un adattamento dell'algoritmo di Hunt-McIlroy
● Corrispondenza
● Le stringhe potrebbero contenere varie occorrenze delle parti comuni
● Quali delle occorrenze sono strutturalmente affini?
● Risolto con un algoritmo progettato ad hoc
● Espressione regolare per il singolo pattern
● Per generalizzare parti diverse in corrispondenza
● Risolto con un algoritmo progettato ad hoc 29

30. Test-driven development
● Per il generatore l'implementazione parte da zero
● ≈ ogni funzione ha un proprio file di test
● La codifica di ogni funzionalità è preceduta da quella dei relativi test
● Grandi vantaggi:
● errori scopribili subito
● moduli piccoli e semplici
● immediata disponibilità di esempi corretti
30

31. PARTE TERZA
Conclusioni
31

32. Conclusioni
Campagna di test
● Errori accidentali meno probabili
● Si sono considerati gli errori più tipici
● Molti errori dipendono dal significato dei dati
dati dimensionali
● All'attivazione dei test:
● 104 espressioni regolari scorrette su 1492 analizzate → ca. 6,97%
● soprattutto imprecisioni poco rilevanti
● spesso '.' invece di '.'
● Possibile misura di valore: rapporto regex modificate / regex totali
● Si ipotizza incidenza degli errori tempo-invariante 32

33. Conclusioni
Generatore di espressioni regolari
● In generale, valutare le prestazioni è complesso
● troppe variabili da considerare
● molte variabili sono difficili da misurare (ad es. la genericità)
● Operatività possibile grazie all'introduzione di schemi per la soluzione
● Situazione migliorata per l'operatore
dati dimensionali
● Lavoro svolto già incluso nell'operatività aziendale 33