Vettori di Attacco Avanzati e Vulnerabilità dei Protocolli

KRACK e Fast Transition: Replay dell'Handshake

L'attacco Key Reinstallation Attack (KRACK) sfrutta il 4-way handshake di WPA2 non attraverso una rottura crittografica, ma manipolando la macchina a stati stessa. Quando un supplicant riceve il messaggio 3 dell'handshake, installa la Pairwise Temporal Key (PTK) e azzera il contatore nonce a zero. Un attaccante che opera un man-in-the-middle basato sul canale ritrasmette questo messaggio 3; il client, obbedendo al diagramma di stato 802.11, reinstalla la stessa PTK e resetta il nonce.

La matematica è brutalmente efficace. La modalità CCMP di WPA2 utilizza AES in modalità contatore: Ciphertext = Plaintext ⊕ AES(Key, Nonce || Counter). Il riutilizzo di (Key, Nonce) con plaintext diversi produce: C₁ ⊕ C₂ = P₁ ⊕ P₂. Il keystream si annulla. Un attaccante che conosce o può indovinare un plaintext—header di protocolli comuni, richieste DHCP prevedibili—recupera l'altro per intero.

Il Fast Transition (802.11r) aggrava la situazione memorizzando nella cache le chiavi PMK-R0/PMK-R1 tra gli AP. L'handshake FT salta completamente lo scambio 4-way, utilizzando un singolo frame di autenticazione. La variante FT di KRACK reinstalla la chiave durante la riassociazione, ottenendo il reset del nonce in un singolo round trip anziché richiedere la danza completa della ritrasmissione del messaggio 3.

Verifica in laboratorio con strumenti di test mantenuti:

# Clona ed esegui la valutazione della vulnerabilità KRACK (solo test difensivi)
git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack/
# Richiede una NIC compatibile in modalità monitor; consulta la documentazione del repo per i requisiti del chipset

# Testa la suscettibilità del client alla reinstallazione della chiave (osservazione passiva + ritrasmissione mirata)
python2 krack-test-client.py --help

Cosa fa: Valuta se un client o un AP rileva e rifiuta correttamente i messaggi di handshake ritrasmessi. Lo script opera come rogue AP con MitM sul canale, registrando se la vittima reinstalla le chiavi su ritrasmissione forzata. Quando usarlo: Validazione hardware pre-deployment, test di regressione post-patch, incident response per confermare eventi sospetti di riutilizzo nonce. Rischi: Il test comporta la creazione di un rogue AP funzionale; isolare in laboratorio schermato RF o VLAN dedicata per prevenire la cattura accidentale di client. Output atteso: [+] Client is vulnerable to key reinstallation attacks o [-] Client rejected retransmitted message 3; quest'ultimo indica comportamento patchato in cui il client traccia lo stato di ricezione del messaggio 3 e ignora i duplicati.

Comportamento patchato: I client devono tracciare se il messaggio 3 è già stato ricevuto e processato; i duplicati devono essere scartati prima dell'installazione della chiave. Windows e iOS hanno implementato questo in modo stateful; molte distribuzioni Linux hanno richiesto wpa_supplicant 2.6+ con flag esplicite. La patch non cambia il protocollo—restringe la finestra di implementazione.

Errori comuni	Perché ti colpisce
Testare solo con strumenti lato AP	La reinstallazione della chiave lato client è il percorso critico per la decrittazione dei dati; il compromesso lato AP avvelena solo il downstream
Utilizzare build obsolete di wpa_supplicant	Le versioni pre-2.6 non dispongono della correzione della macchina a stati dell'handshake; i pacchetti delle distribuzioni possono essere in ritardo
Ignorare FT/802.11r nei deployment enterprise	FT è abilitato di default su molti controller enterprise; il percorso di attacco è più veloce del KRACK di base
Assumere la sicurezza di AES-CCMP	Il riutilizzo del nonce rompe la modalità CTR catastroficamente indipendentemente dalla robustezza della chiave AES

FragAttacks: Difetti di Progettazione nella Riassemblazione dei Frammenti

I FragAttacks (CVE-2020-24586, CVE-2020-24587, CVE-2020-24588) rivelano che i meccanismi di frammentazione e aggregazione dell'802.11 sono stati specificati senza contesto di sicurezza. Lo standard non impone la cancellazione delle code di frammenti alla disconnessione/riconnessione del client. Un dispositivo che si riconnette a una rete controllata dall'attaccante trova frammenti obsoleti in memoria; frammenti iniettati possono essere concatenati con quelli legittimi, o un attaccante può forgiare un pacchetto completo utilizzando solo la sovrapposizione dei numeri di sequenza.

Il bug di riassemblaggio opera al di sotto dei confini di crittografia WPA2/WPA3. Un attaccante invia frammenti che, quando combinati con la memoria in coda, formano un frame valido che lo stack superiore interpreta come plaintext o come superamento dei controlli di integrità. Poiché i frammenti MAC 802.11 avvengono prima della decrittazione e della riassemblazione, le protezioni dei livelli superiori (IPsec, TLS, crittografia applicativa) vedono un singolo frame "valido" che non possono attribuire a composizione malevola.

Tre sottoclassi contano operativamente:

Attacco di aggregazione: I frame A-MSDU portano un flag di sottoframe "is first/last". L'A-MSDU-in-A-MPDU opzionale dello standard permette di iniettare un A-MSDU dove il ricevitore tratta il payload controllato dall'attaccante come appartenente a una sessione cifrata.
Riassemblaggio misto di frammenti plaintext/crittografati: Se il primo frammento è in plaintext e il secondo crittografato, alcune implementazioni li combinano, decrittando solo la seconda porzione e passando il risultato combinato verso l'alto.
Iniezione di frame di grandi dimensioni: I frame riassemblati superano i limiti MTU tipici, causando overflow delle ipotesi sui buffer negli stack di rete.

Test difensivo:

# Suite di test FragAttacks — valuta implementazioni client e AP
git clone https://github.com/vanhoefm/fragattacks.git
cd fragattacks/research/

# Compila il firmware di test per NIC USB supportate (ath9k_htc, mt76, ecc.)
# Consulta il README del repo per la compatibilità del firmware; non tutti i chipset espongono l'iniezione raw
make

# Esempio: Testa il comportamento di riassemblaggio dei frammenti dopo riconnessione simulata
# Richiede due radio: una per l'AP legittimo, una per l'iniezione
python3 fragattack.py --ap --iface wlan0 --test test-reassembly

Cosa fa: Inietta sequenze di frammenti creati ad arte e monitora se il target li riassembla in frame passati allo stack superiore. I test coprono sia la variante "dimenticare di cancellare la memoria" che la variante "plaintext/crittografato misto". Quando usarlo: Validazione firmware per deployment IoT, valutazioni di sicurezza vendor di access point, conferma che i dispositivi "certificati WPA3" gestiscano effettivamente i frammenti in modo sicuro. Rischi: Alcuni test causano il crash di dispositivi target vulnerabili; non eseguire mai contro infrastrutture di produzione senza finestre di manutenzione e piani di ripristino da crash. Output atteso: VULNERABLE: reassembled injected fragment o NOT VULNERABLE: fragment dropped; quest'ultimo indica comportamento patchato in cui le code di frammenti vengono esplicitamente cancellate alle transizioni di stato e i frammenti non consecutivi vengono rifiutati.

Il comportamento patchato richiede tre correzioni indipendenti: cancellare le code di frammenti alla (ri)connessione, richiedere che i frammenti crittografati seguano esclusivamente frammenti crittografati, e limitare le dimensioni dei frame riassemblati. La vulnerabilità a livello di specifica significa che le patch sono dipendenti dall'implementazione; nessuna revisione del protocollo ha ancora proibito completamente le costruzioni pericolose.

Dragonblood e Side-Channel di WPA3-SAE

Il Simultaneous Authentication of Equals (SAE) di WPA3, chiamato anche Dragonfly, è stato progettato come PAKE resistente agli attacchi offline di dizionario. Il protocollo utilizza un ciclo di hunting-and-pecking per convertire una password in un punto della curva, poi esegue uno scambio in stile Diffie-Hellman con maschere derivate da password statica.

Gli attacchi Dragonblood (Vanhoef/Ronen, Black Hat USA 2019) hanno dimostrato che questo design, quando implementato, perde informazioni attraverso side-channel di timing e cache. Il numero di iterazioni del ciclo di hunting-and-pecking dipende dai byte della password; misurare il tempo di esecuzione o i pattern di accesso alla cache rivela informazioni sulla password. Gli attacchi non sono contro la matematica di Dragonfly ma contro il programma che la calcola.

Operativamente, esistono due percorsi:

Attacco di timing: Il ciclo impiega iterazioni variabili per trovare un punto valido della curva. Un attaccante remoto misura i tempi di risposta SAE attraverso multipli messaggi di commit, recuperando statisticamente la password.
Attacco di cache: In ambienti multi-utente o virtualizzati, un processo non privilegiato monitora le linee di cache toccate durante il ciclo di hunting-and-pecking, ricostruendo lo stato segreto.

La variante side-channel cache è particolarmente perniciosa per i deployment enterprise EAP-pwd dove i server RADIUS gestiscono l'autenticazione su larga scala—un attaccante con qualsiasi accesso a livello utente sull'host di autenticazione può attaccare tutte le sessioni SAE concorrenti.

Analisi orientata al rilevamento del timing SAE:

# Non esiste rilascio pubblico di exploit; il rilevamento si basa sull'analisi statistica del timing
# Cattura i frame di commit SAE e misura la varianza dei tempi di risposta

# Esempio con tshark per l'estrazione dei frame, poi analisi statistica
tshark -r capture.pcap -Y "wlan.fc.type_subtype == 11" -T fields \
  -e frame.time_relative -e wlan.sa -e wlan.da \
  -E header=y > sae_commits.csv

# Analizza con Python/scipy per la varianza del timing per sorgente
python3 -c "
import pandas as pd, scipy.stats as stats
df = pd.read_csv('sae_commits.csv')
# Raggruppa per indirizzo sorgente, testa la distribuzione uniforme della risposta
for src, group in df.groupby('wlan.sa'):
    _, p = stats.kstest(group['frame.time_relative'].diff().dropna(), 'uniform')
    print(f'{src}: uniformity p-value = {p:.4f}')
"

Cosa fa: Estrae i timestamp dei frame di commit SAE e testa se il timing di risposta segue una distribuzione uniforme (atteso per implementazioni a tempo costante) o mostra struttura (indicando hunting-and-pecking a tempo variabile). Quando usarlo: Valutazione di sicurezza vendor del firmware AP WPA3, verifica di hardening del server RADIUS EAP-pwd. Rischi: L'analisi del timing richiede condizioni di rete controllate; canali congestionati producono struttura falsa. Eseguire durante periodi di bassa utilizzazione o ambienti RF isolati. Output atteso: P-value elevati (>0.05) suggeriscono comportamento a tempo costante; p-value bassi raggruppati su multiple sorgenti indicano perdite di timing lato implementazione.

Il lavoro di verifica formale (EuroS&P 2023, "Dragondoom") ha da allora dimostrato che esistono implementazioni corrette a tempo costante, ma la certificazione non le impone. Un'etichetta "WPA3 certified" garantisce la conformità al protocollo, non la resistenza ai side-channel. Chiedere esplicitamente ai vendor implementazioni SAE a tempo costante con hunting-and-pecking sicuro per le linee di cache.

Cattura PMKID: RSN IE Senza Associazione Client

L'attacco di cattura PMKID (modalità Hashcat 16800/16801) estrae il PMKID dagli RSN Information Elements nei frame beacon e probe response dell'AP. Il PMKID è HMAC-SHA1-128(PMK, "PMK Name" || MAC_AP || MAC_STA). Per un MAC STA noto (il proprio dell'attaccante), questo si riduce al cracking diretto della PMK—nessuna cattura del 4-way handshake, nessuna associazione client richiesta.

L'efficienza dell'attacco dipende dalla configurazione dell'AP. Molti controller enterprise e router consumer abilitano FT over-the-air o FT over-the-DS, che pre-calcolano il PMKID per il roaming veloce. L'RSN IE trasmette questo valore in chiaro. Un singolo frame di cattura è sufficiente per il cracking offline del PMK, bypassando completamente il tradizionale requisito dell'EAPOL 4-way.

# Laboratorio: Cattura PMKID con hcxdumptool
# Richiede una NIC in modalità monitor compatibile (consulta l'ultima release per il supporto dei chipset)

hcxdumptool -i wlan0mon -o capture.pcapng --active_beacon --enable_status=95

# In parallelo o successivamente, filtra per frame contenenti PMKID
hcxpcapngtool -o hash.16800 capture.pcapng

# Cracking con hashcat se la cattura ha avuto successo (test password solo in laboratorio)
hashcat -m 16800 hash.16800 -a 3 -w 3 '?l?l?l?l?l?l?l?l'

Cosa fa: hcxdumptool invia probe request e cattura le risposte contenenti RSN IE; hcxpcapngtool estrae gli hash PMKID in formato compatibile con Hashcat. Quando usarlo: Verificare se i propri AP espongono il PMKID a stazioni non associate; verificare che le configurazioni okc (Opportunistic Key Caching) e ft_psk_generate_local non perdano materiale craccabile. Rischi: Il probing attivo con hcxdumptool può interrompere le associazioni dei client; il flag --active_beacon genera rumore sul canale. Variante laboratorio: Usare antenna direzionale, durata breve, AP di test dedicato. Variante produzione: Osservazione passiva con airodump-ng --write per periodo esteso, nessun probe iniettato. Output atteso: PMKID written to hash.16800 indica configurazione AP vulnerabile; nessun PMKID nell'output suggerisce che l'RSN IE omette il campo o richiede l'associazione prima.

Mitigazione: Disabilitare ft_over_the_air e ft_over_the_ds se non richiesti; configurare pmk_r1_push per evitare la pre-derivazione del PMKID per STA non autenticate; filtrare l'RSN IE nei frame beacon per escludere il PMKID per client non associati (dipendente dall'implementazione, consultare la documentazione del vendor).

KARMA, MANA e Sfruttamento del Probing Proattivo

I client configurati con SSID nascoste o preferred network lists (PNL) inviano directed probe request contenenti i nomi degli SSID in plaintext. Gli attacchi KARMA rispondono a tutti i directed probe con beacon corrispondenti, ingannando il client in auto-associazione. MANA estende questo priorizzando le risposte basate sulla frequenza di probe osservata—attaccando prima i client più mobili, più disperati.

Il fallimento di protocollo fondamentale: le probe request sono non autenticate e non crittografate. Un client non può distinguere il ripristino della rete domestica legittima dalla impersonazione malevola. Anche WPA3-SAE non risolve questo; l'SSID è esposto prima che qualsiasi scambio SAE inizi.

Il rilevamento richiede il monitoraggio del proprio comportamento client:

# Identifica se i dispositivi client stanno trapelando probe dei tuoi SSID aziendali o domestici
airodump-ng wlan0mon --output-format csv -w probe_survey

# Analizza: cerca il tuo SSID nelle righe di Probe Request, non solo nei Beacon
grep -i "CorpNet" probe_survey-01.csv | head -5

Cosa fa: Registra passivamente tutte le probe request nel raggio radio. L'output rivela se i dispositivi pubblicizzano nomi di rete sensibili in plaintext. Quando usarlo: Valutazione di sicurezza BYOD, incident response a deployment sospetti di evil twin, pre-hardening della configurazione di flotte di dispositivi mobili. Rischi: Il monitoraggio passivo è a basso rischio; la preoccupazione è ciò che scopri. Se i laptop degli executive trasmettono Boardroom-Secure o M&A-VPN, questo è un risultato azionabile. Output atteso: Righe CSV con tipo Probe Request e campo ESSID; la comparsa qui dei tuoi SSID sensibili indica client che si assoceranno con qualsiasi rispondente corrispondente.

Hardening: Disabilitare la connessione automatica alle reti non broadcast (netsh wlan set profileparameter name=CorpNet connectionMode=manual su Windows; rimuovere le voci PNL su macOS/iOS; NetworkManager auto_connect=FALSE su Linux). Per enterprise: deploy di 802.11u/Hotspot 2.0 con selezione di rete basata su certificati, eliminando completamente il probing basato su SSID.

Distance-Bounding, Relay e Considerazioni sul Firmware NIC

I protocolli Wi-Fi Time-of-Flight (ToF) e Fine Timing Measurement (FTM), specificati in 802.11mc/az, abilitano il ranging per il posizionamento indoor. Gli attacchi relay contro questi protocolli sono concettualmente semplici: un man-in-the-middle estende il percorso RF senza aggiungere ritardo rilevabile, facendo apparire locale un attaccante lontano. I protocolli di distance-bounding dovrebbero prevenirlo richiedendo rapidi scambi challenge-response dove i ritardi alla velocità della luce limitano la distanza massima.

Il contro-misura specificata dal protocollo è crittograficamente solida, ma le implementazioni del firmware NIC raramente raggiungono la precisione di timing al nanosecondo richiesta. Bug del firmware in chipset Qualcomm, Broadcom e Intel hanno permesso estensioni di relay oltre i massimi teorici manipolando i timestamp delle richieste FTM in campi controllati dal driver prima dell'elaborazione hardware.

Le vulnerabilità a livello firmware e driver si estendono oltre il ranging. Bug di riassemblaggio dei frammenti in specifiche implementazioni A-MPDU (patchati in Linux mac80211 su multipli cicli) hanno permesso corruzione di memoria perché il descriptor ring DMA hardware e la coda software SKB si desincronizzavano. Queste non sono vulnerabilità di protocollo ma vulnerabilità di implementazione nel percorso di protocollo—non patchabili da revisione dello standard, solo da azione del vendor.

Checklist di verifica per la postura del firmware:

Controllo	Metodo	Indicatore di fallimento
Monotonicità del timestamp FTM	`iw phy0 measurement ftm_request` con responder locale, confronta il ToF riportato rispetto alla distanza fisica	La distanza riportata varia >20% con geometria fissa
Riassemblaggio frammenti sotto carico	`fragattacks` `test-reassembly-stress` con 1000+ iniezioni di frammenti al secondo	Kernel oops o reset NIC in `dmesg`
Versione driver contro database CVE	`ethtool -i wlan0` o `modinfo mac80211`, cross-reference con la mailing list Linux wireless	Driver precedente al commit di fix noto senza notazione di backport
Varianza timing SAE	Test statistico sopra, o build `hostapd` con `-DWPA_TRACE` per log di timing interni	Deviazione standard >10% del tempo di risposta medio

⚠️ Solo uso autorizzato e difensivo. La manipolazione FTM e lo stress testing dei frammenti possono causare crash dei dispositivi target o corrompere il loro stato wireless. Eseguire solo in ambienti di laboratorio isolati con accesso alla console seriale per il ripristino, o in esercizi esplicitamente autorizzati di validazione del rilevamento con scope documentato.

L'insight pratico: la certificazione del protocollo e le patch CVE operano su orologi diversi. Un dispositivo può essere "WPA3 certified" e "KRACK patched" pur rimanendo vulnerabile a crash di riassemblaggio frammenti in firmware mai sottoposto ad audit dal programma di certificazione. L'unica validazione affidabile è il testing diretto del proprio specifico hardware revision con strumenti mantenuti—fidarsi delle etichette è una complacenza che gli avversari non condividono.