Wireless LAN IEEE 802 - Intranet...

Stefano Zanero 1/53

Wireless LAN IEEE 802.11

Sicurezza dei protocolli wireless

Stefano Zanero – 25/04/06

Stefano Zanero 2/53

Wireless LAN: perchè?

� Indubbia facilità d’uso: consente di accedere alle risorse di rete senza essere vincolati a cavi, presenza di prese di rete… (pensate alla filosofia degli “open space” o a un’aula convegni)

� Risparmio sui costi di attivazione (niente cablaggi)� Tecnologia “di moda” (geek-effect)� Iniziano a diffondersi anche tecnologie WAN e MAN di

tipo wireless, nonché l’idea di reti pubbliche (con problemi legislativi…)

Stefano Zanero 3/53

Tecnologie Wireless

PAN(Personal Area Net.)

LAN(Local Area Network)

WAN(Wide Area Network)

MAN(Metropolitan Area Network)

PDAs, Mobile Phones, cellular

access

T1 replacement, last mile access

Enterprise networks

Peer-to-PeerDevice-to-Device

Applicazioni

LongMedium-LongMediumShortRaggio

10 to 384Kbps11 to 100+ Mbps11 to 54 Mbps< 1MbpsData rate

GSM, GPRS,CDMA, 2.5-3G

802.11MMDS, LMDS

802.11HiperLAN2

BluetoothStandard

WANMANLANPAN

Stefano Zanero 4/53

Wireless LAN: gli standard

� IEEE 802.11: 1997, interoperabilità tra reti “wired”(ethernet) e wireless, 1-2Mbps

� Le reti 802.11 usano gli stessi protocolli per:– Media Access Control (MAC) – Carrier Sense Multiple Access with Collision Avoidance

(CSMA/CA)

� 802.11a: 1999, banda 5GHz, codifica OFDM, fino a 54Mbps

� 802.11b: 1999, banda 2,4 GHz, codifica DSSS, 11 Mbps� 802.11g: 2001, banda 2,4 Ghz, codifica OFDM/CCK in

crescita

Stefano Zanero 5/53

IEEE 802.11b

� Prevede l’uso di fino a 14 canali per evitare interferenze tra reti diverse, ma reti multiple con SSID (Service Set ID) diversi possono coesistere sullo stesso canale

� Il canale è condiviso (come in rete su hub)� Modalità infrastrutturale (con access point,

possibile roaming e bridging) oppure ad-hoc� Raggio 100 metri outdoor, 50 indoor

Stefano Zanero 6/53

Problematiche di sicurezza

� Il rischio per una rete wireless è dato da: rischi normali di una rete “wired” + rischi intrinseci ai protocolli wireless.

� Il rischio intrinseco principale deriva dalla natura del mezzo trasmissivo (onde radio), che per sua natura non è confinabile.

� Tutto ciò che viene trasmesso può essere “sniffato”: serve una protezione crittografica forte.

� In mancanza di mezzi di autenticazione affidabili, il wireless puòrendere possibile l’accesso alle reti protette da firewall, consentendo di bypassare la protezione offerta da questo (è come mettere una presa di rete direttamente in strada !).

� Esistono concreti rischi di attacchi Denial of Service contro gli apparati wireless, sia operati a livello radio che a livello di protocollo.

Stefano Zanero 7/53

Requisiti di sicurezza

� Nell’elaborazione dello standard IEEE 802.11b sono stati presi in considerazione tre requisiti di sicurezza:

– Autenticazione dei client e controllo dell’accesso alle risorse– Confidenzialità dei dati trasmessi– Integrità dei dati, che non devono essere modificati

� Lo standard prevede che questi requisiti debbano essere “almeno equivalenti” a quelli di una rete wired

� Questo livello di sicurezza avrebbe dovuto essere garantito dal protocollo WEP (Wired Equivalent Privacy).

Stefano Zanero 8/53

Protocolli di sicurezza wireless

Schemi di autenticazione e di crittografia possibili:

� Nessuno� WEP (Wired Equivalent Privacy – contenuto in

802.11b)� EAP (Extensible Authentication Protocol –

802.1x), in diverse varianti� 802.11i (TKIP-MIC)

Stefano Zanero 9/53

Open Authentication

� Soluzione semplice, creiamo una rete totalmente aperta

� Facilità di configurazione (out of the box): molti venditori di hardware usano questa configurazione di default per semplicità.

� Interoperabilità massima� Performance massima (difficile pensare di cifrare

54Mbps a 128bit)� Purtroppo, nessuna sicurezza!� Può andare bene per una rete di una sala congresso

ad esempio (come al DEI)

Stefano Zanero 10/53

Wired Equivalent Privacy

� Il WEP è un algoritmo a base criptografica, che cerca di garantire autenticazione, integritàe confidenzialità.

� Si basa su una “chiave condivisa” (shared key) che deve essere conosciuta dall’Access Point e dai client, con tutte le difficoltà tipiche.

� Si basa sull’algoritmo RC4 (uno “stream cipher”) di Ron Rivest, protetto come trade secret da RSA security dal 1987 fino al 1994 quando “qualcuno” lo ha postato su internet


Stream Cipher (CFB)

� Non cifriamo per blocchi, ma facciamo uno XOR bit-a-bit tra plaintext e sequenza pseudocasuale generata da chiave

� A destinazione viceversa, XOR


WEP: dettagli algoritmici

Layer 3 (header + dati)Header 802.11

Header 802.11

Layer 3 (header + dati)

CRC-32

RC4

Integrity check

ChiaveIV

IV Cyphertext

Stream cipher: il flusso di byte segreti dipende da segreto non da plaintext


WEP: dettagli che contano

� Stream cipher in modo CFB: problema generico di questo tipo di algoritmi è che dipendono solo da chiave e posizione; quindi:– Plain Text uguali, Cipher Text uguali – key stream identico a parità di segreto (anche per

plain text diversi)

� Per mitigare questo problema, si usa un Initialization Vector (IV) di 24 bit, che si combina con la chiave (di 40 o 104 bit) e viene pretrasmesso in chiaro


Un protocollo nato male

� RC4 è esportabile “facilmente” solo nella versione a 40+24 bit (per accordi con tra RSA e NSA sotto l’ITAR), quindi la versione a 104+24 bit di WEP è stata standardizzata in ritardo

� Lo standard 802.11b come funzione MIC (Message Integrity Code) il CRC-32, che èdistributivo rispetto allo XOR: CRC(A xor B) = CRC(A) xor CRC(B)

� RC4 usa proprio xor per criptare !


Una sequenza di problemi (1)

� Nel 2000, J. Walker studia il riuso degli IV in WEP– Lo spazio è piccolo (224) e quindi c’è alta

probabilità di riutilizzo– Access point che si sovrappongono con lo

stesso meccanismo di generazione di IV possono esaurirlo rapidamente

– Se cercano di dividersi lo spazio, la situazione peggiora!



� Nel 2001 Borisov, Goldberg e Wagner estendono i risultati di Walker per creare attacchi pratici sul reuse

� Inoltre, descrivono un metodo per cambiare bit arbitrari di un messaggio criptato senza conoscere la chiave, utilizzando la distributività del CRC rispetto allo XOR

� Questo pericoloso attacco all’integritàdipende dalla mancanza di una chiave di firma nel MIC



� Pochi mesi dopo, W. Arbaugh utilizza il metodo per un attacco che permette di recuperare il key stream (non la chiave) estendendolo byte per byte:

– Supponiamo di aver riconosciuto n byte criptati (per esempio, una richiesta DHCP)

– Possiamo da ciò dedurre n byte del key stream– Con n byte di key stream possiamo iniettare messaggi

arbitrari di lunghezza (n-4)– Generiamo un messaggio di lunghezza (n-3) che se ricevuto

genera una risposta (ping?)– Proviamo a criptarlo con gli n byte della chiave + un “guess”

per l’ultimo byte– Se riceviamo risposta è giusto



� L’attacco di Walker dimostra l’insufficienza anche teorica del concetto di IV

� L’attacco di Borisov-Goldberg-Wagner dimostra che l’integrità non è garantita nemmeno se l’attaccante non conosce il key stream

� L’attacco di Arbaugh consente di recuperare il key stream, e di costruire un dizionario sui vari IV, ma richiede tempo (media 18h, pessimo 55h) e spazio (ordine dei GB). È un attacco attivo, cioè richiede di trasmettere pacchetti

� Nessuno degli attacchi compromette la chiave WEP


Il colpo di grazia

� Poco dopo, Fluhrer, Shamir e Mantin pubblicano un articolo sulle vulnerabilità di RC4

� Sviluppano un attacco probabilistico passivo che consente di estrarre informazioni sulla chiave dal key stream

� L’attacco funziona se RC4 viene usato con una chiave costante + una serie di byte variabili e esposti: esattamente il caso di WEP !

� Usa una classe di IV “deboli”


Implementazioni pratiche

� Stubblefield, Ioannidis e Rubin (ma anche Hulton e altri) usano questo attacco contro WEP

� Serve un volume sufficiente di traffico, circa 5mln di pacchetti (su una rete utilizzata puòbastare qualche ora a raccoglierli), ma con ottimizzazioni anche 1mln

� Bastano poi pochi secondi a rompere la chiave� L’attacco non richiede l’emissione di pacchetti,

è completamente silenzioso


Tool

� AirSnorthttp://airsnort.shmoo.com/

� Funziona con schede Orinoco, Prism2, Cisco� Implementazione dell’attacco come descritto

da Stubblefield et al. (ma il codice non è il loro)

� Esiste anche WepCrack:http://sourceforge.net/projects/wepcrack


Screenshot di AirSnort


Altri tool utili

� wavemon per rivelare l’intensità e la direzione del segnale wirelesshttp://www.wavemage.com/projects.html

� kismet per individuare con comodità le reti esistenti, verificare se sono protette da WEP o meno e scoprirne il SSIDhttp://www.kismetwireless.net/

� airtraf è un ottimo tool, un tempo free (http://airtraf.sourceforge.net/download.php). Ora è open source ma commerciale (http://www.elixar.com/products/airtraf_download.html)


Wardriving applied

� Ingredienti:– Un’automobile (consigliate 2 persone, uno guida e

l’altro guarda il portatile)– Un portatile o un palmare– Una scheda wireless– Kismet o airtraf (NetStumbler per Win,

MacStumbler per Mac)– (opzionale) un GPS– (opzionale) un’antenna omnidirezionale– (opzionale) un’antenna direzionale– (opzionale) un’inverter


Wardriving: strumenti


Wardriving: risultati

� Risultati: se fate un giro per il quadrilatero milanese, in 20 minuti di guida rileverete 15-20 reti wireless, di cui 5 al massimo “protette” da WEP (e quindi non protette affatto)

� Ricordate: il wardriving non è un reato, ma il collegamento a una rete wireless altrui sì (art. 615/ter c.p.)


Wardriving: risultati (2)

� Da una serie di ricerche effettuate a Londra (RSA Security, INSTIS e Z/Yem Ltd.)

� RSA nel 2002 ha anche notato 522 access card, e 120 degli access point che erano configurati di “default”

n.a.100~85n.a.Leaking7121078

RSA11/03

122131~80Con WEP328 (264)185124AP (Reti)

RSA 11/02

INSTIS 04/02

RSA 09/01


Tendenza

0

200

400

600

800

1000

1200

RSA

09/01

INSTIS

04/02

RSA

11/02

RSA

11/03

AP totali

Con WEP


Suggerimenti per la sicurezza

� Una rete protetta da WEP non può essere resa sicura al 100%

� Possiamo però indicare alcuni “palliativi”– Usare il WEP a 128bit: almeno vi difenderete dall’attaccante

“casuale” o che vuole solo navigare a scrocco– SSID non prevedibile e broadcast del SSID non abilitato– filtro sui MAC address autorizzati ad associarsi

� Il consiglio base è considerare l’AP come un nodo non affidabile: posizionatelo nella DMZ ed utilizzate una VPN per accedere tramite esso alle risorse importanti


IEEE 802.1x

� .1X perché si adatta sia a reti “wired”che “wireless”

� Lo standard proposto cerca di risolvere il problema dell’autenticazione.

� Al momento integra i protocolli LEAP, EAP-TLS, EAP-TTLS e PEAP

� Utilizza il protocollo RADIUS (Remote Access Dial-In User Service)


EAP

� Extensible Authentication Protocol (RFC 2284) e’ una estensione di PPP, adottato da 802.1x

� Consente di autenticare l’utente su un server esterno (tipicamente RADIUS)

� Supporta differenti meccanismi di autenticazione (MD5, kerberos, One Time Password, smart card...)

� l’Access Point fa solo da tramite per consentire il dialogo di autenticazione

� l’autenticazione è centralizzata� Non può essere utilizzato per lo scambio di chiavi


EAP + TLS

� RFC 2716� Utilizza TLS (Transport Layer Security) e i

certificati digitali. TLS è la versione “3.1” di SSL, i due protocolli sono incompatibili ma fondamentalmente identici

� Supporta la generazione dinamica di chiavi di sessione

� L’autenticazione è mutua� Per contro richiede l’esistenza di una PKI

(Public Key Infrastructure) per i certificati


EAP + TTLS

� Tunneled Transport Layer Security: il client usa login+password inviate in un tunnel TLS per autenticarsi

� L’autenticazione è mutua perché il server usa il suo certificato digitale per identificarsi al client

� In questo caso non serve una PKI


Estensioni di EAP: LEAP/PEAP

� LEAP è una estensione proprietaria Cisco, perciò l’interoperabilità con client di altri fornitori non è garantita

� Utilizza MS-CHAPv1 per l’autenticazione� L’autenticazione è mutua� Vengono generate chiavi dinamiche legate alla

sessione� PEAP: Protected EAP, altro standard proposto

da Microsoft e Cisco, basato su CHAPv2


LEAP: meccanismo

client

APRADIUS

server

Start

identity

L’AP blocca ogni richiesta fino ad autenticazione

identity

Il server RADIUS autentica il client

Request identity

Il client RADIUS autentica il serverScambio

chiave

Scambio

chiave


Vulnerabilità di LEAP

� Rivelata a CISCO da J. Wright nell’agosto 2003� Sfrutta una debolezza del meccanismo di

challenge/response di LEAP� La debolezza deriva dall’uso di MS-CHAP, che cripta le

password senza un salt casuale� Si usa una larga lista di password per un attacco di

brute force efficiente realizzabile offline� Cisco reagisce dopo che il tool viene presentato a

Defcon 11 e conferma ai suoi clienti la vulnerabilità ma consiglia solo una “strong password policy”

� http://asleap.sourceforge.net/� Alternativa: usare PEAP o TTLS


Vulnerabilità di LEAP: dettagli

� Ci sono altri problemi in LEAP oltre all’attacco con dizionario� Username passato in chiaro� Vulnerabilità dei due byte

– La password di LEAP viene data in pasto a MD4 per generare un hash da 16 byte (NT_HASH)

– I 16 byte vengono portati a 21 aggiungendo 5 null (!!)– Il risultato viene diviso in 3 parti da 7 byte = 56 bit (come una

chiave DES)– Ogni parte viene utilizzata per cifrare un challenge e unita alle altre

(senza CBC)– Conosciamo il challenge (trasmesso in chiaro) e sappiamo che C ha

solo 2 byte variabili (5 sono NULL).– Due byte di chiave = 65k combinazioni, ovvero 1/65k del normale

keyspace: posso indovinarli– Indovinandoli riduco lo spazio delle possibili password (su un

dizionario da 2,5 milioni di password arrivo a circa 30)


IEEE 802.11i - TKIP

� Standard approvato che cerca di “aggiornare” WEP

� TKIP (Temporal Key Integrity Protocol) usa ancora RC4, ma con chiave variabile

� Le periferiche basate su WEP possono essere aggiornate mediante cambio di firmware

� Una evoluzione di 802.11i basata su AES èattesa, ma richiederà un upgrade hardware


TKIP: WEP Key Hashing

IV base key

RC4

stream cipherRC4

stream cipher

IV base key

hash

packet keyIV

WEP: senza key hashing

TKIP: key hashing


Message Integrity Check (MIC)

� MIC: Message Integrity Check, altra aggiunta di 802.11i: sostituisce CRC-32 con una funzione forte

� MIC è funzione di un seme random, dei MAC address sorgente e destinazione, e del payload

� Il MIC è nel payload crittografato

Niente MIC

MIC

DA SA IV Data ICV

DA SA IV Data SEQ MIC ICV


Wi-Fi Protected Access (WPA)

� WPA = 802.1X + TKIP� Supportato da Microsoft e Cisco� WPA è richiesto, da agosto 2003,

perchè un prodotto possa portare il marchio Wi-Fi


Bibliografia

� J. Walker, “Unsafe at any key size: an analysis of WEP encapsulation”, IEEE 802.11-00/362, IEEE Press, 2000

� N. Borisov, I. Goldberg, D. Wagner, “Intercepting mobile communications: the insecurity of 802.11”, Proc. 7th Ann. Intl. Conf. Mobile Computing and Networking, ACM Press 2001

� W. A. Arbaugh, “An inductive chosen plaintext attack against WEP/WEP2”, IEEE 802.11, Verlag, 2001

� S. Fluhrer, I. Mantin, A. Shamir, “Weaknesses in the key scheduling algorithm of RC4”, Proc. 8th Ann. Workshop Selected Areas in Cryptography, Springer 2001


Risorse web

� E. Danyelyan, “802.11”:http://www.isoc.org/pubs/int/cisco-1-1.html

� Security in Wireless Networks:http://rr.sans.org/wireless/wireless_net3.php

� Using the Fluhrer, Mantin, and Shamir Attack to Break WEP: http://www.cs.rice.edu/~astubble/papers.html

� DRAFT Special Publication 800-48, Wireless Network Security: 802.11, Bluetooth, and Handheld Devices: http://csrc.nist.gov/publications/drafts/draft-sp800-48.pdf

� A Technical Comparison of TTLS and PEAP by Matthew Gast:http://www.oreillynet.com/pub/a/wireless/2002/10/17/peap.html

� Vulnerabilità di LEAP: http://home.jwu.edu/jwright/presentations/asleap-defcon.pdf

Wireless LAN IEEE 802 - Intranet...

Documents

Transcript of Wireless LAN IEEE 802 - Intranet...