Hello World! The 802.11 standard, as we know it today, was not designed to deal with unreliable traffic. Unlike a wired network, anyone with a $9 Wi-Fi card may intercept in-flight frames and eavesdrop on these invisible signals. Security was low on the priority list and proven unsatisfactory in the early.

In this post, I'll go through open network authentication, basics of WEP encryption, MAC filtering, and SSID cloaking. Learning about these methods will provide you a basic grasp of wireless networking security and the need for more secure algorithms, which I will explore in future postings.

New station devices are unknown to the access point, therefore the authentication phase is used to provide the identity of the station to the access point. I initially mistook it for network authentication, and used to think "Why aren't we sending the key here?" Later, however, I learned that it works similarly to setting up a link, which is what we used to do in wired networking by plugging the Ethernet cable into the RJ45 slot on our computer.

It starts with station initiating the authentication request and then as an acknowledgement the access point sends the authentication response. No data encryption or security is available at this stage or in the next stage, i.e Association.

However, there is only one subtype named Authentication in the management frame table. To obtain these frames, use the following filter in the Wireshark display filter.

wlan.fc.type_subtype == 0x000b

The difference between the request and response can be determined from the authentication sequence number: 0x0001 is for request and 0x0002 for response. This can be found in the "Fixed Parameters" of the management frame. Since the sequence number in this instance is 0x0001, communication is directed from the station to the access point. The access point will then acknowledge the successful authentication by returning the sequence number 0x0002, as shown below.

After successful authentication, the station now moves to the association phase to join network obtain an Association Identifier (AID). It will be then used when the stations goes in power save mode and then access point wants to send buffered frames while keeping a track of it. You can filter the association request and response frames using following display filter.

wlan.fc.type_subtype == 0x0000 || wlan.fc.type_subtype == 0x0001

As you can see this frame contains association information in the Fixed parameters and some of the information obtained from beacon frame or probe response frames in the Tagged parameters field.

Next you will see the access point will reply with association response containing the association id (AID) of the station.

Disconnecting from Wi-Fi Network

When the station wants to disconnect from the network, it sends a notification in form disassociation and later deauthentication to terminate all the network. Deauth frame is management frame having sub-type value 0x0c.  You can filter it using below wireshark filter.

wlan.fc.type_subtype = 0x000c

Here is a capture of a Deauthentication frame. In this case, client station specify reason code a 0x0003, which means the station is deauthentication because it is leaving the network.

In the preceding example, the station sends the deauthentication to the client, but this is not always the case. Deauthentication frames can also be sent by an access point. For example, one of the known reasons is that the client is inactive, with the reason code 0x0004. Here is an image of the same from mrncciew.com blog.

This feature is very old, and is being used since Ethernet based networking. It is belived that every network card has a unique MAC address which is hardcoded by the vendor and used to direct the frames in the wireless network.

Network admins in the organizations used this approach to whitelist certain MAC addresses from the access point console, which means that any station whose MAC addresses are not on this list will not be able to pass traffic through the access point.

Here is the screenshot I have taken from my Home acccess point console. It is used to block all the frames originated from D0:54:2D:00:00:00 device, including authentication and association and blocking the access of the device on the network running SSID1.

Note – A single Wi-Fi network can support up to 8 SSIDs. In my case, this is a logical name assigned by the designer of the access point operating system.

This is where it gets funny! To bypass such MAC filter safeguards, anyone can spoof or impersonate these MAC addresses; all you need to do is enter the new address into the device using some administrative privileges. MAC filtering is not considered a reliable means of security for wireless enterprise networks due to spoofing and the administrative work involved in setting up MAC filters.

I recommend you to read the following article where I have used macchanger utility in Linux to bypass such security.

The logical identifier, or logical name, of your wireless network is the service set identifier (SSID). It's the same as giving a non-living thing a human name. The access point will broadcast beacon frames by default to advertise its existence, but this can be disabled from the console; such networks are known as Closed Networks.

This screenshot is from my access point console, and it shows that SSID broadcast is enabled. If I disable it and save the configuration, new stations will be unaware of its existence.

When I first discovered this feature, I thought it was clever. How can you attack when I'm not even present? The device can only connect to the network if it receives a successful probe response for the SSID name specified in the probe request.

If there is at least one station connected to the network, an attacker can send deauthentication frames forcing the station to send the probe request containing the SSID name of the target network to re-establish the connection.

Since data is freely and publicly transmitted in the air, proper protection is required to guarantee data privacy. Therefore, layers 3 through 7 + some LLC data, together called MSDU payload, require strong encryption. Although using WEP encryption with Open Authentication is optional, doing so was recommended because it uses specific mathematical operations to encrypt the data so that it can be sent securely over a medium after authentication and association occur.

WEP uses RC4 stream cipher as its encryption algorithm, which is used to encrypt the MSDU payload derived from LLC sublayer. It also provides the data integrity check by calculating a hash of the clear-text payload using the 32-bit Cyclic Redundancy Check (CRC-32) algorithm. This is known as  Integrity Check Value (ICV), which guards against data tampering in transit.

WEP keys come in two different configurations: a 40-bit static key and a 104-bit static key. Both keys are supposed to have a 24 bit initialization vector prepended to them. Since IVs are generated on the transmitter's end, they must be sent in clear-text; otherwise, the receiver won't be able to use it to derive the decryption key, which must be used to perform the decryption, followed by an integrity check to confirm the received payload.

The attacker can quickly exhaust this 24-bit room of IVs while keeping track of them all. WEP encryption becomes risky in this situation because it is easily broken.

You're probably wondering why IV was used; can't IEEE just get rid of it? If the IV was not used, it would be much easier to break the encryption, that is because it will always produce identical encryption for the same text. With the implementation of IV, it is guaranteed that the cipher text for the same message you want to encrypt will be different for each different value.

You can use the following filter in the Wireshark to display all the Data and QoS Data frames and focus on the WEP parameters in the "IEEE 802.11 Data" section.

wlan.fc.type == 0x2 && ( wlan.fc.subtype == 0x0 || wlan.fc.subtype == 0x8)

This data frame is currently encrypted, wireshark is unable to verify the actual contents of the MDSU, which is why you see "not verified" in front of the WEP ICV field. For the encrypted packets, this is normal.

After providing the correct key in the wireshark preferences, it tried to decrypt the frame. Now you will see "correct" in front of WEP ICV field and also this frame corresponds to ARP Request.

If you may have noticed, there is another field "Key Index" in the WEP parameters which is used to inform which key the transmitter has used to encrypt the message. This value can only be in range of \( 0 - 3 \) as defined in WEP specifications. If the receiving device does not the key defined at that index, the data will not be decrypted.

• https://www.intel.com/content/www/us/en/support/articles/000006508/wireless/legacy-intel-wireless-products.html
• https://networklessons.com/cisco/ccna-200-301/wireless-authentication-methods
• https://en.wikipedia.org/wiki/802.11_Frame_Types#Types_and_SubTypes
• https://mrncciew.com/2014/10/10/802-11-mgmt-authentication-frame/
• https://mrncciew.com/2014/10/28/802-11-mgmt-association-reqresponse/
• https://mrncciew.com/2014/10/11/802-11-mgmt-deauth-disassociation-frames/
• https://www.cisco.com/assets/sol/sb/WAP371_Emulators/WAP371_Emulator_v1-0-1-5/help/Apx_ReasonCodes2.htm
• https://en.wikipedia.org/wiki/Cyclic_redundancy_check
• https://en.wikipedia.org/wiki/RC4
• https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
• https://www.informit.com/articles/article.aspx?p=102230&seqNum=6
• https://www.techtarget.com/whatis/definition/initialization-vector-IV
• https://blog.cryptographyengineering.com/2011/12/15/whats-deal-with-rc4/
• https://www.bengrewell.com/2018/02/11/decloaking_hidden_wireless/