1 Introduction

In this paper we present a case of wireless hacking which is a form of Denial of Service (DoS) Attack on Wi-Fi, or Wi-Fi Jamming, called Mass Deauthentication Attack (Mass Deauth), which is based on Deauthentication Attack [1]. Different from some Wi-Fi Jamming which flood the physical frequency with noise, which operates at level 1 of the OSI model, Mass Deauth operates at level 2. Operating on level 2 gives the advantage of the ability to specifying attack target, but comes with the disadvantage of replying on the design flow of existing protocol, which may be corrected in the future.

2 System

The system consists of three parties, the Access Point (AP), the client and the attacker. AP provides network access to client through Wi-Fi. AP is identified by Basic Service Set Identification (BSSID), which is the Media Access Control (MAC) address of the Network Interface Controller (NIC) attached to the AP. Client, also identified by the MAC address of the attached NIC, is a device (e.g. laptop, smart-phone) that needs network connection through Wi-Fi. attacker is the party that launches the Mass Deauth Attack. The Mass Deauth Attack launched by the attacker is considered to be successful if multiple AP-client pair are disconnected.

3 Mass Deauthentication Attack

Similar to a Deauth Attack [1], Mass Deauth Attack requires certain information about the attack target -- the BSSID of AP, the MAC of client and the Wi-Fi channel used for communication, all of which can be obtained through sniffing.

3.1 Sniffing

In order for the attacker to obtain information required for the attack, it needs to control a NIC that supports Promiscuous Mode and is in close proximity of the attack target.

The attacker will capture two kinds of 802.11 Frames, (1) Beacon Frames sent by the AP and (2) Data Frames sent between client and AP and discards all other frames. The attacker may filter out frames coming from AP or client that it does not wish to attack at this stage. Frames sent to a broadcast or muticast MAC address should also be filtered out, as the MAC address does not identify a AP or client. All the captured frames are then processed to extract the needed information.

3.2 Information Extraction

The 802.11 header of the captured frames contains the MAC information that is needed, but the information extraction process is not straight forward. The structure of the 802.11 header can be seen in the figure below retrieved from the WildPackets website [3].

802.11 Header [3]

3.2.1 Beacon Frames

For beacon frames, both field Address 2 and Address 3 contain the BSSID of the AP sending the beacon, shown in the table below.

The channel information, however, is not in the 802.11 header, it is in the encapsulated in the Network Data field of 802.11 beacon frame as an Information Element. In the beacon frames, the channel information is encapsulated in two IE, that is the IE that contain the channel information is encapsulated inside an IE, which is then encapsulated by another IE (this contain the ESSID of AP), which is then encapsulated by 802.11 frame.

3.2.2 Data Frames

For data frames the situation is more complicated, two more fields, to DS and from DS must be taken into account to identify the AP BSSID and client MAC.

Frames with To DS set to 0 and From DS set to 0 contains the MAC of two different client in field Address 1 and Address 2 respectively, the BSSID of AP in Address 3. Frames with To DS set to 0 and From DS set to 1 contains the MAC of a client in field Address 3 and BSSID of the associated AP in Address 2. Frames with To DS set to 1 and From DS set to 0 contains the MAC of a client in field Address 3 and BSSID of the associated AP in Address 2. Frames with To DS set to 1 and From DS set to 1 are not taken into consideration. All of which can be seen in the table below, the information is retrieved from the WildPackets website [3].

3.3 Deauthentication Attack

For each client-AP pair, the attacker sends two kinds of deauthentication frames. One targeted at the client while masquerading as the AP associated with client, and another target at the AP while masquerading as the client. The 802.11 header of the two kinds of deauthentication frames can be seen in the table below.

4 Implementation

Our implementation can be found on our GitHub repository [4]. It uses Python 2.7, Airocrack-ng [5], libffi [6] and three python modules, Scapy [7], CFFI [8], Gevent [9]. Airocrack-ng puts the NIC into monitor mode. libffi and CFFI together allow our program to call the call the C interface directly. Gevent enable us to use coroutine rather creating threads, which reduces the requirement on system resources. Airocrack-ng, libffi, CFFI and Gevent are dependencies that are not critical to the operation of the program, and maybe replaced with tool that are more common

While there are already multiple implementation of Mass Deauth programs available [10,11], our program has the following advantages: (1) it calls the C code that switches the channel that the NIC operates on, rather than spawning another process, which may be 100 times faster when we compare the two on our test machine; (2) it specify an client MAC rather than using broadcast MAC address deauthentication frame. Some client devices are known to discard broadcast deauthentication frames [12]; (3) unlike some implementation that only do Deauthentication Attack on clients connected to a single AP, our implementation attack all the AP and client in close proximity.

4.1 States

Our program has four states (1) AP Discovery, sniff beacon frames sent from AP in close proximity, create a list of discovered AP \(A\) and associate each AP with the channel \(n\) it operates on. (2) Channel Switching, select a channel that has at least on AP operating on, switch NIC to the same channel \(n\). (3) Client Discovery, sniff data frames sent on the channel \(n\), create a list of client \(C\) for each AP on that channel. (3) Mass Deauth Attack, for each AP in the AP list \(A\), switch to the channel it operates on, and send Deauthentication Frames to the client and AP for each client in \(C\) that is associated with the AP. The program then goes back to state (2) but will choose a different channel. As seen in the figure below.

Program States

4.2 Environment

In our test environment we use Rosewill RNX-N150HG connected through USB with Linux Mint 17 Qiana. The AP is a Actiontec MI424WR Rev. I router, and for the client we use two iPhone 5C.

4.3 Execution

Here we provide several screen shots during the execution of our program.

Sniffing Date Frames on Different Channels

Sending Deauth Frames to Client 1

Sniff Data Frames on Channel 11

Sending Deauth Frames to Client 1 & 2

Sending Loop between State 2 to 4

5 Mitigation

There are two methods to mitigate a Mass Deauth Attack, both prevents the dissociation frames sent by the attacker from taking effect, similar to the mitigation of a Deauthentication Attack.

Using a Faraday Cage mitigates the attack at the physical level, or level 1 in the OSI model. Faraday Cage can isolate the network from the attacker, preventing any frame sent by the attacker from reaching the Wi-Fi network. This method, however, has several draw back that makes it impractical. First, the AP and all the clients must be inside the Faraday Cage, which may be restricted in size. Second, other measures must be taken to prevent the attacking from entering the Wi-Fi network (e.g. preventing the attacker hacking and taking control of a laptop inside the cage). If the attacker manage to enter the Faraday Cage this method cannot mitigate the Mass Deauth Attack.

Adopting the IEEE 802.11w is a more feasible approach to prevent Mass Deauth Attack. The 802.11w standard defines a set of frames, which includes the dissociation frame, that must be sent along with a Message Integrity Code (MIC) computed with a shared-secret unknown to the attacker. Since the attack does not know the shared-secret, the dissociation frames it sends will be discarded by both the client and AP as the MIC will be incorrect. This methods still has drawbacks. First, a Deauthentication Attack is still possible, however the Wi-Fi network becomes less vulnerable as the size of the client pool increases [2]. Second, while several enterprise router (e.g. Cisco, supports the standard (depending on the manufacturer it may be called Protected Management Frames [13] or Management Frame Protection [14]), the standard is not widely adopted in non-enterprise environment. For a home-user or small business, the only option is to use a router that can be flashed OpenWrt [15] with a NIC thats can be used with the ath9k driver, combined with a device that is installed with Microsoft Windows 8 or newer.

6 Conclusion

In this paper we proposed an attack on Wi-Fi network called Mass Deauthentication Attack that can cause a Denial of Service among clients that needs a network connection through Wi-Fi in close proximity of the attacker. Mass Deauth need the MAC of client and the BSSID of the associated AP and their channel of communication in order to launch the attack, all of the information may be extracted from sniffed 802.11 frames.

We also provided an implementation of Mass Deauth attack that can run on Linux, Python 2.7 (with Scapy, CFFI, Gevent), libffi and Airocrack-ng. To mitigate a Mass Deauth Attack we provided two methods, either using Faraday Cage or adopting the 802.11w standard. Adopting the 802.11w standard requires either switching to an enterprise router, or using OpenWrt based router.

Overall, Mass Deauthentication Attack exploits the design flaws within the IEEE 802.11 standard, more specifically, it depends on the fact that management frames, which are essential for Wi-Fi, are not authenticated, thus may be spoofed. Since Mass Deauth exploits the design flaw at the software layer, we expect attacks based on Deauthentication Attack to become obsolete when IEEE 802.11w standard becomes widely adopted.