KRACK Attack: Simulazione di un attacco al protocollo WPA2
Erano i gloriosi anni ‘90 quando la commissione newyorkese dell’IEEE (Institute of Electrical and Electronic Engineers) approvò la prima versione ufficiale del protocollo di comunicazione IEEE 802.11 in grado di scambiare dati a 2 Mbit/s di velocità. Appena due anni più tardi, nel 1999, fu rilasciata la versione 802.11b insieme al brand Wi-Fi che ormai chiunque conosce.
Da allora lo standard si è evoluto fino alla consolidata versione 802.11ac, con velocità che si attestano attorno ai 1300 Mbit/s sulla banda dei 5 GHz e 450 Mbit/s sulla più diffusa frequenza dei 2.4 GHz; cifre che saranno presto superate di circa il 37% dallo sperimentale 802.11ax.
A questa incredibile evoluzione a livello hardware non ha probabilmente fatto seguito un’adeguata implementazione del lato software, volta a garantire allo standard elevati livelli di sicurezza: già nell’agosto del 2001 circolavano abstract e tutorial che dimostravano la debolezza del primo protocollo di crittografia introdotto per reti wireless, ovvero WEP, acronimo di Wired Equivalent Privacy. Purtroppo lo standard fallì clamorosamente il suo obiettivo, rivelando la debolezza dell’algoritmo di cifratura impiegato, l’RC4. Ad oggi una rete protetta con WEP equivale a una rete senza protezione: è craccabile in pochi minuti senza bisogno di client collegati semplicemente catturando tra i 20mila e 100mila initialization vector (IV).
Le cose migliorarono nel 2003 quando la Wi-Fi Alliance rilasciò i protocolli WPA e WPA2; il primo basato sull’algoritmo di controllo dell’integrità dei messaggi TKIP (Temporal Key Integrity Protocol) e il secondo sul più robusto AES (Advanced Encryption Standard ) con chiave a 256 bit: attualmente la certificazione WPA2 è obbligatoria per tutti i nuovi dispositivi idonei a sostenere il marchio Wi-Fi.
Sebbene il protocollo WPA2 sia da considerarsi sicuro, è sufficiente una password debole e qualche informazione lasciata ingenuamente trapelare (come un nome di rete di default e non personalizzato) per poter intraprendere un attacco dizionario o bruteforce tramite rainbow tables e tentare, in tempi umani, di individuarla.
Quello che sembrava essere l’unico vero punto debole del più recente protocollo è stato in questi ultimi tre mesi surclassato da una nuova vulnerabilità individuata dal belga Mathy Vanhoef della imec-DistriNet che ha denominato questa nuova tecnica di attacco “KRACK” (K ey R einstallation A tta ck s ).
Si tratta di una una vulnerabilità molto recente e ancora scarsamente sviluppata dalle varie community, ma nel prosieguo dell’articolo cercheremo di capire il suo funzionamento e di simulare un possibile scenario a fini di eventuali test.
L’attacco si realizza contro il cosiddetto handshake a quattrovie: questa stretta di mano ‘virtuale’ si instaura quando un client inserisce le credenziali corrette per potersi loggare ad una rete protetta, appunto, con protocollo WPA1-2; l’handshake, oltre a confermare che sia il client che l’Access Point sono in possesso delle corrette credenziali, negozia anche una nuova chiave che verrà utilizzata per crittografare tutto il traffico successivo.
In sostanza quando un pacchetto di dati viene inviato via onde radio, questo viene in prima battuta convertito in codice binario per poi essere crittografato via XOR con un numero pseudo-causale e ogni volta diverso chiamato nonce (l’espressione deriva dall’inglese for the nonce, che significa appunto “per l’occasione”), ossia la chiave di decriptaggio per quella specifica connessione.
Mathy Vanhoef è riuscito a trovare il modo di indurre un client vittima a reinstallare la chiave in uso, forzando la negoziazione dell’handshake al livello 3. Ipotizzando la più devastante applicazione concreta dell’attacco, si potrebbe forzare un client vittima a riconnettersi su una rete malevola creata ad hoc dall’attaccante. È facile intuire come tutto il traffico passerà attraverso il computer dell’attaccante – in pratica il nuovo AP – e possa venire ancora più facilmente intercettato mediante programmi quali dsniff e tcpdump .
È importante notare come non sia esente dall’attacco buona parte del traffico crittografato con protocollo HTTPS: in quest’ultima ipotesi, l’attaccante si avvarrà del diabolico sslstrip, un tool che costringe il client a effettuare richieste a server web sicuri – inevitabilmente inserendo le proprie credenziali – senza il prezioso protocollo TLS/SSL e dunque in chiaro. L’attaccante tuttavia incontrerà diverse difficoltà per siti configurati con il protocollo HSTS (HTTP Strict Transport Security), introdotto nel 2012 proprio per prevenire i cosiddetti attacchi di protocol downgrade nonché intercettazione dei cookie.
Lo schema di attacco qui ipotizzato sarà dunque il seguente:
Ora che abbiamo preso confidenza con la virtualizzazione , proveremo a realizzare un semplice scenario di attacco nei confronti di un client collegato a una rete wireless. I requisiti per poter procedere sono: una chiavetta USB che consenta l’iniezione di pacchetti dati (in genere tutti gli apparecchi della ALFA Networks, oppure, come indica l’help dello script di Vanhoef, i modelli TP-Link TL-WN722N o Intel Dual Band Wireless-AC 7260 ) e qualche device (anche come macchine virtuali) che useremo come vittime.
Data la preminente diffusione dei sistemi operativi Microsoft, procederemo utilizzando come sistema host Windows 10. Per prima cosa avviamo Virtualbox e portiamoci sulle impostazioni della nostra macchina virtuale che monta Kali Linux; modifichiamo quindi le opzioni di rete come segue:
A questo punto aggiungiamo alla macchina virtuale la nostra speciale chiavetta Wi-Fi. Dal menu USB abilitiamo la periferica:
Avviamo Kali e lanciamo subito un update prima di procedere con l’installazione del nostro script:
apt update
Installiamo le seguenti librerie:
apt-get install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python-scapy python-pycryptodome
Colleghiamoci ora al repository Git di Mathy Vanhoef e scarichiamo il progetto nella nostra home :
git clone https://github.com/vanhoefm/krackattacks-scripts.git
A questo punto dobbiamo disabilitare il modulo Wi-Fi dal network manager di Kali, dal momento che trasmetteremo la nostra rete test attraverso l’interfaccia wlan0:
Ora è necessario disabilitare la crittografia hardware dell’apparecchio Wi-Fi in uso, con l’intento di evitare bug e interferenze (a questo proposito, l’help del programma raccomanda anche di effettuare i propri test mantenendo una certa distanza tra i propri apparecchi). Portiamoci sotto la cartella dello script scaricato e diamo il comando seguente, avendo poi l’accortezza di riavviare la nostra macchina virtuale:
./disable-hwcrypto.sh
A sistema riavviato digitiamo:
rfkill unblock wifi
Lanciamo i seguenti comandi sotto la directory hostapd per inizializzare l’istanza del demone:
cd .. cp defconfig .config make -j 2
La nostra macchina Kali Linux è finalmente pronta per lanciare l’attacco; lo script creerà una AP – denominata di default ‘testnetwork‘ – al quale si dovranno connettere i dispositivi vittima con password ‘abcdefgh’ (nel mio caso il SSID di prova si chiamerà ICT_SECURITY_MAGAZINE).
Come macchina vittima ho utilizzato una vecchia versione di Parrot Security OS; dal network manager di sistema possiamo individuare la rete creata ad hoc per l’attacco:
Lanciamo dunque lo script di Mathy Vanhoef:
./krack-test-client.py
Osservando l’output del terminale, vediamo come la versione obsoleta di ParrotSec si sia rivelata vulnerabile:
Come già anticipato, l’attacco dovrebbe proseguire deautenticando il client dalla rete iniziale per poi costringerlo a riautenticarsi alla rete clone dell’attaccante. Quest’ultimo avrà furbescamente predisposto diversi sniffer di rete in ascolto oltre al temibile sslstrip che, seppur inefficace contro siti che richiedono il protocollo HSTS, è tra i primi strumenti da sfoderare per l’intercettazione di traffico e credenziali ‘over HTTPS’. Purtroppo però, a dispetto del video dimostrativo postato sul sito web del progetto
non è possibile portare a termine l’attacco attraverso lo script rilasciato. Essendo una vulnerabilità proof of concept, probabilmente non si vogliono ancora divulgare informazioni più dettagliate a tal riguardo. Come quasi sempre succede, sarà solo questione di tempo affinché si diffondano tutorial e guide su come portare a termine la procedura. Per il momento dobbiamo limitarci a capire se i nostri devices (router compresi) siano potenzialmente esposti a questo attacco. Troviamo un valido elenco aggiornato su:
https://github.com/kristate/krackinfo
Come è possibile vedere dal paper ufficiale, i sistemi che presentano la vulnerabilità sono prevalentemente Linux, OpenBSD e Android mentre sembrano cavarsela egregiamente Windows e iOS, che seguono altri standard.
Vediamo invece come utilizzando una versione di LinuxMint aggiornata e uno smartphone Android Nougat 7.0, il test risulti negativo solo per il primo:
Da sottolineare inoltre che la creazione di una password di rete più complessa non serve a mitigare l’attacco, in quanto non viene compromessa durante la sua esecuzione. È il punto chiave di questa nuova vulnerabilità: si riesce ad instaurare un MITM (man in the middle ) senza dover scomodare gravosi attacchi bruteforce o dizionario per tentare di indovinare password di rete. Ciò che è opportuno fare invece, è tenere aggiornati i propri dispositivi con le ultime patch rilasciate per l’occasione.
Non è tutto: è bene precisare che anche i propri router dovrebbero essere aggiornati con gli ultimi firmware, dal momento che un potenziale attacco lanciato su un AP vulnerabile avrebbe conseguenze anche su dispositivi non vulnerabili; fa parte del progetto KRACK anche lo script dedicato ai router krack-ft-test, il cui principio di funzionamento è simile a quello visto per i client: rimando dunque all’help del programma per la sua esecuzione pratica.
Per concludere, la vulnerabilità di Mathy Vanhoef è parecchio grave e farà discutere ancora molto. Sebbene non debba (ancora) generare ansie e paronoie all’utilizzatore medio di apparecchiature Wi-Fi (ricordiamo che un potenziale malintenzionato deve trovarsi fisicamente vicino agli apparecchi della vittima per compiere gli attacchi), dovrebbe invece sollevare diversi interrogativi a compagnie e strutture che non utilizzano comunicazioni cablate o che hanno in passato sofferto di attacchi informatici e furti di dati. È buona norma comunque avvalersi di protocolli sicuri quali il già citato HTTPS per siti web, autenticazioni a due fattori per i login, StartTLS per le email (o SSL/TLS in caso il provider non lo supporti), SSH per sessioni remote da riga di comando e non esitare a implementare reti VPN per le proprie infrastrutture.
A cura di: Milo Caranti
Dopo aver frequentato la facoltà di Giurisprudenza, lavora attualmente come programmatore e svolge attività consulenziale per uno studio legale di Milano. Da sempre appassionato di Sicurezza informatica e vicino alle attuali tematiche in ambito ICT, è autore del libro ”Guida al Pentesting con Parrot Security OS”.
