5. Frame e interazione di rete
Quando i dispositivi si connettono alle reti Wi-Fi e le informazioni fluiscono attraverso la rete, vengono utilizzati diversi tipi di frame per garantire che tutto passi nel modo più efficiente possibile. Catturare e analizzare questo traffico sarà fondamentale per comprendere e sfruttare le reti Wi-Fi.
In questo modulo, inizieremo a comprendere meglio i frame utilizzati nelle reti Wi-Fi, incluse le loro intestazioni e i loro campi. Impareremo anche come i dispositivi wireless interagiscono con vari tipi di reti.
Raccomandiamo agli studenti di procedere lentamente attraverso questo contenuto e di prendersi il tempo necessario. In particolare, raccomandiamo di ispezionare ogni file di cattura prima di proseguire. Gli studenti possono anche tornare a questo modulo per riferimento futuro.
Durante questo modulo ispezioneremo diversi file con Wireshark. Ad esempio, quando discutiamo i Beacon frame, ispezioneremo un file Pcap con Beacon frame. Alcune sezioni di questo modulo iniziano indicando un file di riferimento disponibile. Per scaricare il file, seguire il link nella nota a piè di pagina.
Questo modulo presenta un'eccellente opportunità per diventare ancora più a proprio agio con Wireshark seguendo il contenuto. In alcuni casi, potremmo concentrare la nostra attenzione su un particolare frame o su una serie di frame.
5.1. Pacchetti vs frame
Pacchetti e frame non sono termini intercambiabili. Per comprenderli meglio, può essere utile rivedere rapidamente il modello Open Systems Interconnection (OSI), che è un modello concettuale di come i sistemi comunicano su una rete. Una spiegazione completa è al di fuori dell'ambito di questo modulo, ma una spiegazione sommaria potrebbe essere utile.
| Layer | Descrizione |
|---|---|
| 7. Application Layer | Livello di interazione uomo-computer, dove le applicazioni possono accedere ai servizi di rete |
| 6. Presentation Layer | Garantisce che i dati siano in un formato utilizzabile ed è dove avviene la crittografia dei dati |
| 5. Session Layer | Mantiene le connessioni ed è responsabile del controllo delle porte e delle sessioni |
| 4. Transport Layer | Trasmette i dati usando protocolli di trasmissione tra cui TCP e UDP |
| 3. Network Layer | Decide quale percorso fisico seguiranno i dati |
| 2. Data Link Layer | Definisce il formato dei dati sulla rete |
| 1. Physical Layer | Trasmette il flusso di bit grezzi sul mezzo fisico |
Tabella 1 - Il modello OSI
Ogni livello nel modello OSI è impilato e ha uno scopo specifico. Ad esempio, il livello Data Link è dove esistono le intestazioni MAC. Queste intestazioni aiutano a determinare dove deve andare il pacchetto mentre viaggia tra due dispositivi sulla stessa rete.
Quando catturiamo pacchetti, li catturiamo al livello Data Link, che include il frame. Il frame contiene l'autenticazione nonché informazioni aggiuntive sull'AP. La cattura dei pacchetti è generalmente il punto di partenza per tutti gli altri vettori di attacco Wi-Fi, quindi comprendere i pacchetti, e i frame in particolare, è un ottimo punto di partenza.
Un pacchetto è l'unità dati del protocollo per il livello di rete (3), e un frame è un'unità nel livello data link (2). La packet capture è in realtà un termine improprio perché alcuni hardware possono catturare al livello 3, ma a volte anche al livello 2. Alcuni strumenti specializzati possono anche operare al livello 1.
Nonostante ciò, "Packet Capture" è diventato un termine comune per i dati catturati al livello 2 o 3. Nel nostro caso, tutte le nostre catture e la maggior parte degli strumenti che useremo operano al livello 2.
5.2. Frame MAC 802.11
Iniziamo rivedendo la struttura di base di un frame MAC 802.11 nella Figura 1.
Figura 1: Frame MAC 802.11
La struttura è divisa in tre parti. Per prima cosa, il MAC Header contiene campi comuni per quasi tutti i frame. I primi campi sono obbligatori. Altri possono essere presenti a seconda del frame specifico.
Poi, il Frame body trasporta dati o contiene informazioni aggiuntive. Non tutti i frame useranno questa sezione.
Infine, il Frame Check Sequence (FCS) è il Cyclic Redundancy Check (CRC) del frame wireless corrente. Un CRC viene eseguito su tutti i campi precedenti per generare l'FCS. L'FCS del frame viene ricalcolato una volta che il frame arriva a destinazione. Se è identico a quello ricevuto, allora il frame è stato ricevuto senza errori. A volte non è presente nei frame catturati.
Warning
Nei file di cattura, a volte le intestazioni Radiotap precedono l'intestazione MAC. Queste intestazioni sono inserite dal driver sul ricevitore e contengono metadati per il frame specifico, incluso il livello del segnale, il rate, il canale su cui è stato ricevuto e altre informazioni. Il contenuto e la dimensione variano da un driver all'altro e a volte da un frame all'altro.
5.2.1. Intestazione MAC
L'immagine seguente mostra i dettagli del campo Header di un frame MAC 802.11.
Figura 2: Intestazione MAC 802.11
L'intestazione MAC contiene diversi campi, e alcuni di essi sono successivamente suddivisi in sezioni più piccole. Esploreremo i più importanti e spiegheremo brevemente il contenuto di ciascun campo.
5.2.2. Frame Control Field
- Protocol Version - Questo campo fornisce la versione del protocollo 802.11 utilizzato. Questo valore è attualmente 0.
- Type - Il type è il campo più importante nel frame e determina la funzione del frame, nonché la presenza di altri campi nel frame. Esistono quattro diversi tipi di frame con valori corrispondenti: management (0), control (1), data (2) ed extension (3). Copriremo i primi tre più avanti in questo modulo. Il quarto è un'eccezione rara, quindi non lo tratteremo.
- Subtype - Ogni tipo di frame può avere uno dei diversi valori del campo subtype. Questi determinano la funzione specifica e definiscono il payload.
- To DS e From DS - Questi campi indicano se il frame sta entrando in un distribution system (ToDS) o uscendo dal distribution system (FromDS).
- More frag - Questo campo indica se seguiranno altri frammenti del frame dopo questo.
- Retry - Il campo retry ci dice se il frame viene ritrasmettuto. Una ritrasmissione avviene quando i frame unicast non vengono confermati in tempo.
- Power Mgmt - Questo ci mostrerà se il client mittente è in modalità attiva (0) o in modalità risparmio energetico (1).
- More data - Questo campo indica se ci sono dati in buffer per un client.
- Protected Frame - Questo rivelerà se nel frame vengono usati crittografia o autenticazione.
- +HTC/Order - Questo campo ci dice se il frame contiene un HT Control Field. In alcune rare istanze, viene usato per indicare che il frame viene inviato usando la classe di servizio Strictly-Ordered.
5.2.3. Duration/ID
A seconda del tipo e del sottotipo del frame, Duration/ID può avere un significato diverso. Nei frame Power-Save Poll (tipo 1, sottotipo 10), contiene l'Association Identity (AID) del client nei 14 bit meno significativi. I due bit più significativi sono impostati. Quando richiesto, Duration/ID è la durata del frame in microsecondi. In alcune istanze, ha un valore fisso di 32768.
5.2.4. Indirizzi
La tabella seguente rappresenta i diversi casi di questi indirizzi, a seconda dei bit From/To DS nel Frame Control field.
| FromDS | ToDS | Address 1 | Address 2 | Address 3 | Address 4 |
|---|---|---|---|---|---|
| 0 | 0 | Destination Address | Source Address | BSSID | n/a |
| 0 | 1 | BSSID | Source Address | Destination Address | n/a |
| 1 | 0 | Destination Address | BSSID | Source Address | n/a |
| 1 | 1 | Recipient Address | Transmitter Address | Destination Address | Source Address |
Tabella 2 - Significato dei 3 o 4 indirizzi in base ai valori ToDS e FromDS
Il primo caso, dove ToDS e FromDS sono entrambi impostati a 0, si verificherà in modalità IBSS (ad-hoc) o quando il frame è un frame di gestione o di controllo. I bit FromDS e ToDS non sono impostati come nel caso in cui due client comunicano direttamente tra loro, ma questo è raramente il caso al giorno d'oggi.
Quando solo ToDS è impostato, il traffico proviene da un client ed è destinato all'AP o a qualsiasi cosa connessa ad esso. Questo sarebbe il caso con un ping (richiesta ICMP).
Quando solo FromDS è impostato, il traffico va dall'AP al client. Richiamando l'esempio precedente, questa sarebbe una risposta al ping.
Quando entrambi sono impostati, indica che siamo in modalità WDS. In questo caso, un AP sta parlando con un altro, motivo per cui il quarto campo indirizzo è presente nel frame.
5.2.5. Sequence Control
Il campo Sequence Control consiste in due sottocampi ed è usato per riconoscere la duplicazione dei frame.
Il sottocampo Sequence Number (12 bit) indica il numero di sequenza di ogni frame. Il numero di sequenza è lo stesso per ogni frame inviato per un frame frammentato. L'intervallo di valori per questo campo è 0-4095. Quando raggiunge 4095, la sequenza successiva sarà 0.
Il sottocampo Fragment Number (4 bit) indica il numero di ciascun frammento di un frame inviato. L'intervallo di valori per questo campo è 0-15.
5.2.6. Campi QoS control e HT Control
La presenza dei campi QoS control e HT Control dipende da altri valori nel frame body. Il QoS Control è presente solo nei frame dati Quality of Service (QoS) per indicare i parametri di qualità del servizio. L'HT Control è presente solo se il bit +HTC/Order è impostato.
5.3. Tipi di frame
Esploriamo la struttura dei frame comuni che incontreremo sulle reti Wi-Fi. Man mano che procediamo, ispezioneremo un esempio per ciascuno di essi. In particolare, ci concentreremo sugli aspetti dei tipi di frame che aiutano a descrivere come i dispositivi interagiscono tra loro.
Esamineremo i frame di gestione, di controllo e di dati. Esiste un quarto tipo di frame, i frame extension, ma non è molto comune, quindi lo salteremo.
5.3.1. Frame di gestione
I frame di gestione sono usati per negoziare e controllare la relazione tra AP e client. La tabella seguente illustra i diversi tipi di frame di gestione wireless.
| Subtype | Field Description |
|---|---|
| 0 | Association Request |
| 1 | Association Response |
| 2 | Re-association Request |
| 3 | Re-association Response |
| 4 | Probe Request |
| 5 | Probe Response |
| 6 | Measurement Pilot |
| 7 | Reserved |
| 8 | Beacon |
| 9 | ATIM |
| 10 | Disassociation |
| 11 | Authentication |
| 12 | Deauthentication |
| 13 | Action |
| 14 | Action No ACK |
| 15 | Reserved |
Tabella 3 - Sottotipi dei frame di gestione
Copriremo i frame comuni incontrati sulle reti wireless. Tutti questi frame hanno la stessa struttura del frame MAC 802.11 di base. Il payload varia a seconda del sottotipo.
5.3.2. Beacon
Questa sezione include un file di riferimento, beacon.pcap, nella sezione Resources.
I Beacon frame sono i frame più comuni poiché vengono inviati circa 10 volte al secondo. I beacon sono trasmessi in broadcast dall'AP per mantenere la rete sincronizzata.
Questi frame contengono informazioni utili sulla rete come il nome della rete (a meno che l'SSID non sia nascosto), il canale, i data rate disponibili, il tipo di crittografia e il dominio normativo. Sono tipicamente inviati al basic rate più basso per raggiungere i client più lontani dall'AP.
La struttura di un Beacon frame è la seguente.
Figura 3: Struttura del Beacon frame
Warning
Sebbene SSID e ESSID siano usati in modo intercambiabile negli strumenti Wi-Fi e nella configurazione dell'AP, c'è una piccola differenza. SSID è per singoli AP. ESSID è quando più AP in un Extended Service Set (ESS) condividono lo stesso SSID. Il nome ufficiale del campo nei frame di gestione è SSID.
Le informazioni nel payload del frame sono divise in due parti. La prima parte contiene parametri fissi, che rimarranno sempre gli stessi.
Il primo parametro include Timestamp, che contiene un valore di 8 byte per una Timing Synchronization Function (TSF). Beacon interval indica la frequenza con cui vengono inviati i beacon. È espresso in Time Units (TU) dove 1 TU è 1,024 ms. Capabilities information è suddiviso in 14 flag.
Il secondo parametro è dinamico e la quantità di informazioni incluse dipenderà dall'AP. Gli Information Elements (IE) sono di dimensione variabile, ma hanno una struttura comune. Il primo byte indica l'ID dell'elemento e descrive come viene interpretato il payload. Il secondo indica la lunghezza del campo seguente (payload IE), che ha una lunghezza massima di 255 byte.
Figura 4: Struttura IE del frame di gestione
Gli Information Elements sono solitamente disposti in ordine in base all'ID. In casi speciali, alcuni ID sono condivisi tra più elementi, quindi il loro significato dipende anche dai primi byte nel payload dell'IE. Un buon esempio è WPA TKIP, dove dipende dai primi tre byte nel payload. L'altro caso speciale è l'Element ID Extension, che dipende dal valore del primo byte del suo payload. Questo è usato per le informazioni 802.11ax tra le altre cose.
Sebbene questa sezione sia dinamica, alcuni elementi come l'SSID saranno sempre presenti. La Figura 5 include l'elemento SSID, che ha un ID di 0. La lunghezza del campo è 8 ed è denominato supafast.
Figura 5: Elemento SSID
Un altro campo da notare nella cattura sono i Supported Rates dell'AP. Mostra rate da 6 a 54 Mbit/s, il che, da solo, indica una rete 802.11g o 802.11a.
Figura 6: Supported Rates
Una rete 802.11b o mista 802.11b/g avrebbe questi rate tra 1 e 11. Una rete mista 802.11b/g avrà anche extended supported rates tipicamente tra 6 e 54, ma questo non è il caso negli extended rates sotto.
Figura 7: Extended Supported Rates
Il numero del canale, 36, indica che la rete opera nella banda 5 GHz.
Figura 8: Numero del canale
L'elemento country indica il dominio normativo, la disponibilità dei canali e la potenza di trasmissione. I client a volte lo usano per migliorare ulteriormente la loro conformità. Su Linux questo è chiamato "beacon hinting".
Figura 9: Informazioni country
Su questo particolare AP, il dominio normativo è impostato su US. Fornisce un set di canali, nonché la potenza di trasmissione massima. Otto canali sono disponibili a una potenza di trasmissione di 23 dBm, a partire dal canale 36 (40, 44, 48, 52, 56, 60 e 64). Ci sono 11 canali a partire da 100 con 23 dBm (104, 108, 112, 116, 120, 124, 128, 136 e 140). Ci sono cinque canali a partire da 149 con 30 dBm (153, 157, 161 e 165). Il motivo per cui non fornisce numeri di canale precisi per ognuno è perché nella banda 5 GHz sono sempre separati da 20 MHz, che corrisponde a 4 canali di distanza, e non si sovrappongono.
Gli elementi HT Capabilities e HT Information indicano se l'AP supporta High Throughput (HT), o 802.11n, e includono altre informazioni rilevanti.
Figura 10: HT Capabilities e HT Information
Due elementi, VHT Capabilities e VHT Operation, indicano la presenza di Very High Throughput (VHT), o 802.11ac, e le funzionalità supportate. Un altro campo con nome simile, VHT Tx Power Envelope, aiuta a migliorare ulteriormente la conformità normativa.
Figura 11: VHT Capabilities e VHT Operation
Questo AP supporta anche canali da 80 MHz, con un canale centrale a 42. Si estende dai canali 36 al 48, o da 5,170 GHz a 5,250 GHz. Se il secondo segmento centrato fosse compilato, supporterebbe canali da 160 MHz o 80+80 MHz. La differenza è se finisce per essere un 160 MHz contiguo o meno; 80+80 sono due canali da 80 MHz che non sono adiacenti.
Infine, gli elementi HE Capabilities e HE Operation indicano High Efficiency (HE), o 802.11ax, e le funzionalità supportate.
Figura 12: HE Capabilites e HE Operation
L'AP supporta 80 MHz in HE, come indicato da Rx and Tx MCS Map. Ha solo uno stream, come indicato dalla prima riga in Basic HE-MCS and NSS Set, con rate che usano MCS da 0 a 7, il che significa fino a 360 Mbit/s.
5.3.3. Probe
Questa sezione include un file di riferimento, airport-wifi-01_2_3.cap, nella sezione Resources.
I frame Probe sono usati per scansionare AP esistenti. Le probe request sono inviate dai client alla ricerca di AP e sono spesso inviate su più canali. Un AP risponderà con una probe response che contiene informazioni su se stesso.
Le probe request possono contenere criteri specifici, inclusi, ad esempio, crittografia e rate. Gli AP o i nodi ad-hoc (IBSS) risponderanno solo alle probe request che corrispondono a ciò che offrono. Quando la Probe request è diretta a un SSID specifico, solo l'AP con quell'SSID risponderà.
La struttura delle probe request e response è simile ai beacon. I payload delle probe request consistono solo di IE. La response, che proviene dall'AP, conterrà sia la stessa sezione statica sia la stessa sezione dinamica del beacon.
Una probe request conterrà almeno un IE SSID. Potrebbe contenerne di più, a seconda del dispositivo.
La cattura seguente include una broadcast probe request.
Figura 13: Broadcast Probe Request
Una probe response, dall'AP, segue la request.
Figura 13: Broadcast Probe Request
5.3.4. Authentication
Questa sezione include un file di riferimento, airport-wifi-01_24_26.cap, nella sezione Resources.
I frame Authentication sono usati quando ci si connette a un AP. Non esiste authentication request o response. Sia il client sia l'AP usano lo stesso frame di autenticazione.
Il payload contiene quattro campi.
Figura 14: Struttura del frame Authentication
All'interno di un frame di autenticazione, l'Authentication Algorithm identifica il tipo di autenticazione utilizzato. Il più comune è Open authentication, ma incontreremo anche Simultaneous Authentication of Equals, che è usato con WPA3, e in rari casi Shared Authentication, che è usato con WEP Shared Authentication.
Il processo di autenticazione consiste in diversi frame di autenticazione (il numero esatto di frame scambiati può variare). L'Authentication Transaction Sequence Number tiene traccia dello stato corrente del processo di autenticazione e sarà solitamente un valore tra 1 e 4.
Lo Status Code indica successo (0) o fallimento (altri valori). Oltre a 0, ogni valore indica un diverso tipo di fallimento.
Warning
Il filtraggio MAC è un ripensamento dei vendor e non fa parte dello standard 802.11. L'implementazione varia da un vendor all'altro. Quando il filtraggio MAC è abilitato sull'AP e l'indirizzo MAC del client non è autorizzato a connettersi, l'AP può rispondere o meno. Se risponde, può indicare un fallimento o un successo.
A seconda dell'algoritmo di autenticazione e del numero di sequenza, il frame a volte contiene dati dopo tutti questi campi. Il significato dei dati in questa sezione dipende dal valore dei campi authentication algorithm e authentication sequence.
Nella figura seguente, un client sta avviando una fase di open authentication con un AP.
Figura 15: Authentication
Il secondo frame include la risposta dall'AP.
Figura 16: Authentication Response
5.3.5. Association
Questa sezione include un file di riferimento, airport-wifi-01_28_30.cap, nella sezione Resources.
I frame Association sono usati per connettersi a un AP e sono sempre preceduti da frame di autenticazione. Il client invia un'association request, che è solitamente seguita da un'association response dall'AP.
Un frame association request ha la seguente struttura.
Figura 17: Struttura association request
Le capabilities sono identiche al Beacon frame. Il listen interval è espresso in TU e indica la frequenza con cui si sveglierà per ascoltare i beacon quando è in modalità risparmio energetico. Sebbene sia seguito da IE opzionali, un IE SSID, insieme a uno dei campi supported rates, sono richiesti per associarsi all'AP. Quando ci si connette a un AP con crittografia, i parametri di crittografia selezionati devono essere specificati anche in questo frame.
La figura seguente contiene un'association request per la rete "airport-wifi".
Figura 18: Association Request
Gli AP rifiutano o accettano un'Association Request con un'Association Response.
Warning
Quando il filtraggio MAC è attivo e l'indirizzo MAC non è autorizzato, il comportamento dell'AP può variare. Ignorerà o negherà il dispositivo.
L'Association Response ha la seguente struttura.
Figura 19: Struttura association response
La Figura 20 include un'association response riuscita come indicato dallo Status code.
Figura 20: Association Response
5.3.6. Deauthentication
Questa sezione include due file di riferimento:
- Airport wifi pcap
- aireplay-ng pcap
I frame Deauthentication invalidano l'autenticazione tra un client e un AP. Sebbene siano usati negli attacchi, si verificano anche quando un client si disconnette o quando l'AP forza il client a riautenticarsi per motivi di sicurezza.
La struttura del frame Deauthentication consiste in un campo di 2 byte nel frame body. Questo campo, il Reason Code, indica il motivo della deauthentication.
Nel frame seguente, il client si sta disconnettendo e usa un reason code 3 ("Deauthenticated because sending STA is leaving").
Figura 21: Reason Code Deauthenticated
Nel prossimo esempio, il frame è stato inviato da aireplay-ng al BSSID 00:89:6e:1a:43:90. Usa il reason code 7 ("Class 3 frame received from nonassociated client").
Figura 22: Reason code
AP e client normalmente inviano una deauthentication; una grande quantità di frame deauthentication di solito indica un attacco in corso.
5.3.7. Frame di controllo
I frame di controllo aiutano a consegnare i frame di dati così come altri frame unicast. Devono essere ricevuti in modo affidabile, quindi sono brevi e inviati a un rate basso. La tabella seguente mostra i diversi tipi di frame di controllo.
| Subtype | Field Description |
|---|---|
| 0-6 | Reserved |
| 7 | Control Wrapper |
| 8 | Block ACK Request |
| 9 | Block ACK |
| 10 | PS-Poll |
| 11 | RTS |
| 12 | CTS |
| 13 | ACK |
| 14 | CF End |
| 15 | CF End + CF-ACK |
Tabella 4 - Sottotipi dei frame di controllo
Esaminiamo alcuni dei sottotipi di frame di controllo più comuni.
5.3.8. ACK
Questa sezione include un file di riferimento, ack.pcap, nella sezione Resources.
Un frame ACK dice al client mittente che il frame è stato ricevuto correttamente. Questi frame vengono inviati per ogni frame unicast (diretto a un dispositivo specifico) inviato.
Figura 23: Diagramma del frame ACK
Possiamo aprire un frame ACK in una cattura Wireshark per ispezionarlo più da vicino.
Figura 24: Frame ACK in Wireshark
Il frame ACK ha un campo Type impostato a 1, il che significa che è un frame di controllo. Il campo Subtype ACK è 13.
Il Block ACK permette di disabilitare l'ACK per un certo numero di frame e poi confermarli, il che migliora il throughput. Contengono una bitmap dei frammenti e ogni bit rappresenta lo stato di uno di essi (ACK/NACK).
5.3.9. RTS/CTS
Questa sezione include un file di riferimento, rts-cts.pcap, nella sezione Resources.
Questa sezione include un file di riferimento.
RTS/CTS è un supplemento al meccanismo CSMA/CA che aiuta a ridurre le collisioni. Aggiunge overhead alla comunicazione wireless, perché devono essere aggiunti frame aggiuntivi prima e dopo la comunicazione. La Figura 25 illustra il processo.
Figura 25: Sequenza di comunicazione RTS/CTS
Nella Figura 25, il Nodo 1 vuole comunicare con il Nodo 2, che può essere un AP o un client.
Per prima cosa, il Nodo 1 invia un "Request to Send" al Nodo 2. Se non c'è stata collisione e la richiesta è accettata, il Nodo 2 invia un "Clear to Send" al Nodo 1 dicendogli di procedere. Altri dispositivi nelle vicinanze che sentono il CTS attendono anch'essi. Poi, il Nodo 1 invia i suoi dati. I dati vengono confermati con un frame ACK dal Nodo 2. Se l'invio dei dati fallisce, non viene inviato alcun frame ACK.
Esaminiamo la struttura del frame RTS, che ha una lunghezza di 20 byte.
Figura 26: Struttura del frame RTS
Per confronto, un frame CTS ha la stessa lunghezza (14 byte) e struttura di un frame ACK.
Figura 27: Struttura del frame CTS
La Figura 28 include l'intera sequenza RTS/CTS in azione.
Figura 28: La sequenza RTS/CTS in Wireshark
Esaminiamo questa cattura frame per frame per iniziare a comprendere meglio come avviene questa transazione.
Nel secondo frame, l'AP invia un RTS al client. Si noti che il Type del frame è 1 (Control frame) e il Subtype è 11 (RTS).
Figura 29: La sequenza RTS/CTS in Wireshark - RTS
Nel frame seguente, il client risponde all'AP con CTS. Il Subtype del frame è 12 (CTS).
Figura 30: La sequenza RTS/CTS in Wireshark - CTS
Dopo aver ricevuto un messaggio CTS dal client, l'AP invia un frame di dati dalla rete interna.
Figura 31: La sequenza RTS/CTS in Wireshark - Data frame
Una volta ricevuto con successo il frame di dati, il client invia un ACK (Subtype 13) all'AP.
Figura 32: La sequenza RTS/CTS in Wireshark - RTS - ACK
In alcune istanze, i dispositivi usano il meccanismo di protezione CTS-to-self prima di inviare dati. Come menzionato in precedenza, tutti gli altri dispositivi che sentono CTS attendono prima di trasmettere. Il tempo di attesa è specificato nel campo duration di questo frame, visualizzato nella Figura 31. Di conseguenza, alcuni dispositivi inviano un CTS prima della loro trasmissione per migliorare la probabilità di un trasferimento riuscito.
5.3.10. Frame di dati
Esistono diversi tipi di frame di dati, la maggior parte dei quali sono usati per trasportare dati tra dispositivi. La tabella seguente mostra i diversi tipi.
| Subtype | Field Description |
|---|---|
| 0 | Data |
| 1 | Data + CF ACK |
| 2 | Data + CF Poll |
| 3 | Data + CF ACK + CF Poll |
| 4 | Null Function (No Data) |
| 5 | CF ACK (No Data) |
| 6 | CF Poll (No Data) |
| 7 | CF ACK + CF Poll (No Data) |
| 8 | QoS Data |
| 9 | QoS Data + CF ACK |
| 10 | QoS Data + CF Poll |
| 11 | QoS Data + CF ACK + CF Poll |
| 12 | QoS Null (No Data) |
| 13 | Reserved |
| 14 | QoS CF Poll (No Data) |
| 15 | QoS CF ACK + CF Poll (No Data) |
Tabella 5 - Sottotipi dei frame di dati
I frame di dati più comuni sono Data (sottotipo 0), Null Function (sottotipo 4) e i loro equivalenti con QoS (sottotipi 8 e 12 rispettivamente).
I frame dati QoS sono usati quando si dà priorità al traffico sensibile ai ritardi, come voce o video. Contengono un QoS Control field prima del payload.
5.3.11. Data
Questa sezione include un file di riferimento, airport-wifi_34.pcap, nella sezione Resources.
Esaminiamo una richiesta DHCP (UDP) catturata su una rete aperta. Si tratta di un frame dati QoS.
Figura 33: QoS Data
5.3.12. Null Data
Questa sezione include un file di riferimento, null-data-packet.pcap, nella sezione Resources.
I frame Null consistono solo di intestazioni MAC e di un FCS. I client li usano quando stanno entrando in modalità risparmio energetico. Questo è il caso nella Figura 33, dove notiamo che il bit di power management (PWR MGT) è impostato.
Figura 33: Frame Null inviato da un client
Quando il client esce dalla modalità risparmio energetico, invierà lo stesso frame con il bit power management reimpostato. L'AP invierà al client tutti i frame in buffer in attesa.
5.4. Interazione con le reti
Ora che abbiamo trascorso del tempo esplorando i frame comuni usati sulle reti, discutiamo i passaggi necessari per connettersi e poi trasmettere dati su una rete wireless. Confronteremo anche alcuni diversi tipi di crittografia di rete.
Inizieremo con i passaggi per connettersi a una rete wireless.
Figura 34: Le fasi della connessione a una rete
Possiamo separare questo processo in tre passaggi: probe, authentication e association.
Durante la fase probe, il client invia prima una probe su tutti i canali per trovare un AP. Poi gli AP che sono nel raggio rispondono alla probe request.
Durante l'autenticazione, il client solitamente seleziona l'AP con il segnale più forte il cui SSID era stato precedentemente scelto nell'interfaccia utente del sistema operativo. Il processo di autenticazione effettivo varia, a seconda, ad esempio, del tipo di crittografia. Questa fase termina quando l'AP invia una risposta all'autenticazione.
Terza è la fase association. Il client invia un'association request. Come per l'autenticazione, la durata di questa parte del processo varia. Una volta completata questa fase, il client può comunicare con la rete.
Quando viene usata la crittografia WPA o quando si è su reti Opportunistic Wireless Encryption (OWE), c'è un passaggio in più. Dopo l'association, un client deve passare attraverso lo scambio e la verifica delle chiavi. Questo è necessario per poter usare la rete.
Esploriamo come avvengono queste diverse fasi su reti con diversi schemi di crittografia.
5.4.1. Rete aperta
Questa sezione include un file di riferimento, open.pcap, nella sezione Resources.
Ora apriremo la nostra cattura di rete e osserveremo il funzionamento delle reti wireless. Per prima cosa esamineremo un beacon della rete, il primo frame, che fornisce dettagli sulla rete. Sebbene i beacon si verifichino circa 10 volte al secondo, questa cattura ne contiene solo uno per brevità poiché i beacon sono tutti identici.
Figura 35: Bit Privacy
In IEEE802.11 Wireless Management > Fixed Parameters > Capabilities information, il bit Privacy indica che l'AP non è crittografato.
Tagged parameters include maggiori dettagli su questa rete. Il primo parametro ci dice l'SSID della rete, "freewifi". Il canale, 6, in DS parameter set indica che l'AP opera nella banda 2,4 GHz. Il protocollo potrebbe essere 802.11b, 802.11g, 802.11n o una combinazione di questi. I Supported rates mostrano i rate 802.11b e gli Extended supported rates mostrano i rate 802.11a/g.
Poiché sappiamo che la banda di frequenza 2,4 GHz supporta rate tra 1 e 54 Mbps, possiamo concludere che la rete è 802.11b/g.
Figura 36: Tagged parameters
Il processo di connessione che abbiamo spiegato in precedenza è presente qui nei frame da 2 a 7. I frame 2 e 3 sono la probe e la response. Dopo questo, il processo di autenticazione avviene nei frame 4 e 5. Infine, il processo di association avviene nei frame 6 e 7.
Nel frame 2, la probe request, possiamo notare che Wireshark ha contrassegnato il SSID parameter come Wildcard. Quando apriamo questo campo, notiamo che non c'è SSID presente, il che significa che il client sta cercando qualsiasi AP nel raggio.
Figura 37: SSID parameter set
Qualsiasi AP che sente questo frame risponderà alla probe request. La risposta da freewifi è nel frame 3. Le informazioni nella sezione IEEE802.11 Wireless Management sono identiche al contenuto del suo beacon.
Figura 38: Retry
Nei flag nella colonna Info, la R, che sta per retry, mostra che un frame è stato reinviato dall'AP. In questo caso, potremmo ipotizzare che il client stava scansionando su altri canali e non ha ricevuto o confermato una risposta dall'AP. Poiché la risposta non è stata confermata, l'AP l'ha reinviata.
Dopo aver completato il processo probe, il client inizia l'autenticazione con il frame 4. Nella figura seguente, il client sta provando Open Authentication. Sebbene Shared Authentication sia un'opzione per questo campo, non è disponibile per le reti aperte.
Figura 39: Authentication algorithm
La risposta dall'AP è nel frame 5, che indica che l'autenticazione è riuscita.
Figura 40: Status code Authentication
Ora, nel frame 6, il client inizia il processo di association inviando un'association request. Il client deve fornire l'SSID e i rate altrimenti non sarà in grado di connettersi.
Figura 18: Association request
Nel frame 7, l'AP accetta l'association. Lo Status code evidenziato nella Figura 41 indica che l'association è riuscita.
Figura 41: Association Status code
A questo punto, il client è in grado di comunicare sulla rete. Invia una richiesta DHCP perché non ha un indirizzo IP e ha bisogno di altre informazioni di rete. Non c'è crittografia su questa rete, quindi la richiesta DHCP è visibile nei frame da 8 a 16. Il campo Your (client) IP address nel frame 16 include l'indirizzo IP che è stato assegnato al client, 192.168.200.137.
Figura 42: Indirizzo IP DHCP
Nei frame da 19 a 25, il client sta facendo ping a 8.8.8.8.
Figura 43: Ping a 8.8.8.8
L'ultimo frame non ha una risposta, ma questo non significa necessariamente che una risposta non sia stata inviata. A volte, a causa della nostra posizione o di interferenze, potremmo non sentire o catturare necessariamente ogni singolo frame.
Nel frame 28, un dispositivo sta cercando di risolvere example.com. La risposta, nel frame 29, include un indirizzo IP di 93.184.216.34.
Figura 44: Risposte
Possiamo anche notare un'altra R nei flag di IEEE802.11 Data, che indica che questo frame è stato ritentato. Il client non ha sentito la prima volta che la risposta è stata inviata.
I frame da 30 a 49 sono i frame per il sito web http://example.com. La richiesta è nel frame 34:
Figura 45: HTTP
Il frame 38 include la risposta dal server, 200/OK, il che significa che la pagina esiste. Questo frame include anche i seguenti dati.
Figura 46: Dati testuali basati su righe
Nel frame 42, il browser richiede l'icona dei siti web interrogando il favicon.ico. Nel frame 44, il server restituisce un 404 perché non ne ha uno.
Figura 47: Errore 404
5.4.2. EAPoL
Successivamente esploreremo i frame Extensible Authentication Protocol over LAN (EAPoL), che sono comunemente usati durante l'handshake quando ci si connette a un AP con WPA, WPA2, WPA3 o OWE. Li incontreremo anche durante uno scambio WPS, o quando Protected Management Frames, 802.11w, è usato sulla rete.
Prima di iniziare, rivediamo il formato del frame EAPoL che verrà usato negli handshake che esamineremo.
Figura 48: Struttura del frame EAPoL-Key
La sezione di autenticazione del frame EAPoL è divisa in diversi campi.
- La Protocol Version (1 byte) ha un valore di 1, 2 o 3. Questi valori rappresentano rispettivamente 802.1X-2001, 802.1X-2004 o 802.1X-2010. I valori 1 e 2 sono i più comuni.
- Il Packet type (1 byte) di solito ha un valore di 3, il che significa che è una chiave.
- Il campo Packet Body Length (2 byte) indica la lunghezza del corpo del pacchetto o la quantità di dati dopo questo campo.
- Il Descriptor Type (1 byte) di solito ha un valore di 2, che indica "EAPoL RSN Key" quando è in uso WPA2, o 254, che indica "EAPoL WPA Key" quando è in uso WPA1.
- Le Key Information (2 byte) specificano le caratteristiche della chiave, che è divisa in parti più piccole.
- La Key Length (2 byte) ci dà la lunghezza della PTK. Un valore di 5 o 13 indica WEP40 e WEP104, e valori di 16 o 32 indicano cipher TKIP, CCMP, GCMP, BIP-CMAC o BIP-GMAC.
- Il Replay Counter (8 byte) viene incrementato progressivamente ogni volta che i frame EAPoL viaggiano avanti e indietro. Questo aiuta a evitare il replay di vecchi messaggi. Il Replay Counter è solitamente 1 nella prima parte dell'handshake (frame 1 e 2) e 2 nella seconda parte. Nei casi in cui lo scambio fallisce, a causa di una chiave errata o di un segnale debole, il numero salirà.
- Il Key Nonce (32 byte) contiene un nonce dal trasmettitore.
- L'EAPoL Key IV (16 byte) contiene l'IV usato con la KEK. Quando non è richiesto, questo campo conterrà uno 0.
- Il Key Receive Sequence Counter (8 byte) è usato nel messaggio 3 e 4, per indicare il contatore per la GTK. Non è usato con WEP, ma ha alcuni altri usi.
- Il Key Identifier (8 byte) è un campo non usato, riservato per uso futuro. È impostato a 0.
- Il campo Key MIC (dimensione variabile) è la MIC di questo pacchetto, chiamato EAPoL-Key, da e incluso Protocol Version. La sua dimensione dipenderà dall'AKM usato.
- Il campo Key data length (2 byte) definisce la lunghezza del campo Key Data imminente.
- Il campo Key Data include dati aggiuntivi per lo scambio di chiavi. I dati possono anche essere uno o più Robust Security Network Elements (RSNE) o Key Data Elements (KDE). Un RSNE inizia con 0x30 e KDE inizia con 0xdd.
Le Key Information sono ulteriormente divise in diversi campi più piccoli.
- Per impostazione predefinita, la Key descriptor version (bit 0, 1 e 2) è impostata a 0, ma potrebbe anche essere impostata a valori di 1, 2 o 3 per indicare un algoritmo specifico. I valori 1, 2 e 3 sono mappature agli algoritmi usati per la MIC, la sua lunghezza e la chiave di crittografia. Uno (1) è per crittografia ARC4 con HMAC-MD5, due (2) è per NIST AES key wrap con HMAC-SHA1-128, e tre (3) è NIST AES key wrap con AES-128-CMAC.
- Quando il Key Type (bit 3) è impostato, il risultato sarà una PTK. Quando non è impostato, il risultato sarà una group key o SMK.
- I bit 4 e 5 sono riservati e non sono in uso al momento.
- Se Install (bit 6) è impostato, il client dovrà installare le chiavi.
- Key ACK (bit 7) indica se la parte ricevente si aspetta un messaggio EAPoL-Key.
- Quando Key MIC (bit 8) è impostato, è presente una MIC.
- Secure (bit 9) è impostato quando lo scambio iniziale di chiavi è completo. Sarà impostato nel messaggio 3 (dall'Authenticator al Supplicant) e nel messaggio 4 (dal Supplicant all'Authenticator).
- Error (bit 10) è impostato quando si verifica un fallimento MIC.
- Request (bit 11) è impostato solo da un Supplicant in un report MIC Failure. Può anche richiedere all'Authenticator di avviare un 4-way handshake o un group key handshake.
- L'Encrypted Key Data (bit 12) è impostato se il campo Key Data è crittografato.
- SMK Message (bit 13) specifica se il pacchetto fa parte di un handshake SMK.
Key Data può contenere due tipi di dati: key data cryptographic encapsulation(s) (KDE) o RSNE. La struttura di KDE è la seguente.
Figura 49: Struttura KDE
La struttura RSNE è un po' più complessa.
Figura 50: Struttura RSNE
L'ultimo elemento sarà presente solo se anche quello precedente è presente. La Pairwise Cipher Suite List contiene elementi nel seguente formato.
Figura 51: Elemento RSNE Pairwise Cipher Suite
5.4.3. WEP
Questa sezione include 2 file di riferimento:
- WEP Open Authentication
- WEP Shared Authentication
Entrambi nella sezione Resource.
Il processo di connessione per WEP è simile a quello che abbiamo appena esplorato per le reti aperte. Il client invierà probe request e riceverà response. Poi inizierà il processo di autenticazione e l'association prima di poter finalmente comunicare sulla rete.
La principale differenza che noteremo nei frame è che il bit Privacy è impostato nei beacon, nelle probe response e nei frame di association. Il bit Privacy indica crittografia. A causa della mancanza di tag WPA o WPA2 in questi frame, sappiamo anche che l'algoritmo di sicurezza è WEP.
WEP può essere open authentication o shared authentication. Con open authentication, il processo è identico a una rete aperta. Con shared authentication, il client riceve dati casuali chiamati challenge text dall'AP. Il client deve crittografare il challenge text per dimostrare di avere la chiave giusta. L'AP proverà poi a decrittare usando la propria chiave. Se ha successo, al client sarà permesso di continuare con l'association. La shared authentication è molto meno comune della open authentication, e l'AP che trasmette non la pubblicizza. Per questo motivo, molti client proveranno prima la open authentication. Se vengono negati una o più volte, proveranno la shared authentication.
5.4.4. WPA1
Questa sezione include un file di riferimento, wpa1.pcap, nella sezione Resources.
Useremo un filtro di visualizzazione, !(wlan.fc.type == 1), in Wireshark per saltare i frame di controllo che non sono rilevanti in questo scambio.
Il primo frame è un beacon dall'AP. Pubblicizza WPA1 PSK TKIP.
Figura 52: Frame 1: Beacon con WPA IE
Il frame seguente è una probe request, seguita da una probe response dall'AP. Entrambi hanno gli stessi IE.
Figura 53: Frame 3: Probe Response con WPA IE
L'autenticazione è simile a una che abbiamo esaminato in precedenza. Saltiamo all'association request dal client. Questa request include un accordo per connettersi usando WPA1 PSK TKIP.
Figura 54: Frame 55: Association request con WPA IE
L'association response indica che è riuscita.
Figura 55: Frame 57: Association response
Successivamente, notiamo il 4-way handshake, che è avviato dall'AP.
Figura 56: Frame 59: EAPoL message 1
A questo punto il client genera il suo nonce. Poiché ha tutte le informazioni necessarie, può derivare la PTK successivamente.
Figura 57: Frame 61: EAPoL message 2 - parte 1
Ora che l'AP, che in questo caso è l'Authenticator, ha ricevuto il nonce dal client (Supplicant), può generare la PTK. Confermerà anche che supplicant e authenticator condividono la stessa chiave verificando la MIC. Infine, preparerà il terzo messaggio, che contiene la GTK.
Figura 57: Frame 61: EAPoL message 2 - parte 2
Nei flag sotto la sezione Key Information di questo messaggio, l'AP dice al client di installare le chiavi.
Figura 58: Frame 63: EAPoL message 3 - parte 1
Il Key Data in questo terzo messaggio contiene una KDE all'interno di un IE (che si trovano tipicamente nei frame di gestione come i beacon) per WPA1.
Figura 59: Frame 63: EAPoL message 3 - parte 2
L'ultimo messaggio è semplicemente un riconoscimento che permetterà il flusso di dati crittografati. L'AP verificherà la MIC e poi installerà le chiavi per il client appena connesso.
Figura 60: Frame 65: EAPoL message 4
Il group key handshake viene eseguito successivamente, nei frame 67 e 69. Dovremo decrittare la cattura per poterli esaminare.
Figura 61: Frame 67: Group Handshake message 1
Figura 62: Frame 69: Group Handshake message 2
5.4.5. WPA2
Questa sezione include un file di riferimento, wpa-Induction.pcap, nella sezione Resources.
Il primo frame è un beacon dall'AP. Pubblicizza WPA1 e WPA2, entrambi con AES/CCMP e TKIP. Group Cipher in entrambi i casi è TKIP, il che significa che tutti i frame che sono broadcast o multicast saranno crittografati usando TKIP. Quelli unicast dipenderanno dal cipher selezionato dal client.
Useremo un filtro di visualizzazione, !(wlan.fc.type == 1), in Wireshark per saltare i frame di controllo che non sono rilevanti in questo scambio.
Figura 63: Frame 1: Beacon con RSN IE
Figura 64: Frame 1: Beacon con WPA IE
La sezione di autenticazione è senza eventi (frame 78 e 80). Nell'association request (frame 82), il client sta selezionando WPA2 con AES o RSN così come TKIP per il group cipher.
Figura 65: Frame 82: Association request con RSN
L'AP risponde con un'Association Response riuscita (frame 84), e poi procede ad avviare il 4-way handshake.
Figura 66: Frame 84: Association response
Questo 4-way handshake è simile a quello nella sezione WPA1. Ci sono alcune differenze chiave perché è WPA2 CCMP.
In questo primo messaggio EAPoL, le key information indicano che sta usando CCMP con HMAC-SHA1 MIC.
Figura 67: Frame 87: 4-way handshake (EAPoL message 1) - parte 1
Il campo WPA Data mostra un RSNE con un PMKID.
Figura 68: Frame 87: 4-way handshake (EAPoL message 1) - parte 2
Notiamo un RSNE nel campo WPA Key Data, che mostra i dettagli del cipher usato.
Figura 69: Frame 1: Beacon
Il secondo frame è una probe request e il terzo è una risposta a quella request. Contiene gli stessi IE del beacon e pubblicizza SAE, 802.11w e BIP nell'RSN IE. C'è un'eccezione, il Traffic Indication Map.
Figura 70: Frame 3: Probe response
L'handshake dragonfly avviene durante la parte di autenticazione. Nel primo frame di autenticazione (5), notiamo che l'algoritmo non è "Open authentication" come era con WEP, WPA1 o WPA2. Ora l'algoritmo è Simultaneous Authentication of Equals (SAE) usando il gruppo predefinito, 19. Questo primo frame di autenticazione è l'inizio della fase commit in cui entrambe le parti si impegnano verso un segreto condiviso.
Figura 71: Frame 5: Authentication - Commit message dal client
Il secondo frame (7) della fase di autenticazione è dove l'AP invia il suo scalar e finite field element.
Figura 72: Frame 7: Authentication - Commit message dall'AP
Il frame successivo (9) è il confirm message dal client.
Figura 73: Frame 9: Authentication - Confirm message dal client
E infine, nel frame 11, c'è una risposta dall'AP.
Figura 74: Frame 11: Authentication - Confirm message dall'AP
La fase association, che segue, è senza eventi. Per prima cosa il client indica le specifiche della RSNA, inclusi AES per unicast e multicast, SAE e 802.11w.
Figura 75: Frame 13: Association Request
Poi, l'AP invia l'association response, accettandola.
Figura 76: Frame 15: Association Response
La fase association si conclude con il 4-way handshake, che usa AES/CCMP.
Figura 76: Frame 17: Association 4-way Handshake
5.4.7. Disaccordo sul gruppo
[
Jump to resources to start virtual machines and/or answer labs
]
Questa sezione include un file di riferimento, wpa3-dh-group-disagreement.pcap, nella sezione Resources.
Nella maggior parte dei casi, un client e un AP si accordano sul gruppo predefinito, 19. Tuttavia, è possibile configurare i gruppi sull'AP e sul client. In questa sezione esploreremo un PCAP in cui il client ha una selezione personalizzata di gruppi diversa da ciò che l'AP accetterebbe normalmente. Il client passerà attraverso i gruppi uno per uno finché non troverà uno su cui l'AP può concordare.
Ancora una volta, useremo il filtro di visualizzazione !(wlan.fc.type == 1) in Wireshark per saltare i frame di controllo che non sono rilevanti in questo scambio.
Il primo frame è un beacon dall'AP, che pubblicizza "WPA3-Network" con SAE e 802.11w obbligatorio.
Figura 77: Frame 1: Beacon
Il terzo frame è una risposta alla probe request con le stesse informazioni del beacon.
Figura 78: Frame 3: Probe response
L'autenticazione per l'handshake dragonfly inizia al frame 51 dove il client prova a usare il gruppo 15.
Figura 79: Frame 51: Authentication - client - gruppo 15
L'AP non supporta il gruppo 15 e lo rifiuta.
Figura 80: Frame 53: Authentication - AP - gruppo 15 in disaccordo
Poi, il client riprova. Questa volta con il gruppo 16.
Figura 81: Frame 55: Authentication - client - gruppo 16
L'AP rifiuta anche questo.
Figura 82: Frame 57: Authentication - AP - gruppo 16 in disaccordo
Poi, il client prova il gruppo 19.
Figura 83: Frame 59: Authentication - client - gruppo 19
Il gruppo 19 è il gruppo predefinito ed è richiesto in qualsiasi implementazione, quindi sarà sempre accettato.
Figura 84: Frame 61: Authentication - AP - Accettazione gruppo 19
Ora il client procede alla fase confirm.
Figura 85: Frame 63: Authentication - Client - Confirm
Il frame seguente dall'AP conclude la fase di autenticazione, che è riuscita, come indicato dallo status code.
Figura 86: Frame 65: Authentication - AP - Confirm
Da qui, il client si associerà all'AP e completerà il 4-way handshake.
Resources
Alcuni laboratori richiedono di scaricare i file sottostanti.
| Resource name | |
|---|---|
| wpa3-dh-group-disagreement.pcap | |
5.4.8. Opportunistic Wireless Encryption
[
Jump to resources to start virtual machines and/or answer labs
]
Questa sezione include un file di riferimento, owe.pcap, nella sezione Resources.
In questa sezione esamineremo una cattura che contiene un'association OWE riuscita. Ancora una volta, useremo !(wlan.fc.type == 1) per saltare i frame di controllo.
Il Frame 1 sotto mostra un beacon con un tag RSN che offre solo OWE.
Figura 87: Frame 1: Beacon con RSN IE con OWE
Come WPA3, OWE richiede 802.11w. Questo protegge alcuni frame di gestione suscettibili ad attacchi.
La figura seguente contiene una probe del client che ha anche un RSN IE con OWE e 802.11w.
Figura 88: Frame 3: Probe response con RSN IE con OWE
L'open authentication, con i frame 51 e 52 dal client e dall'AP rispettivamente, è senza eventi. Mentre WPA3 usava l'autenticazione per l'handshake dragonfly, OWE esegue lo scambio di chiavi pubbliche nella fase association. L'association request dal client è nel frame 55.
Figura 89: Frame 55: Association request
L'ultimo IE nell'association request è un IE esteso, che contiene i parametri Diffie-Hellman dal client. Questi includono il gruppo Diffie-Hellman usato, gruppo predefinito 19, e la chiave pubblica.
Nel frame seguente, l'AP invia anche le sue informazioni.
Figura 90: Frame 57: Association response
Da lì, entrambi possono derivare la stessa PMK da usare nel 4-way handshake come in WPA2, nei frame 59, 61, 63 e 65.
Resources
Alcuni laboratori richiedono di scaricare i file sottostanti.
| Resource name | |
|---|---|
| owe.pcap | |
5.4.9. Wi-Fi Protected Setup
[
Jump to resources to start virtual machines and/or answer labs
]
Questa sezione include un file di riferimento, wpsdata.cap, nella sezione Resources.
Questa cattura di pacchetti contiene uno scambio WPS riuscito. Ha frame duplicati (frame con il bit retry impostato) perché alcuni frame non sono stati confermati dal dispositivo ricevente. Quando l'ACK non viene ricevuto entro un certo periodo di tempo, il frame che dovrebbe confermare si presume perso. Il trasmettitore lo invia di nuovo, tuttavia questa volta il bit retry è impostato.
Useremo di nuovo il nostro filtro di visualizzazione !(wlan.fc.type == 1) in Wireshark.
Il Frame 1 sotto mostra un beacon con il tag WPS.
Figura 91: Frame 1: Beacon con WPS IE
I frame da 4 a 16 (17 è un frame di controllo e non è incluso) mostrano la probe request dal client, la risposta dall'AP, così come l'autenticazione e l'association all'AP.
Figura 92: Frame da 4 a 17: probing, authentication, association
Il Frame 18 include l'EAP Start dal client.
Figura 93: Frame 18: EAPoL start
Il Frame 20 include l'EAP Request Identity dall'AP.
Figura 94: Frame 20: EAP Request Identity
Dopo diversi frame ritentati, la identity response (con WFA-SimpleConfig-Enrollee-1-0) è il frame 28.
Figura 95: Frame 28: EAP Response Identity
A causa dell'EAP Response Identity ritentata, la request con WSC Start appare nel frame 26, prima della response.
Figura 96: Frame 26: Request Expanded Types
L'AP e il client scambieranno ora una serie di otto messaggi chiamati M1 a M8, inviati in ordine sequenziale, avanti e indietro, per confermare il PIN WPS e scambiare in modo sicuro la passphrase, in M8. M1 include informazioni dall'enrollee, e M2 aggiungerà informazioni dal registrar. In WPS, il Registrar è un'entità, non necessariamente un AP, che può dare accesso alla rete. Un enrollee è un dispositivo, più spesso un AP o un client, che cerca di ottenere la passphrase per la rete. M1 (e M2 in misura minore) aiuteranno a determinare quale è quale.
Il Frame 30 mostra M1 con informazioni dettagliate sull'enrollee, che include il produttore dell'adattatore wireless (Atheros), il nome del dispositivo (WXP-JBRAEUER-T1) e il device password ID usato. Quest'ultima informazione indica il tipo di password usata (0000, valore predefinito), che indica un PIN. Sono inclusi anche l'indirizzo MAC, il nonce e la chiave pubblica (DH).
Figura 97: Frame 30: M1
Il Frame 38 mostra M2 con informazioni sull'AP, un D-Link DIR-655 Model A1/A2. Questo frame contiene anche sia l'Enrollee sia il Registrar nonce così come la chiave pubblica (DH) del Registrar.
Figura 98: Frame 38: M2
Il Frame 42 sotto mostra M3, che è stato ritrasmettuto alcune volte (39, 40, 41 e 42) con il Registrar nonce e entrambi i valori E-Hash (dall'enrollee e dal registrar).
Figura 99: Frame 42: M3
Il Frame 43 sotto è di tipo M4 con impostazioni di crittografia R-S1.
Figura 100: Frame 43: M4
La prima metà del PIN è stata convalidata.
Il Frame 44 è di tipo M5 con impostazioni di crittografia E-S1. La seconda parte del PIN sarà verificata nei prossimi messaggi.
Figura 101: Frame 44: M5
Il Frame 45 è di tipo M6 con impostazioni di crittografia R-S2.
Figura 102: Frame 45: M6
Il Frame 46 è di tipo M7 con impostazioni di crittografia E-S2.
Figura 103: Frame 46: M7
Il Frame 47 sotto è di tipo M8 con impostazioni wireless crittografate per l'Enrollee.
Figura 104: Frame 47: M8
WSC Done nel frame 48 indica che lo scambio WPS (Wi-Fi Simple Configuration) è terminato.
Figura 105: Frame 48: WSC Done
Il Frame 49 sotto mostra EAP Failure per indicare la fine della sessione del protocollo di registrazione, quindi ora il client può usare le credenziali per eseguire il 4-way handshake:
Figura 106: Frame 49: EAP Failure
Resources
Alcuni laboratori richiedono di scaricare i file sottostanti.
| Resource name | |
|---|---|
| wpsdata.cap | |
5.4.10. 802.11w
[
Jump to resources to start virtual machines and/or answer labs
]
Questa sezione include un file di riferimento, pmf.pcap, nella sezione Resources.
Questo file di cattura mostra il meccanismo SA Query in azione quando 802.11w è negoziato da un client.
Il primo frame è un beacon. Notiamo che WPA2 CCMP è usato nell'RSN IE (sia per i frame unicast che multicast). L'Authentication Key Management (AKM) mostra che viene usata la pre-shared Key (PSK). Per impostazione predefinita, SHA1 è usato quando Wireshark non specifica nulla (AKM type con valore 2), ma in questo caso, 802.11w usa SHA256 (AKM type con valore 6).
Quando le RSN Capabilities sono espanse, solo il bit "Management Frame Protection Capable" è impostato, e quindi l'AP può accettare client con e senza 802.11w.
Figura 107: Frame 1: Beacon
I frame successivi includono diverse Probe Request, in cui il client sta scansionando gli AP. Il Frame 3 mostra una risposta dall'AP con informazioni simili al Beacon descritto nella Figura 107.
Figura 108: Frame 3: Association Response
L'autenticazione inizia al frame 50. L'AP risponde con il frame 51, e il client si associa poi all'AP nei frame 52 e 53. Nel frame 52, l'association request, il client indica che supporta l'AKM richiesto dall'AP così come PMF. Con queste impostazioni, il client si associerà solo a un AP che è impostato su "Capable" o "Required".
Figura 109: Frame 52: Association Request
Il 4-way handshake è simile a qualsiasi altro handshake WPA2.
Il Frame 132 è una deauthentication inviata da un attaccante. È seguito da due action frame e poi altri frame deauthentication. Questo potrebbe essere un contenimento da un Wireless Intrusion Prevention System (WIPS), ma in questo caso è un attacco deauthentication da aireplay-ng.
Figura 110: Frame 132: Deauthentication da un attaccante
Il primo action frame (Figura 111) è un SA Query crittografato dal client, che verifica l'AP.
Figura 111: Frame 133: Action frame: SA Query
L'AP risponde immediatamente nel frame 134. Di conseguenza, l'AP ignorerà le deauthentication che non provengono direttamente dal client.
Figura 112: Frame 134: Action frame: SA Query response
Infine, il client invia un frame deauthentication quando si disconnette dalla rete in modo che l'AP possa liberare le risorse associate alla connessione del client.
Figura 113: Frame 309: Deauthentication dal client
5.5. Conclusione
In questo modulo, abbiamo prima esaminato la struttura dei frame 802.11 ed esplorato i dettagli dei frame comuni incontrati sulle reti Wi-Fi. Poi abbiamo appreso come questi frame lavorano insieme quando ci si connette a reti con diversi tipi di crittografia.