Un VPN protegge da KRACK? Cosa corregge la patch

Se compri un VPN perché un titolo diceva che KRACK rompe la cifratura Wi-Fi, stai riparando lo strato sbagliato. Quella divulgazione del 2017 descriveva una famiglia di attacchi di reinstallazione della chiave contro l’handshake a quattro vie di WPA2, e la riparazione è arrivata come aggiornamenti del sistema operativo, patch dei driver wireless e firmware del router. Un tunnel può nascondere il tuo traffico dalla rete locale, ma non può riparare un handshake che si conclude sotto di esso. Quindi la prima domanda non è quale VPN comprare; è quale dei tuoi dispositivi esegue ancora uno stack wireless senza patch.

La stessa distinzione risponde al timore per il budget. Chi non può permettersi un abbonamento non è mai stato escluso dal rimedio reale, perché il rimedio era un aggiornamento gratuito. Costa denaro sostituire hardware che non ne riceve più.

Cosa ha manipolato davvero l’attacco

WPA2 deriva una nuova chiave di coppia al momento dell’associazione tramite un handshake a quattro vie. Il punto di accesso invia un nonce, il client risponde col proprio, entrambe le parti calcolano la chiave transitoria di coppia e il punto di accesso conferma con un messaggio che il client accusa. Un attacco di reinstallazione della chiave interferisce con quella sequenza invece di indovinare la passphrase, costringendo un client a installare una chiave che ha già installato. Ogni reinstallazione può azzerare il nonce di trasmissione e il contatore di replay in ricezione legati a quella chiave.

Quando quei contatori tornano indietro, parte del traffico che avrebbe dovuto essere rifiutato torna accettabile. A seconda della variante e dell’implementazione, un attaccante a portata radio poteva riprodurre frame, decifrarli o iniettarli. L’handshake della chiave di gruppo e quello della transizione rapida avevano varianti proprie, ed è per questo che l’avviso elencava diversi nomi di attacco invece di uno.

Android 6.0 e successivi è stato il caso peggiore. Le sue versioni di wpa_supplicant potevano essere spinte a installare una chiave di tutti zeri, il che rendeva la decifratura molto più facile che sulle piattaforme dove la reinstallazione azzerava solo i contatori. Quel dettaglio separava una debolezza teorica da una pratica sulla piattaforma telefonica più diffusa dell’epoca.

La correzione vive nello stack wireless

La correzione a monte disse ai supplicant e ai punti di accesso di ignorare un messaggio di handshake ritrasmesso una volta che la chiave era già installata. Le build corrette di wpa_supplicant e hostapd la portavano, e le distribuzioni l’hanno riportata nei rami più vecchi, quindi la stringa stampata da wpa_supplicant -v è un punto di partenza e non un verdetto. Leggi l’avviso di sicurezza della distribuzione e conferma la patch specifica, non solo il numero di versione. Una build che dichiara una versione vecchia può essere comunque corretta, e una che ne dichiara una nuova può ancora mancare di un backport del fornitore.

Entrambe le estremità del collegamento richiedono attenzione. Un router riparato non corregge il portatile che vi si associa, e un portatile riparato non corregge il router. I produttori pubblicavano avvisi per prodotto, e le correzioni dei router spesso arrivavano dopo gli aggiornamenti dei telefoni perché ogni modello ha bisogno della propria build di firmware. Se l’ultima versione di un dispositivo precede l’avviso, trattalo come non corretto finché il produttore non dice il contrario.

Per le apparecchiature che non puoi aggiornare, le opzioni sono strette e poco glamour. Ritirale, tienile lontane da reti che trasportano traffico sensibile, o confinale in un segmento dove i suoi unici pari sono altrettanto sacrificabili. Nessuna di queste opzioni comporta un abbonamento, e nessuna migliora scegliendo un altro fornitore di tunnel.

Cosa copre un tunnel

Un VPN sposta il confine. Il tuo dispositivo cifra ogni pacchetto e lo invia a un server VPN, che lo decifra e lo inoltra. Chi manipola il collegamento Wi-Fi vede i pacchetti esterni del tunnel, non il carico utile all’interno, quindi un attacco di reinstallazione che espone frame del livello di collegamento non espone automaticamente il contenuto della connessione incanalata nel tunnel. Quella protezione vale anche mentre lo stack wireless sottostante resta vulnerabile, ed è esattamente per questo che i due controlli vengono confusi.

Il distinguo è «incanalato nel tunnel». Il tunneling diviso, una lista di esclusione o un’eccezione per il portale captive mandano parte del traffico fuori dal tunnel, e quel traffico non ne trae alcun beneficio. Lo stesso vale per il traffico di altri dispositivi sulla stessa rete che non hanno mai installato il client. Un tunnel è una decisione per dispositivo e per rotta, non una proprietà della stanza, e un VPN a livello di router copre solo ciò che passa davvero attraverso il router.

Ciò che il tunnel non può fare è riparare il driver, fermare un’ondata di deautenticazione o impedire a un attaccante di disturbare il canale. Non può nemmeno proteggere una connessione che non vi entra mai. Sono problemi di disponibilità e di livello di collegamento, e restano con lo stack wireless per quanto sia forte la suite di cifratura del tunnel.

HTTPS e il tunnel proteggono salti diversi

Un singolo caricamento di pagina può coinvolgere tre protezioni separate: il collegamento Wi-Fi, il tunnel verso il server VPN e la sessione TLS verso il sito web. Ognuna viene negoziata in modo indipendente. TLS con un certificato valido e una versione di protocollo moderna ti dà cifratura autenticata tra browser e sito anche quando il primo salto è ostile, perché è il controllo del certificato a impedire a un impostore di sostituire la propria chiave.

Quel controllo ha punti deboli ai bordi. Un reindirizzamento da HTTPS a HTTP, una pagina che carica script in HTTP semplice o un utente che clicca attraverso un avviso di certificato spostano tutti il traffico fuori dalla sessione protetta. HSTS e le pagine intermedie del browser esistono perché questi errori sono frequenti, non perché TLS sia fragile.

Mantenere HTTPS e un tunnel non rende l’implementazione wireless non più vulnerabile. I frame vengono ancora decifrati da un driver difettoso; la differenza è ciò che l’attaccante trova dentro e se quel contenuto era già protetto da qualcos’altro.

Ordine di riparazione per una rete mista

Parti dal punto di accesso, perché è il dispositivo che controlli e da cui dipende ogni client. Poi passa ai sistemi operativi dei client, dal più vecchio al più recente, dato che le piattaforme che hanno smesso di ricevere aggiornamenti sono quelle che non saranno mai corrette. Solo quando quell’inventario è completo una decisione sul VPN ha senso, ed è una decisione sull’esposizione, non sulla riparazione. Farlo nell’ordine opposto, prima il tunnel e poi il firmware, lascia il difetto reale al suo posto finché dura l’abbonamento.

Annota ciò che hai verificato, inclusa la versione del firmware e la data. «Aggiornato» non è uno stato che qualcuno possa controllare dopo.

Tre controlli coprono la maggior parte del lavoro, e vanno in quest’ordine. Non saltare il terzo solo perché i primi due sono tornati puliti.

• Firmware del router: confronta la versione installata con la pagina degli avvisi del produttore, non con il pulsante di aggiornamento.
• SO del client: conferma il livello di patch che include la correzione wireless per ogni telefono, portatile e tablet.
• Resti: elenca i dispositivi senza un percorso di patch e decidi se ritirare, isolare o accettare.

Se l’elenco dei resti è lungo, una rete ospiti con isolamento dei client guadagna tempo mentre l’hardware viene sostituito. Poi prova un client noto su ogni banda, annota il risultato e ricontrolla dopo la versione di firmware successiva. L’inventario hardware è ciò che rende rapido il prossimo avviso; il tunnel è ciò che copre il divario nel frattempo.