1. `
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 Presentata da
Prof. Walter Cerroni Marco Frison
Correlatore
Ing. Marco Ramilli
Sessione II
Anno Accademico 2006/2007

3. Copyright c 2007 Marco Frison <marco.frison@studio.unibo.it>
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”.

5. “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

7. 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 citt` di Cesena . . . . . . . . . . . . . 30
a
4 Wireless IDS 33
4.1 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Attacchi e contromisure . . . . . . . . . . . . . . . . . . . . . 40

8. 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

9. 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 pi` note sul mercato con
u
l’acronimo Wi-Fi queste tecnologie hanno saputo imporsi per diversi moti-
vi, essenzialmente riconducibili al basso costo dei dispositivi e alla notevole
semplicit` di installazione ed utilizzo.
a
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 ` presto divenuto un fattore insostenibile
e
per le grandi societ` e gli enti governativi che richiedono rigorose procedure
a
di controllo e standard certificabili.
Un susseguirsi di sempre nuove vulnerabilit` facilmente sfruttabili e di ra-
a
pida automatizzazione ha convinto la Wi-Fi Alliance prima e il gruppo 802.11
poi della necessit` di riprogettare interamente l’impalcatura di autenticazione
a
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 pi` moderni e recenti standard di sicurezza, questa tesi pone co-
u
me obiettivo lo studio delle problematiche di monitoraggio e rilevamento del-

10. 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 vulnerabilit`.
a
Il quarto capitolo descrive dettagliatamente i Wireless IDS, delinean-
done l’architettura e discutendone le nuove problematiche; infine, come caso
di studio, ` presentato Kismet, uno scanner/WIDS open-source.
e
Nel quinto capitolo ` illustrata l’attivit` sperimentale, volta a verificare
e a
le attuali capacit` di Kismet.
a
Prima di continuare ` doveroso precisare come i termini “wireless”, “Wi-
e
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 far`, occasionalmente, un uso indistinto.
a
Marco Frison

11. Capitolo 1
Cenni di sicurezza
dell’informazione
Tra tutti i settori legati all’informatica la sicurezza dell’informazione ` forse
e
l’unico rimasto ammantato da un velo di ombre e misteri che, ancora oggi, lo
rendono agli occhi dei pi` non una vera e propria scienza, definibile formal-
u
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 difficolt` di formulare correttamente soluzioni al problema,
a
motiva la penuria, la giovinezza e la conseguente instabilit` delle comuni
a
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; ci`
o
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 comunit`
a
scientifica.
La definizione del concetto di sicurezza, per nulla univoco nel campo

12. 2 Cenni di sicurezza dell’informazione
dell’informatica, ` il nostro primo passo nel processo di sviluppo di quella
e
figura professionale che chiameremo “security engineer”, in virt` della ferma
u
volont` di rievocare le prassi operative dell’ingegneria.
a
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 (confidenzialit`, integrit` e
a a
disponibilit`) [1] [2]. Si osservi che le definizioni a seguire divergono legger-
a
mente da quelle espresse nei documenti di ricerca analizzati e rappresentano
una rielaborazione personale che pu` essere vista come parte del contributo
o
originale di questo studio.
La confidentiality riguarda la necessit` di rendere accessibili le risorse del
a
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 capacit` o meno di accedere in lettura al dato/ri-
a
sorsa ma pi` intrinsecamente la possibilit` di riservatezza riguardo l’esistenza
u a
stessa dell’informazione.
La integrity esterna la capacit` di garantire che la risorsa sia validabile,
a
cio` la definizione di una relazione ternaria tra le risorse, gli utenti e lo
e
spazio delle possibili operazioni; non solo include vincoli di consistenza su
modifica, cancellazione o altri accessi in scrittura ma anche la possibilit`
a
di verificare l’origine dell’informazione; questo punto ` inequivocabilmente il
e
nodo critico della struttura in quanto generalmente la fiducia di una sorgente
non ` valutabile obiettivamente ma solo tramite assunzioni poste a priori.
e
La availability definisce la volont` di garantire, entro un tempo accettabi-
a
le, che l’utilizzo di una risorsa non sia mai negato ad un utente effettivamente

13. 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’usabilit` dello stesso da parte del personale autorizzato. Quest’assunzione,
a
indicando come requisito un “tempo accettabile”, pu` limitare fortemente
o
la scelta delle tecniche implementative e condurre persino alla decisione che
un particolare rischio ` accettabile o trasferibile (ad esempio per mezzo di
e
un’assicurazione).
Ricordiamo infine, a scanso di equivoci, come queste definizioni siano da
assumere nel modo pi` generale possibile e non limitatamente ai concetti
u
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. ` stato rias-
e
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:
ci` ` classicamente accettato in quanto quest’ultima attiene maggiormente,
oe
ma in ultima analisi non esclusivamente, alle capacit` infrastrutturali del si-
a
stema: ad esempio essa ` generalmente trattata in termini di throughput,
e
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-

14. 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’identit` collegandola ad un qualche genere di token, generalmente una
a
password ma anche impronte vocali o, come sopra, sistemi hardware o bio-
metrici. In questa fase ` significativo l’utilizzo di tecniche crittografiche; ad
e
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, ` in assoluto
e
il tema pi` delicato e per questo maggiormente studiato in ambito scienti-
u
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 ` sicuramente il pi` diffuso e quello a cui siamo nor-
e u
malmente abituati: ` tipicamente la scelta di default sia nei sistemi Unix (e
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’identit` del soggetto e/o del gruppo a cui ap-
a
partiene”, ignorando completamente la nozione di proprietario che dunque
non costituisce un prerequisito ma solamente la pi` comune scelta imple-
u
mentativa. In questi sistemi il termine Discretionary indica che il detentore
di un diritto su una particolare risorsa pu` delegare ad altri utenti, anche
o
indirettamente, questo suo privilegio.

15. 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 sensitivit` dell’infor-
a
mazione contenuta e da una formale autorizzazione del soggetto all’accesso
a informazioni di tale sensitivit`. Questa asserzione implica che ogni risorsa
a
` preventivamente inserita in uno specifico contesto di sicurezza nel quale gli
e
utenti autorizzati possono eseguire un ristretto sottoinsieme di operazioni,
anch’esso predeterminato; tipicamente questo compito ` eseguito dal secu-
e
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 ` la possibilit` di inibire particolari operazioni ad un utente anche
e a
per risorse da lui stesso create e/o possedute: questo garantisce una robu-
stezza e un livello di granularit` molto pi` fine di quello permesso in una
a u
architettura DAC in quanto l’identit` del soggetto non ` pi` condizione ne-
a e u
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 pi` famosi riconducibili
u
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 pi` apprezzata non solo in ambito accademico ma anche in campo com-
u
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.

16. 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 societ` umana, rappresenta un cambiamento sostanziale in quanto eleva
a
arbitrariamente la granuralit` e l’approccio del least privilege apportabile al
a
sistema; inoltre ` intuitivamente applicabile ricorsivamente a pi` livelli, ad
e u
esempio in caso si debbano gestire enormi volumi di ruoli, utenti e permessi.
Data la sua giovane et` questo criterio ` ancora poco diffuso nel set-
a e
tore dei sistemi operativi mentre ` da tempo l’implementazione standard
e
per la maggior parte dei DBMS in commercio, tra cui citiamo Oracle e
PostgreSQL; piacevole eccezione a quanto appena argomentato ` grsecurity
e
[7], fruibile come patch per il kernel Linux, mentre soluzioni ibride MAC-
RBAC sono disponibili in FreeBSD, Trust Solaris e tramite il gi` citato
a
SELinux.
1.3 Inadeguatezza del paradigma
Giunti a questo punto ha senso, o meglio ` necessario, domandarsi che li-
e
vello di sicurezza garantiscano questi modelli. Nessuno. Una risposta tanto
immediata quanto raggelante. Nessuna assicurazione pu` essere formulata
o

17. 1.4 Violazioni al paradigma 7
in termini di safety, nessuna verifica di “buon comportamento” ` di per se
e
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 propriet` di ge-
a
stione e certificazione tipiche di quest’ultimi: gli studi qualitativi prevedono
difatti un miglioramento asintotico frutto di un rapporto qualit`/prezzo sta-
a
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 ` vulnerabile, potenziale
e
vittima di aggressioni. Chiunque affermi il contrario ` inequivocabilmente
e
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; pu` essere perpre-
o
tata nei modi pi` vari, fisicamente (wiretapping) o a lunghe distanze. Con-
u
tromisure tipiche risiedono nell’utilizzo di tecnologie crittografiche, applicate
a uno o pi` layer del protocollo TCP/IP (data-link, network e/o transport
u
nella maggioranza dei casi).

18. 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 pi` note ed eleganti descritte in letteratura. Ad esempio i cosiddetti
u
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’integrit` dei dati tramite operazioni di parsing
a
degli input e monitoraggio dei files sensibili.
Con spoofing si intendono tutte le attivit` volte al mascheramento della
a
propria identit` con lo scopo di aggirare i controlli preposti a garantire con-
a
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 ` prono a raggiri causati da scarsa competenza
e
o ingenuit`; come una robusta cassaforte ` un debole palliativo per un ladro
a e
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 realt` `
ae
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.

19. 1.5 Obscurity versus full disclosure 9
Ostacolare queste minacce ` particolarmente complicato e prevede sostan-
e
zialmente la capacit` di assicurare efficaci servizi di autenticazione, tanto nel
a
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 quantit` di traffico ingestibili,
a
spesso ricorrendo all’utilizzo di insiemi di host gi` violati (gergalmente mac-
a
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
sar` sempre superiormente limitata.
a
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 ` una corrente di pensiero basata sul princi-
e
pio di segretezza, in termini di design, implementazione e manutenzione del
software: le vulnerabilit`, eventuali o realmente esistenti, non sono divulgate
a
al pubblico nella speranza che gli aggressori non ne giungano a conoscenza.
Questa convinzione, notoriamente smentita dai fatti, ` abitualmente applica-
e
ta in ambito commerciale e militare ma aspramente criticata dalla comunit`
a
open-source che la ritiene una comoda scusante ai tempi spesso intollerabili
di aggiornamento e revisione del software.
Contrapposta alla precedente, full disclosure ` una diffusa metodologia
e
che richiede la completa divulgazione al pubblico di ogni vulnerabilit`, in-
a
clusi i dettagli per la rilevazione e l’exploit della stessa. La teoria fondante

20. 10 Cenni di sicurezza dell’informazione
prevede che questo atteggiamento porti a correzioni pi` repentine perch´ gli
u e
autori del software sono costretti a rispondere celeramente per mantenere la
credibilit` del proprio prodotto; ci` generalmente riduce la finestra di espo-
a o
sizione all’attacco.
L’origine risale formalmente ad un articolo del 1853 [10], a cura di A. C.
Hobbs, sull’opportunit` che i difetti delle serrature rimanessero confinati alla
a
comunit` dei fabbri. Da allora numerosi sono stati i consensi; in particolare
a
nel campo della crittografia il concetto ` riassunto nella legge di Kerckhoffs.
e
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 vulnerabilit` solo a correzione avvenuta e comunque
a
non oltre un tempo massimo di quindici-trenta giorni.
Questa modalit` di procedere non ` tuttavia esente da critiche; in par-
a e
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.

21. Capitolo 2
Soluzioni di rete tradizionali
Nella teoria classica sono state fornite molteplici e pi` o meno valide soluzioni
u
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 difficolt`.
a
2.1 Firewall
In una prima affrettata descrizione, un firewall ` semplicemente un siste-
e
ma hardware o software capace di filtrare il traffico di rete; in realt` que-
a
sti apparecchi si sono gradualmente sviluppati sino a comprendere gli strati
applicativi superiori al livello di trasporto.
La nozione di firewall ` ufficializzata in un documento del 1988 redatto
e
presso la Digital Equipment Corporation (DEC) [11] in cui ` illustrato un
e
primitivo analizzatore di pacchetti; questo rudimentale programma limitava
le proprie considerazioni all’indirizzo sorgente e destinazione, al protocollo e
alla porta associata, cio` ai dati ottenibili ispezionando il singolo pacchetto.
e

22. 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 abilit` identifica i sistemi stateful, frutto della collabora-
a
zione di Dave Presetto, Howard Trickey, e Kshitij Nigam presso gli AT&T
Bell Laboratories. La seconda generazione ` idonea a prevenire maggior tipo-
e
logie d’attacco proprio in virt` della possibilit` di analizzare le connessioni
u a
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, ` rilevabile solo a patto di
e
mantenere traccia dello stato del traffico di rete.
Verso la met` del 1991 Marcus Ranum concretizz` i suoi studi teorici,
a o
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 pi` complessi e mirati attacchi e/o abusi; inoltre queste
u
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 pi` diffusa e classica
u
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.

23. 2.1 Firewall 13
La suddivisione non ` solo una pratica utile per separare entit` concet-
e a
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 pu` accettare richieste e stabilire connessioni
o
in entrambi i versi, la rete interna ` totalmente schermata e irraggiungibile
e
sia dall’esterno sia dalla DMZ stessa, a tutelare che eventuali vulnerabilit` di
a
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, ` esportabile e scalabile a esigenze notevolmente pi`
e u
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.

24. 14 Soluzioni di rete tradizionali
2.2 Intrusion Detection System
Nella sez. 1.3 abbiamo assiomaticamente stabilito l’impossibilit` di garanti-
a
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 realt` presen-
a
ta molteplici difficolt` realizzative. Infatti se un aggressore ottiene privilegi
a
di tipo amministrativo ` tipicamente in grado, a meno di stringenti politiche
e
MAC-RBAC, di aggirare, sospendere e alterare l’attivit` di qualsiasi proces-
a
so di controllo e registrazione degli eventi al fine di mascherare le proprie
tracce.
Partendo da questa assunzione, gli IDS sviluppano la propria attivit`
a
cercando di rispondere alle domande
Cosa cerchi di fare? Perch´?
e
in maniera complementare a quanto evidenziato dal paradigma C.I.A. Ci` `
oe
possibile ipotizzando che il comportamento di un intruso differisca sensibil-
mente rispetto a quello degli utenti autorizzati; ` ovviamente una discutibile
e
semplificazione ma i dati sperimentali permettono generalmente di avallarla.
Una nota prima di proseguire: un IDS non sostituisce i precedenti processi
di sicurezza ma ` piuttosto adibito a scoprire un loro fallimento. Questa preci-
e
sazione, ripresa con varie modalit` in qualunque testo, vuole essere un monito
a
a tutti quegli impreparati addetti ai lavori che svolgono con superficialit` la
a
loro mansione.

25. 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 pi` comuni generalizzazioni distingue tra due macro categorie,
u
misuse-based e anomaly-based detection.
Un approccio misuse-based, similarmente ai software antivirus, indivi-
dua le attivit` sospette tramite il confronto con un catalogo preesistente di
a
signatures, associate ad attacchi di cui si conoscono pattern caratteristici e
costanti. Questo correla l’abilit` di riconoscimento e il numero di falsi positivi
a
(allarmi generati in reazione ad azioni lecite) alla qualit` e alla tempestivit`
a a
degli aggiornamenti delle signatures stesse. Il principale svantaggio `, vice-
e
versa, l’incapacit` di rilevare aggressioni realizzate con tecniche sconosciute
a
o di cui ancora non si ` definita una impronta.
e
Una soluzione anomaly-based, al contrario, basa la propria efficacia su
considerazioni di tipo statistico, riportando all’attenzione dell’amministrato-
re le attivit` che non rientrano nel normale atteggiamento degli utenti sot-
a
toposti a controllo. Sebbene ci` permetta di rilevare anche attacchi ancora
o
sconosciuti e non necessiti di continui aggiornamenti, ` fondamentale formu-
e
lare correttamente il modello comportamentale e sottoporrlo a lunghe fasi
di apprendimento. Inoltre tali sistemi sono tragicamente propensi a fornire
enormi quantit` di falsi positivi.
a
A causa della difficolt` nel definire modelli sufficientemente generali gli
a
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.

26. 16 Soluzioni di rete tradizionali
Un ulteriore importante modalit` di differenziazione ` tra IDS host-
a e
based e network-based.
I sistemi host-based sono adibiti al controllo di una singola postazione e
tipicamente realizzano le proprie funzionalit` attraverso i servizi di monito-
a
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 pi` sottoreti, catturando e analizzando i flussi di pacchetti tramite
u
l’utilizzo di sniffer. Il pi` immediato vantaggio ` la possibilit` di proteggere
u e a
con relativamente pochi dispositivi, o sensori, anche reti decisamente ampie.
In aggiunta lo sniffer opera passivamente, impostando la scheda di rete in
una particolare modalit` detta promiscua che ne disabilita le capacit` di tra-
a a
smissione; questo ne rende estremamente difficile, sebbene non impossibile, il
rilevamento a soggetti esterni. D’altro canto questa soluzione ` inefficacie in
e
praticamente tutti gli attacchi inseriti in un contesto crittografico (ad esem-
pio tramite HTTPS o VPN) in quanto il traffico coinvolto non pu` essere
o
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 pi` server centrali adibiti alla correlazione e valutazione. Torneremo a
u
considerare questo approccio nel corso del capitolo 4.

27. 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 ci` ` condivisibile, in quanto mantiene inalterato il con-
oe
cetto di controllo riducendo la necessit` di interventi umani, questo modello
a
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 necessit` di esaminare
a
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 ` il comparto
e
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 staticit`
a
della rete; questa considerazione, unita all’ipotesi di delimitazione fisica
del mezzo di trasmissione, costituisce la causa primaria dell’incapacit` degli
a
strumenti classici ad adattarsi e sopravvivere autonomanente in ambienti
wireless. Approfondiremo in dettaglio l’argomento nel capitolo 4.

28. 18 Soluzioni di rete tradizionali

29. 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 ` costellato di molteplici e spesso radicali cambiamenti;
e
modalit` di trasmissione, frequenza e implementazione delle procedure di
a
sicurezza rappresentano gli esempi pi` ecclatanti.
u
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 vulnerabilit` e, laddove giusti-
a
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.
ı

30. 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 ` gratuita. A memoria, nessun’altro
e
standard ` stato vittima di una quantit` di falle cos` gravi da essere sosti-
e a ı
tuito e deprecato dopo pochi anni dalla sua introduzione. Simili episodi non
possono essere commentati come “casuali fatalit`”. Sperando costituiscano
a
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

31. 3.1 Wired Equivalent Privacy 21
sull’algoritmo RC4, originariamente ideato da Ron Rivest nel 1987; RC4 ` il
e
pi` famoso e utilizzato stream cipher, un generatore di sequenze pseudoca-
u
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’integrit`. Il vettore IV ` infine allegato in chiaro al payload cifrato, per
a e
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 vulnerabilit`, esemplifica-
a
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 ` mediamente saturabile in 6-12 ore; si noti inoltre come il
e
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] dimostr` come un even-
o
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
ı
abilit` a RC4, affetto da forte low sampling resistance (definito da Biryukov,
a
Shamir e Wagner in [16]) cio` uno stretto legame tra alcune classi di input e
e
i corrispettivi pattern di output.

32. 22 Tecnologie di protezione per reti wireless 802.11
Figura 3.2: Vulnerabilit` WEP [14]
a
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 interoperabilit` con
a
gli apparecchi gi` in commercio e la sostanziale inefficacia della soluzione
a
[17] hanno presto sconfessato tale pratica. Attualmente, difatti, la quantit`
a
di informazioni per eseguire un attacco e il tempo necessario ad ottenerle
dipende piuttosto dalle capacit` dell’aggressore che dalla dimensione della
a
chiave WEP; studi recenti [18] evidenziano WEP128 decifrate in meno di
sessanta secondi.
La seconda principale preoccupazione riguarda l’integrit` del messaggio.
a
Il checksum CRC32 accodato al payload ` concepito per rilevare errori casuali
e
di comunicazione e non manomissioni intenzionali; ne deriva che alterazioni
apportate sia ai dati che al corrispondente checksum non sono accertabili.

33. 3.2 Temporal Key Integrity Protocol 23
Un aggressore esperto, anche sprovvisto della chiave, pu` dunque iniettare
o
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 perci` insicuro. Il protocollo WEP fallisce tutti i suoi
o
propositi.
Sebbene tutti gli esperti concordino sulla sua inadeguatezza, WEP `
e
tutt’oggi ancora largamente utilizzato. Tale affermazione sar` verificata
a
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
comunit` IT; gli utilizzatori necessitavano rapidamente un successore che non
a
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 integrit` (MIC).
a
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 gi` esistenti,
a
` suddiviso in due fasi. Tramite una Sostitution Box (S-box, una tabella di
e
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 pi` significativi del vettore IV; la dipendenza dal MAC address locale
u
ha l’immediato apprezzabile vantaggio di produrre valori differenti per ogni

34. 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’integrit` dell’informazione affidandosi a MIC (Message Integrity Check,
a
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 ` per` decisamente pi` costoso
e o u
in termini di cicli di calcolo, tanto da degradare sensibilmente le prestazio-
ni degli access point pi` economici; buon compromesso per il riutilizzo di
u
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, rilasci` verso
o
la met` del 2003 una serie di raccomandazioni per un nuovo protocollo ba-
a
sato sulle proposte, allora ancora abbozzate, del futuro IEEE 802.11i. Oggi
conosciuto come WPA (Wi-Fi Protected Access), ` sostanzialmente un’e-
e
stensione dell’architettura WEP realizzata tramite TKIP e MIC che offre,
in aggiunta, funzionalit` di autenticazione e distribuzione delle chiavi; l’im-
a
plementazione di quest’ultimo fattore discrimina tra le due diverse modalit`
a

35. 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 ` ottenuta la chiave TK necessaria a TKIP.
e
Disgraziatamente la PTK ` scambiata nel secondo pacchetto dell’handshake
e
a quattro vie eseguito in fase di associazione e se intercettata diviene suscet-
tibile ad attacchi a dizionario [19], assai pericolosi perch´ effettuabili anche
e

36. 26 Tecnologie di protezione per reti wireless 802.11
off-line. Oltretutto un aggressore pu` facilmente forzare la ri-associazione dei
o
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, ci` conduce ad attacchi DOS teoricamente permanenti.
o
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 pi` comuni. Numerosi break-test dimostrano incrementi di velocit`
u a
nella ricerca della PSK nell’ordine di 104 .
La modalit` enterprise, viceversa, presuppone una struttura RSN (Ro-
a
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 ` assicurata dal framework EAP, in
e
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-

37. 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 modalit` enterprise offra un grado di sicurezza molto elevato,
a
i costi e le complessit` legate all’utilizzo di un server RADIUS ne hanno
a
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, ` stato finalmente rila-
e
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 retrocompatibilit` con i dispositivi WPA e prevede, inoltre, una modalit`
a a
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 ` un sofisticato block-
e
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

38. 28 Tecnologie di protezione per reti wireless 802.11
denotate assieme come CCM.
Analogalmente a TKIP, il Counter Mode ` basato su un vettore IV di
e
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 integrit`.
a
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 complessit` computazionale della cifratura
a
AES. Giovano pertanto le stesse raccomandazioni espresse in precedenza.
CCMP, con la sua elegante e robusta struttura, ` attualmente considerato
e
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
Integrit` header
a No Michael CBC-MAC
Integrit` dati
a CRC32 Michael + CRC32 CBC-MAC
Distribuzione chiavi No 802.1X (EAP) 802.1X (EAP)
Tabella 3.1: Standard di sicurezza 802.11

39. 3.5 Sviluppi futuri: 802.11w 29
3.5 Sviluppi futuri: 802.11w
Tutti i precedenti protocolli forniscono, in maniera pi` o meno valida, un sup-
u
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 introdurr` tre diversi meccanismi di sicurezza
a
[26]. Il primo estender` l’utilizzo degli algoritmi TKIP/CCM anche ai ma-
a
nagement frame trasmessi in modalit` unicast, cio` tra un solo client e un
a e
access point, garantendone confidentiality e integrity. Il secondo, viceversa,
sar` riservato ai frame broadcast ed usufruir` di un controllo d’integrit` MIC
a a a
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’autenticit` dei messaggi di disassociazione e deautenticazione. In ogni caso,
a
il funzionamento di tali tecniche presuppone che il client e l’access point ab-
biano gi` scambiato una PTK e, pertanto, 802.11w non eliminer` le tematiche
a a
relative all’intercettazione e al cracking delle password WPA/WPA2.
Queste novit`, teoricamente, richiederanno solamente un aggiornamento
a
del firmware dei dispostivi.

40. 30 Tecnologie di protezione per reti wireless 802.11
3.6 Caso di studio: WLAN citt` di Cesena
a
Analizzati gli standard di sicurezza offerti dal mercato, ` lecito e interessante
e
domandarsi quali di questi siano effettivamente utilizzati. Come caso di
studio abbiamo investigato 240 reti WLAN della citt` di Cesena nell’area
a
attorno alle due sedi della Seconda Facolt` di Ingegneria dell’Universit` di
a a
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.

41. 3.6 Caso di studio: WLAN citt` di Cesena
a 31
Figura 3.5: Stato delle reti WLAN nella citt` di Cesena
a

42. 32 Tecnologie di protezione per reti wireless 802.11

43. Capitolo 4
Wireless IDS
Abbiamo gi` notato che il protocollo CCMP, specialmente nella variante en-
a
terprise, ` pi` che idoneo a garantire sia le autenticazioni sia le comunicazioni
e u
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 gi` vaste tecniche di attacco in direzio-
a
ni ortogonali a quelle risolte con l’adozione di un canale crittograficamente
sicuro.
In questa fase ` fondamentale ricordare che seppure consapevoli di non
e
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.

44. 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, per`, ` indiscutibilmente
o e
distribuito e oltremodo variabile nel tempo. In conseguenza un’impostazione
host based o in ogni caso prettamente off-line ` inefficace nel confrontarsi con
e
le sfide proposte. Queste considerazioni hanno condotto, quasi unicamente,
allo sviluppo di architetture basate sulla collaborazione tra sensori e uno o
pi` server di analisi (vd. Figura 4.1).
u
Figura 4.1: Struttura Wireless IDS
4.1.1 Reti di sensori
Un sensore WLAN `, sostanzialmente, uno sniffer idoneo a catturare frame
e
802.11. In particolare ` necessaria una modalit` speciale chiamata moni-
e a

45. 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 ` associati, includendo oltretutto gli header
e
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 pi` o meno sofisticate per Linux e, in modo minore, per BSD e MAC
u
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
funzionalit` degrada le performance della rete e dunque il throughput di en-
a
trambe le operazioni. Assai pi` critico ` il secondo aspetto: unire un servizio
u e
con i propri meccanismi di controllo ` tipicamente una pessima decisione in
e
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 ` sconsigliabile.
e
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 ` molto vasta ed il numero di dispositivi necessari ` elevato. Questa
e e
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 pi` efficace ed evoluta, priva delle debolezze sopra elencate. Con-
u
trariamente ai precedenti, effettuano delle operazioni di scrematura sui dati

46. 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 complessit` interna del dispositivo. Gli elevatissimi costi,
a
tuttavia, hanno relegato questi prodotti a mercati di nicchia in cui il numero
di sensori ` limitato e, in ogni caso, la spesa ` un fattore secondario.
e e
Trascurando i sistemi integrati, l’aspetto cruciale che determina il suc-
cesso o, viceversa, il fallimento di un WIDS ` l’ubicazione dei sensori. Il
e
suggerimento pi` comune, indubbiamente errato, ne prevede la collocazio-
u
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 pi` ampia
u
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

47. 4.1 Architettura 37
Interferendo con un segnale pi` intenso, l’intruso induce un client ad
u
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 pu`
o
rilevare n´ la presenza dell’intruso, magari distante e appostato in auto, n´
e e
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 pi` server adibiti alle successive operazioni di controllo.
u
Il collegamento pu` essere stabilito tramite la rete cablata o per mezzo della
o
WLAN stessa: la rete cablata garantisce performance e sicurezza maggiori
ma impone la disponibilit` di prese ethernet attigue ai sensori, vincolandone
a
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 pi` facilmente ad
u
interferenze e denial of service. In ogni caso ` imprescindibile adoperarsi per
e
autenticare e cifrare tutte le trasmissioni utilizzando protocolli notoriamente
“sicuri” quali SSL3/TLS. Inoltre ` opportuno impedire ai sensori di stabilire
e
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

48. 38 Wireless IDS
ma innanzitutto per relazionare le informazioni ricevute dai diversi sensori.
Questo permette, ad esempio, di eliminare i duplicati e non notificare pi`
u
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 pi` complete, inoltre, prevedono la possibilit` di connettere in cascata
u a
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 funzionalit`
a
prettamente misuse-based con basse, o nulle, capacit` anomaly-based. Nel-
a
la sezione 4.2 approfondiremo in dettaglio diverse signatures comunemente
utilizzate e proporremo alcuni spunti per nuovi algoritmi anomaly-based.
Lo stadio di notifica ` preposto ad avvisare l’amministratore generando
e
un alert quando l’analisi riscontra un probabile attacco. Il componente di
notifica non ` un passivo segnalatore di eventi ma, al contrario, ` preposto
e e
ad organizzare tempestivamente gli alert distribuendoli, in base alla loro
priorit`, tra diversi mezzi di comunicazione quali SMS, e-mail, console e
a
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
popolarit` di un prodotto ` fortemente condizionata dall’esistenza di un’in-
a e

49. 4.1 Architettura 39
terfaccia efficiente e soprattutto intuitiva, pertanto ` compito del progettista
e
presentare le informazioni in modo chiaro e ordinato, suddividendole in classi
concettuali. Gli alert, ad esempio, dovrebbero essere ordinati per gravit` e
a
tipologia e, inoltre, opportunamente riassunti per consentirne una pi` rapida
u
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 praticit` e portabilit` sia per fenomeni di moda e tendenza, sfruttano
a a
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 perci` propense ad attacchi volti a compromettere il
o
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:

50. 40 Wireless IDS
’; drop table ...;--
Se l’anomalia non ` opportunamente gestita in fase di analisi, la query adibita
e
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 ` stato incautamente incluso il seguente codice malevolo,
e
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 vulnerabilit`, tipiche di un’implemen-
a
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 pi` note metodologie d’attacco
u
ai sistemi WLAN, delineandone parallelamente possibili contromisure non
necessariamente adottate dai WIDS esistenti.
4.2.1 Sniffer e wardriving
Abbiamo gi` brevemente discusso il termine sniffing in sez. 1.4. Un ambien-
a
te wireless, tuttavia, espande indefinitamente le potenzialit` di tale tecnica,
a

51. 4.2 Attacchi e contromisure 41
tanto da imporre una ritrattazione pi` approfondita e mirata. Ovviamente
u
` lecito domandarsi quale motivo promuova tale scelta: il comune atteggia-
e
mento di ogni aggressore in procinto di attaccare una rete a lui sconosciuta
` senza dubbio la migliore giustificazione. Chiunque abbia un minimo di
e
esperienza, difatti, svolge una pi` o meno lunga fase di preparazione detta
u
information gathering in cui cerca di conoscere quanti pi` dettagli pos-
u
sibile sull’obiettivo; questa attivit` trascende sia dalle tecnologie (vd. social
a
engineering in sez. 1.4) sia dal settore informatico ed ` applicato in campo
e
militare, intelligence, marketing e molti altri.
In realt`, introducendo i sensori e la modalit` RFMON, abbiamo gi` an-
a a a
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 ` inequivocabilmente il principale svantaggio rispetto ai nostri
e
ostili rivali: non possiamo, in generale [29], localizzare un intruso fintanto
che permane in una modalit` passiva come RFMON. Ovviamente se in un
a
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 perch´ i sistemi Windows non supportano nativamente la
e
modalit` monitor.
a
In ogni caso, negli anni, l’idea di identificare reti WLAN si ` sviluppata
e
come una vera e propria moda detta wardriving; tale fenomeno, non ri-
chiendo n´ particolari competenze tecniche n´ hardware specifico (un PDA
e e
o un portatile), ` solitamente perpetrata per hobby, studio o per connetter-
e
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 ` un esempio di wardriving realizzato abbinando
e
a Kismet un’antenna GPS e le Google Maps API [30].

52. 42 Wireless IDS
Nonostante il wardriving non costituisca un vero e proprio attacco, e pi`
u
in generale nemmeno un reato (vd. appendice B), siamo comunque interessa-
ti a monitorarne l’attivit` in quanto rappresenta una potenziale minaccia alla
a
sicurezza della nostra rete. Purtroppo, come gi` evidenziato, dovremo limi-
a
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 ` verosimilmente lo strumento pi` popolare e adoperato tra gli
e u
amanti del wardriving; disponibile per Windows 2000/XP e CE, ` caratte-
e
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 modalit`
a
broadcast: ci` ` perfettamente conforme alle specifiche IEEE 802.11, pertan-
oe
to ` difficile individuare un tentativo di scansione. Fortunatamente alcune
e
versioni di NetStumbler (0.3.20∼0.3.30), ogni volta che rilevano un nuovo
access point, inviano un ulteriore frame il cui pattern ` stato ampiamente
e
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 `, perci`, relativamente facile; ad esempio
e o

53. 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) ` insensibile a questi
e
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 velocit` di spostamento. Stabilita una soglia massima
a
abbiamo introdotto una semplice regola per discriminare un wardriver dai
clients legittimi. Tuttavia questa tecnica presuppone la capacit` di localiz-
a
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 autenticit` di un indirizzo ` estremamente arduo e, pi`
a e u
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

54. 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 ` di
e
dominio pubblico, pu` dissuadere solo soggetti molto inesperti.
o
Un metodo nettamente migliore, descritto in [32], ` basato sull’analisi del
e
sequence number, un campo del protocollo 802.11 utilizzato come conta-
tore per ordinare il flusso dei frame. Controllandone la sequenza il sistema
pu` identificare valori fuori scala, pertanto prodotti da una diversa fonte:
o
ad esempio se un sensore cattura la serie 1920-1921-232-1923 ` altamente
e
probabile che il terzo pacchetto sia stato trasmesso da un intruso in fase di
spoofing. Questa tecnica ` molto raffinata ma tuttavia infrangibile trami-
e
te alcuni driver con funzionalit` avanzate di injection che alterano in modo
a
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 pi` blasonato FakeAP.
u
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 capacit` di riconoscimento del nostro WIDS.
a
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 ` generato un alert. In ogni caso questo procedimento, oltre a degradare
e
le performance della rete, obbliga a mantenere costantemente aggiornate le
informazioni del database.
Osservazioni pi` utili possono essere nuovamente ricavate dalle coordi-
u
nate GPS dell’host. Ad esempio se la nostra policy di sicurezza disciplina
gli ambienti in cui ` permesso il collegamento WLAN potremmo ritenere so-
e
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

55. 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 ` tipicamente gestito tramite l’utilizzo di due liste di
e
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 perch´ rilevati dai senso-
e
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 gi`,
a
in parte, introdotto le immense potenzialit` di questi attacchi che, di fatto,
a
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-

56. 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 abiliter` il fiammante iPod
a
touch appena acquistato a scaricare MP3 sfruttando la veloce rete azien-
dale; decisamente non ` un gran lavoratore ma non ` il suo rendimento a
e e
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 pu` liberamente entrare nella rete locale,
o
supposta sicura nella suddivisione DMZ, evitando tutti i sistemi di controllo
tradizionali quali firewall e IDS.
Al lettore attento non sar` sfuggito un tragico particolare: nel nostro
a
esempio non ` specificato che l’azienda possega una preesistente WLAN ma
e
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 pu` garantire un minimale livello di sicurezza senza adottare
o

57. 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
` decisamente semplice; difatti, in modo simile ai rogue clients, ` sufficiente
e e
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 difficolt` esposte in sez. 4.1 e comporta,
a
sostanzialmente, una disposizione accurata e previdente dei sensori in tutte
le aree potenzialmente critiche. Inoltre ` consigliabile eseguire un wardri-
e
ving nella zona circostante il proprio edificio e annotare in una lista “known
but not ours list” gli access point delle reti vicini. Ci` evita la generazione
o
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 sar` soggetto a notifiche.
a
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 pi`
u
comuni.
Injection e flooding
Il modo pi` semplice per causare un DOS ` sicuramente un flood, una ge-
u e
nerazione continua di frame tramite script di injection atta a saturare il
canale; in realt` qualunque dispositivo produca un segnale nei pressi dei 2.4
a
GHz ` sufficiente a disturbare e degradare il funzionamento di una WLAN e
e
ci` ` sostanzialmente inevitabile. In ogni caso, picchi improvvisi di traffico
oe
delineano, probabilmente, un WEP cracking piuttosto che un tentativo di
DOS.