Sunday, June 5, 2011

Wi-fi Deauth technique Demystified

These days there is much rattling going on around Wi-fi Attacks & Preventions so I decided to dig around Wi-Fi DOS(Denial of Service) attack based on Deauthentication technique. This is basically Wi-Fi Message type which is exploited.
I get really happy when a protocol gets owned due to its inherent functionality.

Applications of Deauth :

1) Used by attackers to do real-time DOS attack.

2) Used by WIPS (Wireless Intrusion Prevention systems) to prevent Rogue AP's & attackers.

Limitations of Attacks : 

1) Attacking device used to perform Deauth must emit packets at continuous intervals i.e. Attacker has to be in Access points range all the time.

2) Attacking device must have Wireless card in "Monitor" mode to sense all packets in air & must support packet injection mode.

So In non-geek language, How De-Auth works?

1) Deauth packets means Wireless Management Frame of Subtype 12 i.e. Type = 0 & Subtype = 8.

2) Management Frames in 802.11 wireless protocol are un-authenticated & always un-encrypted. That is no authentication is required to transmit or receive Management frames.

3) This gives an Attacker a opportunity to send packets to Target client of Subtype 12 (Deauth)  as they were coming from Access point. This causes the Wireless Driver of Client to reconnect.

4) Re-association of Wireless card, causes the Network connections on target to close. Now different Wireless card manufacturers have different Backoff Algorithms to send Association requests. This timer can be matched by the attacker & imitated to cause complete DOS.

My Experimental Setup at home & Observations :

Resources : 
1) Ubuntu 10.04 Laptop with Realtek 8187* Chipset & aircrack-ng installed. No IP address assigned
           *Realtek 8187 chipset supports Packet Injection & Monitor Mode
2) Normal Windows XP client laptop connected to "Cyberninja" SSID IP - 10.0.0.2
3) Netgear WGR614v9 Wireless router having "Cyberninja" as SSID with WPA2-PSK IP - 10.0.0.1

Mac addresses:
1) Attacker : Doesn't matter as card goes in "Monitor" Mode
2) Access Point : Netgear_75:C2:74
3) Target : HonHaiPr_82:FC:F7

Windows XP client is associated with AP, Four way EAPOL is already done. Now lets set the Ubuntu Laptop.

1) Start the Wireless interface in "Monitor" mode.
airmon-ng start wlan0

2) Started tcpdump on attacking system to capture the packets.
tcpdump -i mon0 -w Attacker.pcap

here mon0 is the interface in Monitor mode, you can see it in "ifconfig -a" .

3) Dumping traffic at Monitor interface to see the Access points & clients associated with it.
airodump-ng -c 1 mon0

My access point is running on Channel 1, so I have specified it to channel 1.
Here in first section, you can see the AP information such as BSSID which is usually MAC address of Access Point, Channel of AP, SSID name of AP, etc
Second section reveals the Clients information connected to  AP such as Clients MAC addresses.
Keep this airdump-ng running on channel 1 while doing Deauth of clients.

4)  Deauth'ing the clients
aireplay-ng --deauth 3 -a <<BSSID of AP>> -c <<MAC address of Target client>> mon0

Also run Wireshark on the XP client to see whats happening.

Observations :

1) Aireplay will resend 3 "deauth" packets with spoofed source MAC address of AP to the Client on interface mon0. This causes the client to think that the AP wants re-association & restarts it's Wireless card & performs 4 way EAPOL (Extensible Protocol over LAN) again. This can be clearly seen from the Wireshark Packet captures.

2) Now to check ping 10.0.0.1 (Netgear Router) from 10.0.0.2 (XP Client). You can clearly observe the lost requests of ICMP ping. Client will not notice anything but will get "Request timed out" as wireless card is continuously re-associating.

3) As I have sent 3 Deauth packets, clients get re-associated 3 times causing 12 EAPOL handshakes.

    Click on the image below to see in full resolution

    Snapshot : Wireshark Packet Capture on Target i.e. XP client