Key reinstallation attacks forcing nonce reuse in wpa2
•
0 likes•112 views
Cybersecurity
Recommended
Recommended
More Related Content
Similar to Key reinstallation attacks forcing nonce reuse in wpa2
Similar to Key reinstallation attacks forcing nonce reuse in wpa2 (20)
More from Università Degli Studi Di Salerno
More from Università Degli Studi Di Salerno (9)
Recently uploaded
Recently uploaded (20)
Key reinstallation attacks forcing nonce reuse in wpa2
- 1. Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 Supervisor: Prof. Francesco Palmieri Student: Giorgio Vitiello
- 2. KRACK Overview Concretely, attackers can use this novel attack technique to read information that was previously assumed to be safely encrypted. This can be abused to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on
- 3. About Authors Frank Piessens is a professor in the research group DistriNet (Distributed Systems and Computer Networks) at the Computer Science department of the Katholieke Universiteit Leuven (BE). Mathy Vanhoef is a postdoctoral researcher at Katholieke Universiteit Leuven (BE), where he currently performs research on automatically discovering logical vulnerabilities in network protocol implementations.
- 4. Assigned CVEs Identifiers ◎ CVE-2017-13077 ◎ CVE-2017-13078 ◎ CVE-2017-13079 ◎ CVE-2017-13080 ◎ CVE-2017-13081 ◎ CVE-2017-13082 ◎ CVE-2017-13084 ◎ CVE-2017-13086 ◎ CVE-2017-13087 ◎ CVE-2017-13088
- 6. 4-way handshake AMAC, ANonce, sn, Msg1 SMAC, SNonce, sn, Msg2 MICKCK(SNonce, sn, Msg2) AMAC, ANonce, sn+1, Msg3, EncKEK(GTK), MICKCK(ANonce, sn+1, Msg3) SMAC, SNonce, sn+1, Msg4 MICKCK(sn+1, Msg4) Derive PTK Derive PTK, Verify MIC Verify MIC, Install PTK & GTK, Update sn Install PTK Update sn optional 802.1X authentication encrypted data frame can now be exchanged
- 7. 4-way handshake AMAC, ANonce, sn, Msg1 SMAC, SNonce, sn, Msg2 MICKCK(SNonce, sn, Msg2) Derive PTK Derive PTK, Verify MIC optional 802.1X authentication PTK = PRF (PMK, “Pairwise key expansion”, min (AMAC, SMAC) || max (AMAC, SMAC) || min (Anonce, Snonce) || max (Anonce, Snonce), 384 [key length])
- 8. Frame Encryption (Simplified) Enc Nonce (packet number) PTK (TK) Encrypted Data Keystream Nonc e Plaintext Data Packet Key Nonce reuse implies keystream reuse (in all WPA2 ciphers)
- 9. Frame Encryption: CCMP Example AES AES AES CTR CTR + 1 CTR + N . . . PTK (TK) PTK (TK) PTK (TK) Plaintext 1 Plaintext 2 Plaintext N Encrypted Data Keystream Nonce . . .
- 10. Frame Encryption: CCMP Example AES AES AES. . . PTK (TK) Plaintext 1 Plaintext 2 Plaintext N Encrypted Data Keystream Nonce CTR = Flag2 || Flag || MAC_send || Nonce || 016 CTR CTR + 1 CTR + N PTK (TK)PTK (TK) . . .
- 11. 4-way handshake AMAC, ANonce, sn, Msg1 SMAC, SNonce, sn, Msg2 MICKCK(SNonce, sn, Msg2) AMAC, ANonce, sn+1, Msg3, EncKEK(GTK), MICKCK(ANonce, sn+1, Msg3) SMAC, SNonce, sn+1, Msg4 MICKCK(sn+1, Msg4) Derive PTK Derive PTK, Verify MIC Verify MIC, Install PTK & GTK, Update sn Install PTK Update sn optional 802.1X authentication encrypted data frame can now be exchanged Installing PTK initializes Nonce to 0
- 13. Key Reinstallation Attack - Complications ◎Not all Wi-Fi clients properly implement the state machine ○ Still vulnerable against the group key handshake and FT handshake ◎We must obtain a MitM position between the client and AP ○ It is difficult due to 4-way handshake ○ The solution is to employ a channel-based MitM attack
- 14. Key Reinstallation Attack Msg1(r, Anonce) Msg2(r, Snonce) Msg3(r+1, GTK) optional 802.1X authentication Msg1(r, Anonce) Msg2(r, Snonce) Msg3(r+1, GTK) Msg4(r+1) Install PTK & GTK Block Msg4 Channel 3 Channel 5
- 15. Key Reinstallation Attack Msg4(r+1)Install PTK & GTK Msg3(r+2, GTK)Msg3(r+2, GTK) Enc1 PTK(Msg4(r+2)) Reinstall PTK & GTK Key Reinstallation! Nonce is reset
- 16. Key Reinstallation Attack Msg4(r+1)Install PTK & GTK Msg3(r+2, GTK)Msg3(r+2, GTK) Enc1 PTK(Msg4(r+2)) Reinstall PTK & GTK Enc1 PTK(Data(...)) Enc1 PTK(Data(...))
- 17. Key Reinstallation Attack Msg4(r+1)Install PTK & GTK Msg3(r+2, GTK)Msg3(r+2, GTK) Enc1 PTK(Msg4(r+2)) Reinstall PTK & GTK Enc1 PTK(Data(...)) Enc1 PTK(Data(...)) Same Nonce is used
- 18. Key Reinstallation Attack Msg4(r+1)Install PTK & GTK Msg3(r+2, GTK)Msg3(r+2, GTK) Enc1 PTK(Msg4(r+2)) Reinstall PTK & GTK Enc1 PTK(Data(...)) Enc1 PTK(Data(...)) Keystream
- 19. Key Reinstallation Attack Msg4(r+1)Install PTK & GTK Msg3(r+2, GTK)Msg3(r+2, GTK) Enc1 PTK(Msg4(r+2)) Reinstall PTK & GTK Enc1 PTK(Data(...)) Enc1 PTK(Data(...)) Keystream Decrypted!
- 20. Encrypted Retransmission of frame 3 ◎There are some clients that, once they installed the PTK, they do only accept encrypted retransmissions of message 3 ◎To attack them, we exploit an inherent race condition between the entity executing the 4-way handshake, and the entity implementing the data-confidentiality protocol
- 21. Warm-up: Android Attack Msg1(r, Anonce)Msg1(r, Anonce) Msg2(r, Snonce) Msg2(r, Snonce) Msg3(r+1, GTK) Msg3(r+2, GTK) Msg3(r+1, GTK) Msg3(r+2, GTK)
- 22. Warm-up: Android Attack Msg4(r+1) Msg4(r+1) Install keys command Install PTK & GTK Msg4(r+2) Enc1 PTK(Msg4(r+2)) Install keys command Reinstall PTK & GTK next transmitted frame will reuse Nonce 1
- 23. Attack macOS: encrypted message 3 retransmissions initial 4-way handshake Install PTK & GTK pairwise rekey in progress Encx PTK(Msg3(r+1, GTK)) Encx+1 PTK(Msg3(r+2, GTK)) Msg3(r+1, GTK) Msg3(r+2, GTK)
- 24. Attack macOS: encrypted message 3 retransmissions Msg4(r+1) Install keys command Ency PTK(Msg4(r+1)) Install PTK’ & GTKMsg4(r+2) Install keys command Enc1 PTK’(Msg4(r+2)) Reinstall PTK’ & GTKnext transmitted frame will reuse Nonce 1
- 25. Breaking the Group Key Handshake Prerequisites: ◎ Clients will reinitialize the replay counter when installing an already-in-use group key ○ All Wi-Fi clients are vulnerable ◎ We must be able to collect a group message 1 that the client (still) accepts, and that contains a group key that is already in use by the AP ○ According to the standard, the new group key should be installed after all stations replied with a group message 2
- 26. Breaking the Group Key Handshake ◎ Client is attacked, but only AP sends real broadcast frames ◎ Can only replay broadcast frames to client Unicast Broadcast
- 27. Group Key Handshake Initial 4-way handshake Encx PTK(Group1(r+2, GTK)) Refresh GTK Ency PTK(Group2(r+2)) Install GTK? Install GTK Install GTK?
- 28. GK Handshake: Immediate Key Installation Attack Encx PTK(Group1(r, GTK)) Initial 4-way handshake Encx PTK(Group1(r, GTK)) Ency PTK(Group2(r)) Encx+1 PTK(Group1(r+1, GTK)) Refresh GTK Install GTK Install GTK
- 29. GK Handshake: Immediate Key Installation Attack Enc1 GTK(GroupData(...)) Encx+1 PTK(Group1(r+1, GTK)) Enc1 GTK(GroupData(...) ) Reinstall GTK Reinitialize replay counter Enc1 GTK(GroupData(...)) Replay Broadcast Data Frame!
- 30. GK Handshake: Delay Key Installation Attack Encx PTK(Group1(r, GTK)) Initial 4-way handshake Encx PTK(Group1(r, GTK)) Ency PTK(Group2(r)) Encx+1 PTK(Group1(r+1, GTK)) Refresh GTK Install GTK NOT Install GTK again
- 31. GK Handshake: Delay Key Installation Attack Ency PTK(Group2(r)) Enc1 GTK(GroupData(...)) Encx+1 PTK(Group1(r+1, GTK)) Enc1 GTK(GroupData(...)) Reinstall GTK Reinitialize replay counter Install GTK Enc1 GTK(GroupData(...)) Replay Broadcast Data Frame!
- 32. The Fast BSS Transition (FT) Handshake ◎Fast Roaming = 802.11r ◎Its goal is to reduce the roaming time when a client moves from one AP to another of the same Basic Service Set ◎A new 802.1x handshake is not required ◎It embeds the 4-way handshake stage in the authentication and reassociation frames
- 33. FT Handshake AuthReq(Snonce) ReassReq(ANonce, SNonce, MIC) Install PTK? Install PTK & GTK AuthResp(Anonce, Snonce) Install PTK? Install PTK ReassResp(ANonce, SNonce, MIC, GTK)
- 34. 802.11r FT Handshake Attack ◎Access Point is attacked ○ Replay, Decrypt, Forge ◎No MitM required ◎Can keep causing Nonce resets ◎If the reassociation response is lost due to background noise, the client will retransmit the reassociation request ○ APs may already be reusing Nonces
- 35. 802.11r FT Handshake Attack AuthReq(Snonce) ReassReq(ANonce, SNonce, MIC) Install PTK & GTK AuthResp(Anonce, Snonce) Install PTK ReassResp(ANonce, SNonce, MIC, GTK) ReassReq(ANonce, SNonce, MIC) Enc1 PTK(Data(...)) ReassResp(ANonce, SNonce, MIC, GTK) next transmitted frames will reuse Nonces Reinstall PTK
- 36. 802.11r FT Handshake Attack AuthReq(Snonce) ReassReq(ANonce, SNonce, MIC) Install PTK & GTK AuthResp(Anonce, Snonce) Install PTK ReassResp(ANonce, SNonce, MIC, GTK) ReassReq(ANonce, SNonce, MIC) Enc1 PTK(Data(...)) ReassResp(ANonce, SNonce, MIC, GTK) next transmitted frames will reuse Nonces Reinstall PTK Do NOT contain Replay Counter!
- 37. Cipher suite specific ◎ AES-CCMP ○ No practical frame forging attacks ◎ WPA-TKIP ○ Recover Message Integrity Check key from plaintext ○ Forge/inject frames sent by the device under attack ◎ GCMP (WiGig) ○ Recover GHASH authentication key from nonce reuse ○ Forge/inject frames in both directions
- 38. Implementation specific ◎ iOS 10 and Windows: 4-way handshake not affected ○ Cannot decrypt unicast traffic (nor replay/decrypt) ○ But group key handshake is affected (replay broadcast) ○ Note: iOS 11 does have vulnerable 4-way handshake ◎wpa_supplicant 2.4+ ○ Client used on Linux and Android 6.0+ ○ On retransmitted msg3 will install all-zero key
- 39. Android all-zero key Attack Msg3(r+1, GTK)Msg3(r+1, GTK) Initial stage 4-way handshake Derive PTK Msg4(r+1) Msg4(r+1) Install-key(PTK) Clear PTK Install PTK Msg3(r+2, GTK) Enc1 PTK(Msg4(r+2)) Msg3(r+2, GTK) Msg4(r+2) Install-key(0…0) Install all- zero PTK
- 40. Limitation of the Security Proofs Both encryption protocols and 4-way handshake have been proven secure...
- 41. Limitation of the Security Proofs ...but not their combination!
- 42. “ In theory, theory and practice are the same. In practice, they are not.
- 43. References ◎ M. Vanhoef, Frank Piessens - Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 https://papers.mathyvanhoef.com/ccs2017.pdf
Editor's Notes
- Concretamente, gli aggressori possono utilizzare questa nuova tecnica di attacco per leggere informazioni che in precedenza erano ritenute crittografate in modo sicuro. Questo può essere abusato per rubare informazioni sensibili come numeri di carta di credito, password, messaggi di chat, e-mail, foto e così via.
- Previously he performed research on streamciphers, and discovered a new attack on RC4 that made it possible to exploit RC4 as used in TLS in practice (the RC4 NOMORE attack)
- Quindi l’AP invierà un altro frame al client contenente il proprio MAC address, il Nonce che aveva usato in precedenza, il sn incrementato di uno e (opzionalmente in questa fase) la GTK (group temporal key), la quale sarà cifrata con la KEK (sempre ottenuta dalla PTK), e infine il MIC del messaggio. Il client, verificata l’integrità, potrà installare la PTK (Pairwise Transient Key) e la GTK e incrementare il sn Infine il client invia l’ultimo messaggio di “conferma” con il proprio MAC address, il Nonce che ha usato in precedenza, il sn + 1 e il MIC. L’AP ora installa la PTK Da questo punto in poi la comunicazione potrà avvenire in maniera cifrata
- Ora l’AP può generare la stessa PTK del client. Per esempio nel caso del CCMP la PTK è generata applicando una PRF (che non è altro che un HMAC-SHA1) con input la PMK (che hanno ottenuto in precedenza con la pre-shared key o con Radius), una frase standard, il minimo fra i due mac address concatenato al max fra i due mac address concatenato al min fra i due nonce concatenato al max fra i due nonce, e come ultimo parametro la lunghezza della chiave, 384 nel caso del CCMP
- Ora cerchiamo di capire come funziona la cifratura in una rete wpa2. Nel seguente esempio vogliamo inviare questo testo in chiaro di dati. L’algoritmo di cifratura prende in input la chiave di sessione (che abbiamo appena negoziato) e un Nonce (del client o dall’AP a seconda di chi trasmette) che sarà incrementato di uno per ogni pacchetto trasmesso. In questo modo si dovrebbe ottenere una chiave diversa per ogni pacchetto inviato che naturalmente si dovrebbe utilizzare soltanto una volta. Otteniamo quindi il Keystram e come in uno streamcipher facciamo lo xor bit a bit con il testo in chiaro e infine concateniamo il Nonce in chiaro perché il ricevente deve conoscere il Nonce che il mittente ha utilizzato per cifrare. La cosa essenziale da capire è che se il Nonce viene riutilizzato lo stesso packet key viene generato e sappiamo bene che in crittografia il determinismo porta a una bassa sicurezza.
- Per fare un esempio un po’ più concreto vediamo come si comporta il protocollo crittografico in modalità CCMP. In questo caso, come dicevo prima viene utilizzato AES in modalità counter, e ora lo possiamo ricordare meglio con la figura. Come sappiamo ogni blocco prende il ctr incrementato di uno. Ci chiediamo dove viene usato il Nonce in questo schema….
- ...e la risposta è che questo viene utilizzato per generare il counter. Dalla specifica dell’RFC Flag2 e Flag sono costanti, il MAC address del mittente è ovviamente una costante come è una costante la parte finale composta da 16 0. Quindi l’unicità del ctr dipende interamente dal Nonce. Quindi l’unico obiettivo è evitare che il Nonce venga riutilizzato. Visto che il Nonce viene ogni volta incrementato di uno l’unica cosa che ci resta da capire è come questo sia inizializzato
- E la risposta è molto semplice. Quando viene installata la PTK il Nonce viene inizializzato a 0. In realtà la cosa ha perfettamente senso perché ogni volta che un pacchetto viene inviato questo viene incrementato di uno e non c’è mai riuso perché quando si va in overflow si potrebbe rifare l’handshake e si usa una nuova chiave. Faremo quindi vedere il modo in cui si può forzare il riuso di questo nonce forzando la reinstallazione della chiave che inzializzerà di nuovo il Nonce a 0 (oppure a 1 a seconda dell’implementazione)
- L’emendamento 802.11i non contiene una descrizione formale della macchina di stato di come il client debba implementare il 4wh. Fortunatamente l’802.11r estende il 4wh e fornisce una descrizione piu dettagliata. Nell’immagine gli autori del paper ci propongono questa versione semplificata. Senza andare troppo nel dettaglio, ciò che occorre notare è che avverrà una ritrasmissione del messaggio 1 o del messaggio 3 se l’authenticator non ha ricevuto rispettivamente il messaggio 2 o il messaggio 4. La ritrasmissione usa un replay counter incrementato.
- Prima di procedere con l’attacco c’è da dire che in pratica possono nascere alcune complicazioni quando si esegue l’attacco. In primo luogo non tutti i client implementano la macchina di stato in maniera identica allo standard, tuttavia tali client restano ancora vulnerabili al group key handshake e al ft handshake (fast BSS Transition Handshake). In secondo luogo vorremmo ottenere una posizione fra il client e l’AP per un attacco MitM. Il problema è che ciò non è banale a causa del 4way-handshake. Infatti, come abbiamo visto, le chiavi di sessione generate dipendono dal mac address dell’ap e del client. Quindi se usiamo un rouge AP (access point wireless) con un mac address differente l’handshake fallirà. Spoofare il mac address per esempio dell’AP neanche è possibile altrimenti il client e l’AP comunicherebbero fra di loro. La soluzione è quindi quella di utilizzare un attacco MitM channel-based dove il rouge AP è clonato su canale differente con il MAC address spoofato dell’AP vittima. Questo ci assicura che il client e l’AP derivino le stesse chiavi di sessione e che non si parlino fra di loro.
- Nell’esempio il client prova a connettersi all’ap sul canale 3 dove è presente l’avversario con un rouge AP. L’attaccante inoltrerà i messaggi ricevuti dal client sul canale 5 (che è il vero canale dell’AP) verso l’AP, spoofando ovviamente il mac address del client. Dunque supponiamo che l’attaccante riesca ad assumere questa posizione di MitM e che quindi sia in grado di bloccare i pacchetti in quanto non inviare un pacchetto equivale a bloccarlo, visto che comunicano su canali diversi. Dunque i primi tre messaggi sono semplicemente inoltrati fra le due device, mentre il messaggio 4 che invia il client non sarà inoltrato. La cosa interessante è che dal punto di vista del client a questo punto il 4-way handshake è concluso e può installare la PTK e la GTK
- A questo punto l’AP rimanda il messaggio 3 con il replay counter incrementato perché pensa che il messaggio 3 non sia stato ricevuto. Il client accetta il messaggio e invia l’ack con il messaggio 4 che questa volta sarà inviato cifrato (nella notazione il numero l’apice indica il valore del Nonce mentre al pedice la chiave, diciamo PTK per non scendere troppo nel dettaglio qui ma si tratta della TK). Dunque segue il reinstall delle chiavi, quindi come abbiamo già detto il Nonce è resettato
- Il prossimo frame che il client invia userà lo stesso Nonce
- In altre parole lo stesso keystream è riutilizzato. Ora possiamo far vedere come sfruttare il riuso di questo Nonce per decriptare il contenuto di questo data frame
- Ora se notate la differenza fra questi due frame in chiaro è essenzialmente la stessa, quindi effettuando uno xor bit a bit fra il frame cifrato e lo stesso frame in chiaro otteniamo il keystream per il Nonce ad 1. Infatti abbiamo invertito lo xor effettuando naturalmente lo xor stesso
- A questo punto il gioco è fatto perché ottenuto il keystream possiamo decifrare il frame in questione applicando semplicemente lo xor bit a bit
- Ora analizziamo lo scenario in cui un client, dopo avere installato la PTK, accetta soltanto la ritrasmissione cifrata del messaggio 3 Per attaccare questo tipo di client exploitiamo una race condition tra l’entità che esegue il 4wh e l’entità che implementa il protocollo di data-confidentiality
- Partiamo da una sfida piu semplice in cui attacchiamo una implementazione Android del supplicant. Sappiamo che Android accetta la ritrasmissione del plaintext del messaggio 3 quando c’è una ritrasmissione “istantanea”(quando vengono inviate immediatamente dopo il messaggio originale 3). Nel nostro attacco facciamo prima in modo che il client e l’AP si scambino i messaggi 1 e 2. Tuttavia, non inoltriamo il messaggio 3 al client. Invece aspettiamo che l’AP ritrasmetta il messaggio 3 per la seconda volta, e inviamo i due messaggi istantaneamente al client. Il wireless NIC, che implementa il protocollo di data confidentiality, non ha una chiave PTK installata, quindi inoltra entrambi i messaggi alla main CPU. La main CPU, che implementa il 4wh, replica al primo messaggio 3 e ordina al NIC di installare la PTK.
- A questo punto la main CPU del client riceve il secondo messaggio 3 dalla coda di ricezione. Android e Linux accettano frame EAPOL non cifrati come un’eccezione e quindi la main CPU riprocesserà il messaggio 3. Poiché il NIC ha già installato la PTK, il replay sarà cifrato con un Nonce di valore 1. Dopo di ciò, la main CPU dice al NIC di reinstallare la PTK. Nel farlo il NIC resetta il Nonce e il replay counter associato alla PTK, quindi il prossimo Data Frame riutilizzerà il Nonce 1
- Adesso facciamo vedere come attaccare macOS. Questa device accetta soltanto ritrasmissioni cifrate del messaggio 3. Similmente ad Android abusiamo della race condition fra il NIC e la main CPU. Tuttavia, per eseguire questo attacco dobbiamo utilizzare come target una 4wh che sta refreshando la PTK. L’avversario usa ancora un MiTM channel-based attack. Aspetta poi che la vittima e l’avversario eseguano l’inizio del 4wh e aspetta che un secondo 4wh inizi per refreshare la PTK
- Il resto funziona analogamente a prima
- La rete periodicamente fresha il group key per assicurarsi che solo i client autorizzati possiedano questa chiave. Spesso il GTK è rigenerato quando un client lascia la rete. Il nuovo GTK è distribuito con un group key handshake che è formalmente provato sicuro. Nel nostro attacco l’obiettivo è di osservare un group message 1 ritrasmesso, non farlo arrivare al client subito, e inoltrarlo al client in un secondo momento. Il client rinizializzerà il replay counter del GTK che installa. Il primo prerequisito è che il client rinizializzi il replay counter quando installa un GTK già in uso. Questo di fatto avviene sempre. Il secondo prerequisito è che dobbiamo essere in grado di collezionare un group message 1 che il client ancora accetti e che contiene un GTK gia in uso dall’AP. In accordo allo standard il nuovo GTK dovrebbe essere installato dopo che tutte le stazioni replichino con un group message 2
- Si noti che solo l’AP ritrasmetterà il reale frame di broadcast e multicast che sono cifrati usando il group key. Siccome il nostro key reinstallation attack ha come target il client questo significa che non possiamo forzare il riuso del Nonce durante la cifratura. Tuttavia il client resetta il replay counter quando reinstalla il GTK che può essere abusato come replay frame ai client.
- La GTK potrebbe essere installata subito dopo l’invio del messaggio o dopo l’ack. Analizziamo entrambi gli scenari
- Analizziamo l’attacco nel caso in cui l’AP immediatamente installa il group key dopo aver inviato il message 1 a tutti i client. Il client ricevuto il messaggio installerà la nuova GTK e replicherà con group message 2. L’avversario blocca questo messaggio, quindi l’AP ritrasmetterà un nuovo group message 1, che verrà ancora bloccato.
- Ora aspettiamo finché un broadcast data frame è trasmesso, e lo inoltriamo alla vittima. Dopo di ciò inoltriamo il messaggio che prima avevamo conservato alla vittima. Come risultato la vittima reinstallerà la GTK e reinizializzerà il replay counter associato. Questo ci permette di replicare il broadcast data frame. Il client accetta questo frame perché il replay counter è reinizializzato
- Attaccare il group key quando l’AP installa la GTK successivamente è più tedioso. Si noti che l’attacco precedente dovrebbe fallire perché il frame di broadcast trasmesso dovrebbe ancora essere cifrato con il vecchio group key. Questo è un problema perché il group message 1 reinstalla il nuovo group key e quindi non può essere abusato per resettare il replay counter del vecchio gruppo
- Possiamo risolvere il problema al seguente modo. L’attaccante invia il vecchio group message 2 con replay counter r all’AP. Interessante che l’AP dovrebbe accettare questo messaggio anche se non usa l’ultimo replay counter value. Lo standard non richiede che il replay counter matcha l’ultimo che ha usato l’AP. Invece, deve matchare uno che è stato usato in group key handshake. Come risultato l’AP installa un nuovo group key. Quindi aspettiamo finché un frame di broadcast non viene trasmesso e procediamo similmente all’attacco precedente. Ancora è essenziale che il frame di broadcast che vogliamo ritrasmettere è inviato prima della ritrasmissione del group message 1. Altrimenti esso include l’updated replay counter del group key
- L’amendamento 802.11r ha aggiunto il Fast Basic Service Set (BSS) Transition (FT) hs all’802.11. Il suo obiettivo è di ridurre il tempo di roaming quando un client si muove da un AP a un altro dello stesso BSS. Tradizionalmente questo richiede un hs che include un nuovo 802.1x e 4wh. Tuttavia poiché l’FT hs si basa sulla master key derivata durante una connessione precedente con la rete, un nuovo 802.1x hs non è richiesto. Inoltre incorpora il 4wh nei frame di autenticazione e riassociazione
- Ecco un normale FT hs. Si osservi che a differenza del 4wh l’FT hs inizia dal supplicant. I primi due messaggi sono un Authentication Request e un Authentication Response. Sono funzionalmente equivalenti al messaggio 1 e 2 del 4wh rispettivamente e trasportano Nonce randomicamente generati che sono usati per derivare una fresh session key. Dopo di ciò il client invia una ReassReq e l’AP replica con una ReassResp. Sono funzionalmente simili al messaggio 3 e al messaggio 4 del 4wh e trasportano la GTK al client. Soltanto i due messaggi di riassociazione sono autenticati usando il MIC. Inoltre nessuno dei messaggi nell’FT hs contiene un replay counter. Invece, l’FT hs si basa sui random SNonce e ANonce per fornire protezione dai replay tra invocazioni differenti dell’hs. In accordo allo standard la PTK deve già essere installata dopo l’authResp è inviata al ricevente. Inoltre la porta logica 802.1x è solo aperta dopo aver inviato o ricevuto ReassReq. Questo assicura che anche se la PTK è gia stata installata mentre l’hs è ancora in progress, l’AP e il client trasmettono e accettano i frame solo una volta che l’hs è completato. In sintesi questo implica che l’FT hs come definito nell’amendamento 802.11r non è vulnerabile al key reinstallation attack. Tuttavia con le sperimentazioni si è trovato che molte implementazioni effettivamente installano la PTK cosi come la GTK dopo aver inviato o ricevuto la reassResp. Quindi in pratica molte implementazioni dell’FT hs sono vulnerabili al key reinstallation attack.
- Siccome l’AP installa la PTK in risposta alla reassReq il nostro obiettivo sarà di replicare questo frame. In pratica l’AP deve accettare la ritrasmissione della reassReq. Questo perché la reassResp potrebbe essere persa dal rumore di fondo facendo si che il client invii una nuova request. Per questo attacco non è richiesta una posizione MitM. Invece, dobbiamo essere in grado di ascoltare e iniettare frame.
- Nella prima parte dell’attacco lasciamo che il client e l’AP eseguano il normale FT hs. Aspettiamo poi che l’AP abbia trasmesso uno o più data frame cifrati. A questo punto replichiamo la reassReq all’AP.
- Si noti che esso non contiene un replay counter. Inoltre ha un MIC valido quindi l’AP accetterà e processerà il frame replicato. Di conseguenza l’AP reinstallerà la PTK resettando il Nonce associato e il replay counter. Infine il prossimo data frame trasmesso dall’AP sarà cifrato usando un Nonce già utilizzato. Similmente all’attacco precedente anche questo abilita l’attaccante a replicare vecchi data frame inviati dal client all’AP. Sottolineamo che l’attacco è devstante perché i messaggi di FT hs non hanno replay counter il che abilita l’avversario di replicare la reassReq continuamente causando ogni volta il reset del nonce e del replay counter
- L’impatto dipende dall’algoritmo specifico di cifratura e la maggior parte di questi algoritmi usa AES-CCMP e se questa cifratura viene utilizzata l’attacco è molto limitato per quanto riguarda decifrare, inviare frame di replay oppure forgiare frame. Se invece si usa il vecchio TKIP l’attaccante può decifrare frame e recuperare la MIC key che permette di forgiare nuovi frame. Se viene usato GCMP (galois counter mode protocol) l’impatto dell’attacco è abbastanza elevato perché non solo si riesce a recuperare l’authentication key ma si può anche usare per cifrare frame in entrambe le direzioni
- Un altro elemento che influenza l’impatto dell’attacco è la specifica implementazione. Per esempio in IOS e Windows il 4wh non è vulnerabile, perché non implementano esattamente la specifica e non accettano il processo di ritrasmissione del messaggio 3 e di conseguenza non è possibile applicare il key reinstallation attack. Tuttavia sono vulnerabili al group key handshake per reinviare i frame di broadcast. IOS 11 è invece vulnerabile perché accetta la ritrasmissione del messaggio 3. Su Linux si è trovato un flusso interessante se si usa come client wifi wpa_supplicant 2.4+, quindi invece di reinstallare la chiave esso installerà una all-zero encryption key.
- Il nostro key reinstallation attack contro il 4wh non copre il particolare comportamento di un wpa_supplicant. La versione 2.4 e 2.5 installa una all-zero TK quando riceve e ritrasmette il messaggio 3. Questa vulnerabilità sembra essere causata da un remark di 802.11 che indirettamente suggerisce di pulire la TK dalla memoria una volta che è stata installata. La versione 2.6 fixa questo bug installando solo la TK quando riceve il messaggio 3. Tuttavia quando è stato patchato questo bug si è considerato solo lo scenario in cui il messaggio 3 viene perso a causa del rumore e che non si tratti di un attacco attivo. Di conseguenza la patch non tratta criticità di sicurezza e non è stata riportata nelle vecchie versioni. Indipendentemente da questo bug tutte le versioni wpa_supplicant reinstallano il GTK quando ricevono e ritrasmettono il messaggio 3 e sono vulnerabili al group key attack. Molti dispositivi Android 6.0 sono vulnerabili all’all-zero key attack