Table of contents
The structure and functionality of deauthentication frames are something we get asked about regularly. So we thought it was time for a blog post to explore what they are and how they work.
What is a Deauthentication Frame?
The Deauthentication Frame is a type of packet defined in the IEEE 802.11 WiFi standard. It has been part of the standard since the beginning and still plays an important role.
It's used to terminate a WiFi connection. It can be sent by either the access point or the station to let the other side know that the connection is closed.
In case you're unfamiliar with the terminology, the access point (AP) is a device that provides access to a WiFi network, for example, your home router. While a station is a client device that can connect to an access point, for example, your phone.
The station might send a deauthentication frame to the access point because it's switching to another WiFi network. Or the access point might send a deauthentication frame to the station because the router has to restart. Deauthentication works both ways, and there are plenty of reasons why they are sent - you can find a complete list of reasons below.
But one crucial attribute of the deauthentication frame is that it's not a request; it's a notification, and it can not be refused.
Structure of a Deauthentication Frame
The actual data the packet holds is very minimal:
Deauthentication frame body
Order | Information |
1 | Reason code |
Last – 1 | One or more Vendor Specific elements are optionally present. |
Last | The MME is present when management frame protection is enabled at the AP and the frame is a group addressed frame. |
But if you look at a deauthentication frame in Wireshark, you'd see more than just the frame body. That's because deauthentication packets are part of the family of WiFi management frames, and their format looks like this:
Octets | Description |
2 | Frame Control |
2 | Duration |
6 | Address 1 |
6 | Address 2 |
6 | Address 3 |
2 | Sequence Control |
0 or 4 | HT Control |
variable | Frame Body |
4 | FCS |
In the DeautherX's code, a packet looks like this:
COPY
uint8_t deauthPacket[26] = {
/* 0 - 1 */ 0xC0, 0x00, // type, subtype c0: deauth (a0: disassociate)
/* 2 - 3 */ 0x00, 0x00, // duration (SDK takes care of that)
/* 4 - 9 */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, // reciever (target)
/* 10 - 15 */ 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, // source (ap)
/* 16 - 21 */ 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, // BSSID (ap)
/* 22 - 23 */ 0x00, 0x00, // fragment & squence number
/* 24 - 25 */ 0x01, 0x00 // reason code (1 = unspecified reason)
};
Deauthentication frame definition in DeautherX code You can find this definition in the Attack.h file.
You might notice that some data is left out of this array. For example, the frame check sequence (FCS) is not defined here. That's because it's already handled by the underlying ESP8266 SDK functions automatically. The same goes for the duration and the flags in the second byte of the frame control field.
Reason codes
As mentioned, every deauthentication frame has to contain a code for the reason of disconnect. Here is a list of the available reason codes and what they mean.
Yes, the list is quite long...
Code | Description |
0 | reserved |
1 | Unspecified reason |
2 | Previous authentication no longer valid |
3 | Deauthenticated because sending STA is leaving (or has left) the BSS |
4 | Disassociated due to inactivity |
5 | Disassociated because AP is unable to handle all currently associated STAs |
6 | Class 2 frame received from nonauthenticated STA |
7 | Class 3 frame received from nonassociated STA |
8 | Disassociated because sending STA is leaving (or has left) BSS |
9 | STA requesting (re)association is not authenticated with responding STA |
10 | Disassociated because the information in the Power Capability element is unacceptable |
11 | Disassociated because the information in the Supported Channels element is unacceptable |
12 | Disassociated due to BSS transition management |
13 | Invalid element, i.e., an element defined in this standard for which the content does not meet the specifications in Clause 9 |
14 | Message integrity code (MIC) failure |
15 | 4-way handshake timeout |
16 | Group key handshake timeout |
17 | Element in 4-way handshake different from (Re)Association Request/Probe Response/Beacon frame |
18 | Invalid group cipher |
19 | Invalid pairwise cipher |
20 | Invalid AKMP |
21 | Unsupported RSNE version |
22 | Invalid RSNE capabilities |
23 | IEEE 802.1X authentication failed |
24 | Cipher suite rejected because of the security policy |
25 | TDLS direct-link teardown due to TDLS peer STA unreachable via the TDLS direct link |
26 | TDLS direct-link teardown for unspecified reason |
27 | Disassociated because session terminated by SSP request |
28 | Disassociated because of lack of SSP roaming agreement |
29 | Requested service rejected because of SSP cipher suite or AKM requirement |
30 | Requested service not authorized in this location |
31 | TS deleted because QoS AP lacks sufficient bandwidth for this QoS STA due to a change in BSS service characteristics or operational mode (e.g., an HT BSS change from 40 MHz channel to 20 MHz channel) |
32 | Disassociated for unspecified, QoS-related reason |
33 | Disassociated because QoS AP lacks sufficient bandwidth for this QoS STA |
34 | Disassociated because excessive number of frames need to be acknowledged, but are not acknowledged due to AP transmissions and/or poor channel conditions |
35 | Disassociated because STA is transmitting outside the limits of its TXOPs |
36 | Requesting STA is leaving the BSS (or resetting) |
37 | Requesting STA is no longer using the stream or session |
38 | Requesting STA received frames using a mechanism for which a setup has not been completed |
39 | Requested from peer STA due to timeout |
40–45 | Reserved |
46 | In a Disassociation frame: Disassociated because authorized access limit reached |
47 | In a Disassociation frame: Disassociated due to external service requirements |
48 | Invalid FT Action frame count |
49 | Invalid pairwise master key identifier (PMKID) |
50 | Invalid MDE |
51 | Invalid FTE |
52 | Mesh peering canceled for unknown reasons |
53 | The mesh STA has reached the supported maximum number of peer mesh STAs |
54 | The received information violates the Mesh Configuration policy configured in the mesh STA profile |
55 | The mesh STA has received a Mesh Peering Close frame requesting to close the mesh peering. |
56 | The mesh STA has resent dot11MeshMaxRetries Mesh Peering Open frames, without receiving a Mesh Peering Confirm frame. |
57 | The confirmTimer for the mesh peering instance times out. |
58 | The mesh STA fails to unwrap the GTK or the values in the wrapped contents do not match |
59 | The mesh STA receives inconsistent information about the mesh parameters between mesh peering Management frames |
60 | The mesh STA fails the authenticated mesh peering exchange because due to failure in selecting either the pairwise ciphersuite or group ciphersuite |
61 | The mesh STA does not have proxy information for this external destination. |
62 | The mesh STA does not have forwarding information for this destination. |
63 | The mesh STA determines that the link to the next hop of an active path in its forwarding information is no longer usable. |
64 | The Deauthentication frame was sent because the MAC address of the STA already exists in the mesh BSS. |
65 | The mesh STA performs channel switch to meet regulatory requirements. |
66 | The mesh STA performs channel switching with unspecified reason. |
67 | Transmission link establishment in alternative channel failed. |
68 | The alternative channel is occupied. |
69–65535 | Reserved |
Disassociation vs. Deauthentication
Besides the deauthentication frame, there is also the disassociation frame. They sound similar, work similar, and their structure is basically identical.
To understand the difference between Disassociation and Deauthenticatios, we have to understand the difference between WiFi association and authentication.
When you connect to a WiFi network, you first authenticate yourself. This is done by entering a password, for example. Then, to use the WiFi network, you now have to associate to an access point. It's simply another step before you can start browsing the web through WiFi. Of course, this is all done automatically and really fast.
In the case of a regular home router, you both authenticate and associate to the same access point. And if you disconnect, you both deauthenticate and disassociate to the same access point. But in a larger network made out of multiple access points, you might disassociate from one access point and associate to a new one while staying authenticated to the same network.
How deauthentication frames can be exploited
Deauthentication frames are very simple in their structure. You basically only need a sender or receiver MAC address. And you can obtain such by simply scanning for WiFi devices nearby.
So it's super easy to spoof a deauth packet. And keep in mind that if the target receives it, it has to drop its connection.
The target can reconnect immediately, of course, and it can do that quite fast, maybe without the user noticing that the connection was ever dropped. But if these deauth packets are sent continuously, it results in a denial of service attack, and network access is blocked for the entirety of the attack.
Luckily this was addressed, and we now have protected management frames! This feature allows packets like deauthentication frames to be safe against spoofing.
The only problem with this feature is that not every access point has it enabled yet. If you want to test if your network is safe against this type of attack, check out our DeautherX project.