Deadlock in WiFi Networks

You might have experienced deadlock occurring in a chaotic traffic condition or if you are a software guy then must be aware of deadlock occurring in software programs. In simple term, deadlock is a condition which cease the progress of any process or operation.

Interestingly, the deadlock can also occur in a WiFi network. It happens between a wireless client and an access point (AP) at the time of connection establishment. 

To understand it better, let me first explain how connection establishment takes place between a wireless client device and an AP.

There are three important steps involved in connection establishment. First step is wireless network Discovery, second is Authentication, and third is Association.

Until and unless network discovery completes wireless client does not start Authentication and Association.

Figure 1: Connection Establishment

All WiFi networks are identified by a network name also known as Service Set Identifier or SSID. SSID is at most 32 characters string advertised in beacon frames which are periodically transmitted by APs. All clients in the proximity of an AP listen to these periodic advertisements and know the presence of a WiFi network. This is known as passive network scanning or discovery. Sometimes, wireless client devices send request frames to know the presence of a WiFi network. These frames are called “Probe Requests”. APs in the radio range of client listen to these request frames and respond thorugh “Probe Response” frames. These frames are very similar to Beacon frames and also contain the wireless network name. The process of discovering wireless network by sending probes is called active scanning or active discovery. 

Probe Requests may or may not contain the wireless network name. When no network name is present in “Probe Request” frame, it is known as Null Probe. These types of frames are used by client to discover any WiFi network present in the proximity of the client. Sometimes “Probe Request” does contain the name of the WiFi network. These types of frames are sent by a wireless client device when it looks for the presence of pre-configured wireless networks.

Wireless Client (In)Security

The active scanning done by client, especially when it leaks the trusted WiFi network name in the probe request frames, gives rise to various wireless attacks on client device. One example of such attack is setting up “Honeypot” to launch Man-in-the-Middle (MITM) attack. It’s very easy to launch honeypot attack on a wireless device which does active scanning for a WiFi network. In fact security enabled Honeypots are also possible.

WiFi clients configured to connect to WEP secured WiFi network can be victimized by launching Caffe Latte attack. WPA-PSK or WPA2-PSK (also called Personal Mode) configured clients can be lured by attacker with the help of airodum-ng and aircrack-ng tool. You can learn more about security enabled WiFi network here. A few clients which only connect to WPA2-802.1x based WiFi network and are not properly configured, they can be attacked by launching PEAP attack.

If you analyze, you will find that wireless enabled clients were victimized due to the reason that trusted WiFi network present in the client's memory were leaked during network discovery phase. In fact there exist a tool called WiFish Finder that will tell you which client is vulnerable to Honeypot attack and what kind of attack is possible. The tool is used to do security assessment of wireless client devices. 

To defeat attacks on wireless clients, Microsoft, in recent releases such as Windows XP service pack2 (SP2) and later, tricked the wireless client behavior. These clients are programmed not to leak the name of trusted WiFi network name present in its preferred network list (PNL) during active scanning. Null probes are sent by such clients during active scanning. If it finds a WiFi network advertising a name which matches with a network name present in it's PNL then only it tries to do connection establishment. More details about the behavior of Windows XP, Windows Server or Vista based wireless clients can be found here. http://technet.microsoft.com/hi-in/library/bb726942(en-us).aspx

So the security against Honeypot attacks have been achieved by not advertising or leaking the trusted wireless network name present in the PNL.

Access Point (In)Security

Disabling SSID broadcast has become common practice and is being widely adopted by network administrators as a security measure. Most AP vendors provide support to turnoff SSID advertisements. When you turn off SSID broadcasting, though the periodic wireless network advertisement frames are sent by AP, it does not contain network name. This prevents a casual user from locating private wireless network just by performing a simple network discovery (View available wireless network in Windows). Believe me; you do not achieve any security. In fact there are other ways of figuring out SSID of a non-broadcasting wireless network. (e.g. Probe Responses or Association Responses sent to connecting client do contain the name of wireless network, so if if you do wireless packet capture, you should be able to discover SSID of non-broadcasting wireless network).

So, it doesn't add anything to wireless security, at the same time it might create havoc in your existing wireless network deployment if you are planning to turn off SSID broadcast.

WiFi Connection Deadlock

Let’s take an example of WiFi network deployed in a big corporate network. The name of the network is “M-Mobile” and is being advertised initially. There is a WiFi user Jhon who is using a Windows XP and SP2 based WiFi client to connect to "M-Mobile". Jhon's client is automatically configured to connect to “M-Mobile”. One fine day, the network administrator Mr. Patrick learns that disabling SSID broadcast is a good security practice so he disables the SSID broadcasting on tens or hundreds of APs installed in the office premises and may be managed through a controller. Next day, when Jhon arrives office, he is not able to connect to WiFi network. He asks others, but other colleagues are still connected to the network may be because they leave their laptops in the office itself or whatever reason. Mr. Patrick, the administrator has absolutely no idea as what went wrong; all other users are still connected. What should he do? Should he rollback the change that he had applied yesterday or debug the problem of Mr. Jhon. What if Jhon works from distant office. Mr. Patrick might be helpless as he can't keep on flipping fully functional network settings so he might ignore the request and advice Jhon to use another machine. But it's important to understand the reason.

As soon as Mr. Patrick disables SSID broadcast, all APs present in the network stop advertising the name of the network. Clients which reveals the name of the trusted WiFi network in active scanning should be able to connect. But since Jhon is using a WiFi client which does not see advertise wireless network present in it’s preferred network list, so it send simply a null probe request. SSID broadcast disabled APs are not going to honor null porbe requests coming from Jhon's client and hence does not reveal the network name.

Figure 2: WiFi Connection Deadlock

As a result Jhon's client is not able to complete network discovery though the trusted WiF network exists in the range of the client. The scenario is depicted in the figure 2 above. Since the discovery does not complete, client does not initiate Authentication and Association with the AP and always remains in a wireless network scanning state. The condition in which wireless client is not able to discover its own trusted Wireless Network and the network is not able to serve legitimate wireless client device is termed as "Deadlock in WiFi Network".

First of all you should not turn off SSID broadcast, and if you done it and facing similar problem as reported by Jhon, then you must investigate and see whether you have your wireless network is in a Deadlock state or not.

The key take away of this post is:

"Disable SSID broadcast, but in Wireless Client Devices and Not in Access Points"

WEP, TKIP Declared Out…

If the fast spreading news on the Internet is to be believed, Wi-Fi alliance has decided to drop off WEP and TKIP encryption techniques from its certification criteria.

WEP was the only encryption techniques mentioned in the original IEEE 802.11 standard. Some flaws in the WEP encryption algorithm were discovered just after two years of release of WiFi standard and it was cracked in 2001. Since then several attacks on WEP have been published e.g. FMS attack, Korek attack, chop-chop attack, fragmentation attack, Aircrack-PTW attack, Caffe Latte attack etc.

TKIP was an enhancement over WEP. It was an attempt to provide better security to legacy WEP encryption capable devices and hence same RC4 technique with some modification was used in TKIP. The first and only attack on TKIP was published by Martin Beck and Erik Tews in 2008, five years after the release of TKIP specification for WiFi encryption. The attack was about injection of few small sized frames in the client to cause some disruption. It was not a key retrieving attack and unlike WEP, data privacy was guaranteed in TKIP.

The migration towards only-AES encryption mode will be done in stages over three years starting from 2011. From 2011, WiFi alliance will stop certifying APs with WEP or TKIP configuration. In 2012, wireless client devices will be axed for their support for WEP or TKIP. Starting from 2014, new WiFi devices which support only AES encryption will be certified. These requirements must be easily satisfied by device vendors by masking the disallowed encryption techniques just by applying software patch on the newly manufactured devices and if it happens, this will be a great move towards much needed secured wireless world.

A very interesting observation to note here is that the default configuration of most out of the box access points is “Open” which is a much bigger evil than WEP or TKIP. If a wireless LAN is operating in open mode all types of wireless attacks are possible e.g. data snooping, impersonation, unauthorized access to the network etc. The ideal move would be to support only one configuration in the Access Point and Client with the AES encryption as per the IEEE 802.11i and the IEEE 802.11w standard.

In short, the good (TKIP) and the bad (WEP) has been declared out but the ugly (Open configuration) will be continued to play!

Lessons from Apple’s WWDC Fiasco

If you haven’t heard about it, here is the condensed version of what happened on the opening day of iPhone 4G. The information has been gathered from various stories released on the Internet but the essence of all is same.

“Steve Job was trying to show the screen resolution and speed of the device by accessing a web portal that’s where the mishap happened. A completely saturated 2.4 GHz spectrum couldn’t distinguish between Steve’s new iPhone and hundreds of WiFi clients active at that location and hence the iPhone 4G was starved from getting wireless service.”

You may compare this scenario with a very heavily congested road. No matter what model or speed of the car is, one can not drive faster than the average speed of the traffic.

Could this have been avoided?

I am astonished to see every body (whether it’s WLAN infrastructure vendor or else) making claim that if Apple had used their solution or service, the problem would have never arisen. The way Ferrari can’t solve the very basic problem of congestion likewise iPhone 4G can’t solve the saturated link problem.

I have yet to see a solution which can accommodate hundreds of WiFi client devices or save 2.4 GHz from being saturated in the similar situation.

Yes there are solutions which could have raised alert on seeing too many devices operating in 2.4GHz band. Kudos to great Steve Job, he realized this very soon and requested his audiences to shutoff their WiFi warriors and saved his iPhone 4G demo!

If you are going to make such a crucial demo and planning to use WiFi you are bound to face the similar fiasco until you learn the lessons from Apple.


1. You ensure that there are not too many WiFi devices are operating in 2.4 GHz band. Its better to ask audience to switch of WiFi in the beginning.
2. If your device supports 5GHz band, better you use one channel in 5Ghz band
3. Always use security (WPA or WPA2 ) on your AP so that others can not connect to your device
4. Your demo environment should be free from Wireless DoS or jamming or at least it should be detectable
5. Have a WiFi expert not sales expert setup the WiFi infrastructure

Is Your Wireless Auditing Done Right?

WiFi is one of the newest networking technologies and hence auditing wireless networks is still a big challenge for auditors. It is mainly due to the unavailability of sophisticated solutions to cover all possible and realistic scenarios. More often than not the wireless network or security audits are done with the help of open source software/tools freely available on the Internet. These tools have some intrinsic limitations and hence do not always give answer to all the wireless auditing related questions. Due to the software limitations wireless auditing fail to ensure FIVE important wireless audit requirements are:

1. Presence of NO mis-configured, rogue or unmanaged wireless device on the trusted/authorized network
2. Presence of ALL authorized wireless device on the network Up and Running
3. Presence of the BEST wireless security configuration (e.g. WPA2/802.1x)for authorized wireless LANs
4. Presence of NO infected or rogue wireless client device
5. Presence of ALL wireless connection association logs for forensics purpose

Now we know what to see in the report when we get a wireless audit done next time !

WPA Cracking on Cloud

Yes, a cluster of about 400 CPUs could be used to test security of WPA-PSK protected wireless networks for only $17. WPA Cracker is an online cloud based key cracking service for penetration testers and network auditors who need to do security assessment of WiFi networks. WPA-PSK based WiFi networks are vulnerable to dictionary attack and takes several hours when run with a respectable size dictionary file. The online service would make feasible to test against 140 million word dictionary in less than an hour. You just need to upload a network capture file and start cracking and WPA Cracker will inform you the results within minutes.

It’s really great to see a bit of WiFi Pen testing as hosted service on Internet Cloud.

My question to the community: Isn’t it a right time to offer a complete package of WiFi security assessment/Pentesting on cloud?