Cosa c’è dietro KRACK – Key Reinstallation Attacks

Notizia degli ultimi giorni, che a chi non si interessa di computer potrebbe essere sfuggita, è che un gruppo di ricercatori ha scoperto una vulnerabilità nel sistema di sicurezza delle connessioni wi-fi WPA2.

Prima parte, la basi basi.

Chi è già preparato in materia e fosse interessato solo ai dettagli “piccanti” può andare direttamente qui.

WPA2 ( Wi-Fi Protected Access II), successore del colabrodo WEP (Wired Equivalent Privacy), fu introdotto per rimediare alle molte falle di sicurezza del suo predecessore. E nonostante tutto sembra aver funzionato abbastanza bene fino a poco tempo fa, quando alcune delle falle di sicurezza nel processo di autenticazione teorizzate negli ultimi anni, sono state messe in pratica alcuni giorni fa per permettere ad un attacnte che abbia accesso alla rete wi-fi a cui siamo connessi di intercettare il traffico che generiamo.

Perché succede ciò?

WPA non dovrebbe criptare tutte le comunicazioni dal mio pc/smartphone/smart-qualsiasicosa al router/access point? In teoria si, ma il punto è proprio che con questo nuovo sistema un attaccante può decrittare – e quindi ottenere in chiaro – le informazioni inviate dalla vittima via Wi-Fi. Questo, combinato con altre tecniche che permettono, per alcuni siti, di bypassare il protocollo https possono consentire, ad esempio, di ottenere le credenziali di accesso della vittima, quali nome utente e password.

In questo video una dimostrazione pratica di quello che è possibile fare:

Nel video il bersaglio è android, e pare che i sistemi che usano il client wi-fi wpa_supplicant siano particolarmente vulnerabili, a detta degli autori, a causa di una nota aggiunta nella revisione 2016 della specifica IEEE 802.11. Ad ogni modo…

Perché questa falla di sicurezza è così grave?

Principalmente perché riguarda una serie di dispositivi che con ogni probabilità non verranno mai aggiornati. Android è tristemente famoso per i suoi problemi con gli aggiornamenti di sistema, a causa del fatto che questi sono delegati ai produttori. I dispositivi legati all’IoT (Internet of Things) sono altrettanto noti per la quasi totale mancanza di aggiornamenti e per l’uso come botnet in vari attacchi. Questo dal lato client, il router/Access Point di casa vostra, a meno che non abbiate un AP di livello (e costo) aziendale, con ogni probabilità non verrà mai aggiornato.

Cosa fare per proteggersi da questa vulnerabilità?

Dove è possibile aggiornare il proprio client (per molti OS gli aggiornamenti sono già disponibili).

Se verranno rilasciate patch aggiornare anche gli Access Point.

Per il resto le solite cose, come

usare una password persa per ogni sito

usare https, VPN e/o altre forme di criptazione EndToEnd

e tutte le altre cose che si dovrebbero fare comunque, oltre ad essere consapevoli che internet è intrinsecamente insicuro e le precauzioni non sono mai troppe.

Per i più esperti:

Premessa: non sono un sistemista di rete, né esperto in alcun modo di sicurezza. Mi limito semplicemente a raccogliere le informazioni che ho trovato e a riassumerle. Potrei però fare degli strafalcioni clamorosi, in quel caso se qualcuno che ne sappia più di me volesse correggermi gliene sarò grato. Bene, cominciamo…

L’autenticazione WPA2:

Per capire cosa è successo serve un po’ di background su come funziona l’autenticazione di un client presso un Access Point(AP) wireless. In pratica ci sono 3 fasi, association stage, 4-way handshake e group key handshake. Nella fase di associazione non vi è nessuna forma di autenticazione, solo una richiesta di associazione del client e risposta dell’AP. La parte che interessa l’attacco KRACK è la successiva, quella del 4-way handshake.

4-Way handshake:

Il 4-way handshake provvede l’autenticazione reciproca di AP e client. Lo scopo è quello di definire una chiave crittografica comune per le successive comunicazioni.

I messaggi che AP e client si scambiano nel 4-way handshake sono frame EAPOL (Extensible Authentication Protocol over LAN). Sono strutturati così:

|header|counter|nonce|RSC|   MIC    | Key Data  |
|---------82 byte--------|-variable-|-encrypted-|

In cui l’header identifica di quale messaggio dell’handshake si tratta (1 di 4, 2 di 4, ecc.)

Il replay counter è un semplice contatore incrementale. L’AP incrementa questo contatore dopo aver trasmesso un frame, mentre il client al momento della risposta usa lo stesso valore del frame che ha ricevuto.

Il nonce è spiegato qui, e sia client che AP generano un proprio nonce.

RSC (Recieve Sequence Counter) contiene il riferimento che punta all’inizio del pacchetto che contiene la chiave, nel caso in cui una chiave venga inviata.

MIC (Message Integrity Check) è, come dice il nome, un controllo di integrità.

La chiave stessa, alla fine del frame.

Lo scambio di messaggi dell’handshake si svolge così (spiegazione dei termini sotto):

M1: Nel primo messaggio l’AP invia al client un messaggio che include un replay counter e il suo nonce.

M2: Il client ora ha tutte le informazioni necessarie a derivare la sua PTK e invia il suo nonce all’AP.

M3: L’AP ora può calcolare anch’esso la PTK e invia al client un nuovo messaggio che contiene la GTK (Group Temporal Key) e il contatore incrementato di 1.

PTK e GTK servono per generare la chiave crittografica con cui cifrare i messaggi, solitamente usando AES.

M4: Il client invia una risposta all’AP per confermare che tutto è andato bene e installa PTK e GTK. L’AP ricevuta conferma installa anche lui la PTK ricavata precedentemente.

    Client                                             AP
Calcola la PTK     <--(replay counter, ANonce)---    
                   ---(replay counter, SNonce)--> Calcola la PTK
                   <--(replay counter+1; GTK )--- Installa PTK e GTK
                   ---(       counter+1      )--> Installa PTK

La PMK (Pairwise Master Key) è derivata dalla password di rete, mentre la PTK (Pairwise Transient Key) è derivata da PMK, Authenticator [AP] Nonce (ANonce), Supplicant [Client] Nonce (SNonce) e gli indirizzi MAC dei due.

Una volta generata la PTK è pisa in Key Confirmation Key (KCK), Key Encryption Key (KEK) e Temporal Key (TK). KEK e KCK sono usate rispettivamente per crittare la chiave (“key data” nello schema sopra) e per derivare il MIC.

Perché tutto ciò è importante:

Per capirlo bisogna fare un salto in avanti e capire come questa chiave verrà usata per trasmettere i pacchetti nelle comunicazioni succesive.

Questo avviene in modi differenti a seconda del protocollo usato e in base a questo cambiano anche i vettori di attacco. A titolo esemplificativo si veda CCMP.

Dalla stessa pagina wiki si può vedere che la cifratura avviene così:

L’intestazione del pacchetto CCMP contiene il valore iniziale del contatore utilizzato nel processo crittografico. La cifratura si esegue blocco per blocco secondo il seguente schema:

  1. si cifra il valore iniziale del contatore con l’AES e la chiave di cifratura;
  2. si esegue uno XOR tra il valore cifrato del contatore ed i 128 bit del blocco, ottenendo il primo blocco cifrato;
  3. si incrementa il contatore e si cifra con l’AES, sempre utilizzando la stessa chiave di cifratura;
  4. si esegue uno XOR fra il valore cifrato del contatore ed i 128 bit del blocco successivo, ottenendo un altro blocco cifrato;
  5. si continua dal punto 3 fino a che non sono stati trattati tutti i blocchi

La cosa da notare è che il contatore è parte fondante del processo di crittazione dei dati.

Ne risulta evidente che per la sicurezza crittografica questo non debba mai essere riusato. La logica è la seguente:

legenda Cx = messaggio cifrato x; Px = pacchetto x; Kx = chiave x
C1 = P1(XOR)K1
C2 = P2(XOR)K2
Poiché la chiave è derivata dal contatore, se viene usato lo stesso contatore allora:
K1==K2
Così che:
C1(XOR)C2 == P1(XOR)P2
Nel caso P1 sia noto/derivabile/decifrato è possibile decifrare anche P2

Ottimo, abbiamo capito che il contatore è il punto centrale dell’attacco e che non dovrebbe mai essere riusato.

Come è possibile forzare il riuso di un contatore?

Per fare ciò viene sfruttata una peculiarità dell’implementazione del 4-way handshake. Visto che è possibile che, in una comincazione via Wi-Fi, dei dati vadano persi c’è spesso bisogno di una conferma di ricezione dei dati da parte di Client e AP. Ed è quello che succede nel quarto passaggio dell’handshake, in cui il Client invia conferma all’AP, i contatori sono azzerati e il client comincia ad inviare i suoi pacchetti.

In questa circostanza un attaccante che abbia accesso diretto al segnale Wi-Fi può intercettare i pacchetti inviati dal Client e fare in modo che il 4° messaggio non arrivi all’AP.

Questo implica che l’AP non avendo ricevuto risposta invierà di nuovo al client una richiesta di conferma.

Il client, ricevuta la nuova richiesta, invierà di nuovo la conferma, resetterà di nuovo il contatore ed invierà di nuovo i pacchetti.

L’attaccante che nel frattempo ha intercettato il traffico dal client all’AP è quindi ora in possesso di pacchetti codificati con lo stesso contatore ed ha quindi la possibilità di decifrarne il contenuto.

Perché per alcuni sistemi la falla è più grave che per altri?

Da quanto ho capito, quanto spiegato poco fa si applica alla prima connessione di un client alla rete, e quindi il contatore viene azzerato una volta e poi continua ad incrementare. Questo comporta che affinché il client sappia a che punto è arrivato, la chiave usata per crittografare i pacchetti deve essere conservata. Questo costituisce in sé un problema per la sicurezza in quanto un attaccante potrebbe avere accesso a questa chiave se avesse accesso al nostro computer. Per evitare ciò la revisione 2016 della specifica suggerisce di ri-inizializzare il processo di autenticazione dopo un determinato lasso di tempo. Questo vuol dire che anche il contatore viene azzerato, rendendo così l’attacco molto più semplice, in quanto l’attaccante non ha più bisogno di “indovinare” il valore del contatore ma può assumere che questo riparta da 0.

Mentre Windows e altri hanno ignorato questa parte della specifica, i sistemi basati su linux l’hanno implementata, facendo sì che questo attacco risulti più facile per i sistemi che usano una versione di wpa_supplicant non aggiornata.

Annotazioni:

KRACK è in realtà più complicato di così e a seconda dei casi, delle implementazioni e dello schema crittografico utilizzato, sfrutta debolezze perse e permette all’attaccante un perso grado di libertà. Per chi fosse interessato c’è l’articolo di Mathy Vanhoef e Frank Piessens qui.

Per cercare di capire come funzionasse il tutto ho usato questa serie di video, il primo è qui sotto.

A parte l’accento indiano la spiegazione è probabilmente più chiara della mia.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo di WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google photo

Stai commentando usando il tuo account Google. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...