Net&System Security13 Ottobre 2005
Pisa
“Attacchi attivi al WEP” (Live Session)
Angelo Dell'Aera [email protected]
A proposito del relatore...
Angelo Dell'Aera si è laureato in Ingegneria Elettronica presso il Politecnico di Bari con cui ha collaborato nell'ambito del progetto TCP Westwood+, un algoritmo di nuova concezione per il TCP congestion control, di cui ha sviluppato le patch, ufficialmente integrate nel kernel di Linux.
Segue attivamente lo sviluppo del kernel di Linux da alcuni anni interessandosi, in particolar modo, al networking, alla VM e alle problematiche relative alle architetture SMP. Membro di Antifork Research, associazione di ricerca no-profit sulla sicurezza informatica, contribuisce a numerosi progetti security-related.
Attualmente lavora in qualità di Security Engineer presso Communication Valley S.p.A., noto Security Service Provider avente sede a Parma.
Il protocollo WEP
➢ Il protocollo WEP (Wired Equivalent Privacy) è parte integrante dello
standard 802.11 definito dall'IEEE che definisce le specifiche per le wireless
local area networks (WLAN)
➢ E' stato progettato come protocollo di sicurezza a data-link layer in grado di
garantire lo stesso livello di sicurezza di una wired LAN
Obiettivi del protocollo WEP
Il protocollo WEP si pone essenzialmente due obiettivi
➢ Proteggere la confidenzialità dei dati da link-layer eavesdropping
➢ Garantire un controllo sull'accesso alla rete
WEP➢ I client wireless condividono una chiave
WEP tipicamente a 40/104 bit con l'Access Point (AP)
➢ Alla chiave WEP vengono aggiunti 24 bit che costituiscono l'Initialization Vector
(IV)
➢ E' un errore parlare di chiavi WEP a 64/128 bit in quanto l'IV viene
trasmesso in chiaro!
WEP
➢ Ogni frame include inoltre un integrity check CRC-32 indicato con il termine
Integrity Check Value (ICV)
➢ Se la verifica dell'ICV dovesse risultare invalida il frame verrebbe scartato in
quanto corrotto
➢ Opzionalmente tutti i frame non crittati dovrebbero essere scartati
WEP➢ Il protocollo WEP si basa sullo stream
cipher RC4 per garantire la confidenzialità dei dati
➢ Lo stream cipher RC4 espande il seed <IV, chiave> in un keystream
pseudorandom
➢ Le operazioni di crittazione e decrittazione sono identiche e consistono in una XOR con il keystream ottenuto dal
seed
Costruzione di un frame WEP Checksumming
➢ Si calcola il checksum CRC(M) del messaggio M da inviare
➢ Il messaggio M e il checksum CRC(M) vengono concatenati e vanno a formare il
plaintext P = <M, CRC(M)>
➢ Si noti che P non dipende dalla chiave WEP k
Costruzione di un frame WEP Encryption
➢ Viene scelto un IV v che viene concatenato alla chiave k condivisa da client e AP
➢ Si genera un keystream mediante l'algoritmo RC4 che indicheremo con RC4(v,
k)
➢ Viene generato il ciphertext comeC = P ⊕ RC4(v, k)
Struttura di un frame WEP
IV MSDU ICV
Initialization Vector Pad Key ID
24 6 2
0-2304 4
Octets
Bits
Encrypted
Initialization Vector
Essendo il WEP basato su RC4, in assenza di IV, lo stesso plaintext produrrebbe sempre lo
stesso ciphertext a causa del keystream sempre uguale. Questo potrebbe consentire a
un eavesdropper di osservare pattern nel ciphertext e ricavare il plaintext.
key
XXYYZZHello!
plaintext ciphertext
WEP
Problema 1 Keystream Reuse
➢ Ipotizziamo che per crittare due plaintext P1 e P2 venga scelto lo stesso IV v. In tal
caso avremmo
C1 = P1 ⊕ RC4(v, k)
C2 = P2 ⊕ RC4(v, k)
C1 ⊕ C2 = (P1 ⊕ RC4(v, k)) ⊕ (P2 ⊕ RC4(v, k))
=P1 ⊕ P2
Problema 1 Keystream Reuse
➢ In altre parole, mettendo in XOR due ciphertext crittati con lo stesso seed è
possibile eliminare il keystream
➢ Successivamente è possibile ricavare uno dei due plaintext se si conosce l'altro mediante un attacco chosen-plaintext
oppure ricavare entrambi con attacchi di tipo statistico
Problema 2 Checksum Linearity
➢ Il CRC-32 crittato è uno strumento valido per controllare la presenza di errori casuali ma non di quelli introdotti di
proposito!
➢ Infatti il CRC-32 è lineare il che implica che
CRC(X ⊕ Y) = CRC(X)⊕ CRC(Y)
Problema 2 Checksum Linearity
➢ E' possibile trovare un nuovo ciphertext C' che venga decrittato in M' con M' = M
⊕ µ con µ scelto arbitrariamente dall'attaccante
C' = C ⊕ <µ, CRC(µ)>
= RC4(v,k) ⊕ <M, CRC(M)> ⊕ <µ, CRC(µ)>=RC4(v,k) ⊕ <M ⊕ µ, CRC(M) ⊕ CRC(µ)>
= RC4(v,k) ⊕ <M', CRC(M ⊕ µ)>= RC4(v,k) ⊕ <M', CRC(M')>
Problema 3
Traffic Injection
➢ Se un attaccante riuscisse ad avere a disposizione sia il plaintext sia il ciphertext
conoscerebbe il keystream e potrebbe usarlo per iniettare pacchetti usando lo stesso IV
➢ E' possibile montare un attacco di questo tipo mandando del traffico in chiaro noto verso la
rete wireless e sniffando alla ricerca del ciphertext
Problema 4
Traffic Reinjection ➢ WEP non implementa alcuna forma di
protezione nei confronti dei replay attacks
➢ E' quindi possibile reiniettare più volte un frame crittato e questo sarà considerato
valido
➢ Questo problema viene sfruttato nell'attacco attivo più efficace al WEP ossia l'ARP request
reinjection
Attacco di Fluhrer, Mantin e Shamir (FMS)
➢ L'attacco FMS è un attacco passivo che sfrutta i punti deboli presenti nell'algoritmo di pianificazione delle chiavi di RC4 e l'impiego
degli IV
➢ Esistono infatti valori “deboli” di IV (weak Ivs) che lasciano trapelare informazioni sulla
chiave
➢ Raccogliendo un numero sufficiente di pacchetti con weak IV è possibile individuare
la chiave
Aircrack
➢ Aircrack è lo strumento principe per realizzare attacchi attivi e passivi al WEP
➢ Esso implementa gli attacchi statistici sviluppati del talentuoso hacker KoreK nonchè una versione particolarmente
ottimizzata dell'attacco FMS
Live Session!
Riferimenti➢ Fluhrer, Mantin, Shamir “Weakness in the Key Scheduling Algorithm of RC4”
(Eight Annual Workshop on Selected Areas in Cryptography, 2001)
➢ Borisov, Goldberg, Wagner “Intercepting Mobile Communications : The Insecurity of 802.11”
(Proceedings of the Seventh Annual International Conference on Mobile Computing And Networking, 2001)
Ringraziamenti➢ Guido “Zen” Bolognesi per il prezioso
materiale
➢ Alessandro Curio per aver sacrificato un intero venerdì notte a fare test di ogni genere
e sorta
➢ Scott Fluhrer, Itsik Mantin, Adi Shamir, Christophe Devine e Korek per aver reso il discorso sicurezza in ambito 802.11 così
piccante...