Are You Betting on Wireless Clients?

If yes, be watchful as you might be on the verge of inviting serious security risks to your enterprise network or confidential data residing on the network. Unlike APs, WiFi enabled clients are physically unconnected mobile end points. They keep moving in and out of your wireless networks and might carry infected wireless network profile. In this blog post, I am going to share with you how a wireless client device can easily break the security cordon of an enterprise network.

Infected Clients

An infected wireless device present on the corporate network is a serious security threat. Here infection doesn't mean infected from virus or worms. Such problems are already known. A wireless infection can create backdoor. These infection occurs when a roaming wireless client connect to insecure WiFi network. There are two types of infection possible:

a. Probing clients

Wireless devices keep the memory of wireless network they have connected to in the past and keep probing for such networks. This gives opportunity to hacker to launch honeypot attach on a corporate wireless device. Once the infected corporate client connects to attacker planted "Honeypot" several other upper layer attacks can be launched to take root access of the machine. Imagine if the infected client is connected to corporate network through ethernet. Attacker can exploit and access corporate network as well. This puts serious threat to the data residing on corporate client device as well as corporate network.

b. Adhoc mode

A corporate client device can be infected from Ad hoc mode or Viral SSID profile. Such a client invites peer to peer connection from other wireless client devices. Attackers looking for an opportunity to break into corporate network can make first connection with infected client device. Later, she can run higher layer attacks or exploits to gain root access of the machine. Once the access to machine is taken attacker can also connect ti corporate network and scan for vulnerable machine on the network. This puts serious threat to the data residing on corporate client device as well as corporate network.

Virtual AP Threat

Windows 7 has included a new wireless feature called virtual WiFi or virtual AP which allow its user to run a fully functional access point on a laptop with just a few clicks. Similar features are also available in different operating system and different types of mobile devices e.g. Intel’s MyWiFi works on Windows Vista as well as on Windows 7 operating system and allow user to run AP with any type of security configuration. If the client device is connected to corporate network and having a virtual AP running in open configuration, any unauthorized user connect to virtual AP and gain access of the corporate network.

 

It's equally important to scan for wireless client and deter whether a client is carrying infected wireless profiles or running virtual AP. This can be achieved by using a wireless network monitoring system.

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"

Top Five Windows Based Wireless Attack Tools You Should Really Know About

[Category-Security]

Plethora of wireless attack tools are freely available on the Internet.  But most of these tools are written for Linux platforms. A naïve user might not comfortably run these tools as it requires good knowledge of tools and the underlying system.

Windows (XP, Vista or 7) is the most popular and widely used operating system in the world. It provides click based environment to interact with any application. Since most of us already feel comfortable working in Windows based environment, we do understand its power of quickly turning even a naïve user into a skilled one. But the unavailability of free wireless tools for Windows machines have kept their users afar from playing with wireless networks  in the past. But lately, windows based tools have started showing up. What if people start getting access to these attack tools. Wouldn’t it give rise to new security threat in an enterprise network environment?

In this post, I am going to  brief you about such tools and what all is possible using these tools.

Tool #1. CommView for WiFi

CommView for WiFi is a very powerful wireless network monitor and analyzer tool for 802.11 a/b/g/n networks. It is paid software but limited period, evaluation version is freely available for download.

Some of the things one can do with CommView for WiFi are mentioned below:

• Scan the air for WiFi stations and access points and capture 802.11a, 802.11b, 802.11g, and 802.11n WLAN traffic
• Specify WEP or WPA keys to decrypt encrypted packets
• View detailed IP connections statistics: IP addresses, ports, sessions, etc
• Reconstruct TCP/UDP sessions
• Search for strings or hex data in captured packet contents
• Load and view capture files offline
• Modify and inject captured frame; It also supports injection of all captured traffic

CommView runs under Windows XP/2003/Vista/2008/7 and requires a compatible wireless network adapter. The list of adapters that have been tested and are compatible with CommView for WiFi, are available at http://www.tamos.com/products/commwifi/adapterlist.php

Figure 1: Snapshot of Running CommView

So, using an evaluation version of CommView for WiFi, one can actually capture all the wireless traffic, sniff password in an open WiFi network. A malicious insider can decrypt private data frames of other wireless users in WPA-PSK or WPA2-PSK enabled wireless networks.

Packet injection capability can be exploited to launch denial of service attack, stealth mode ARP spoofing attack in an open Wireless Network and what not. It completely depends on the imagination of an intruder.

So, using an evaluation version of CommView for WiFi, one can actually capture all the wireless traffic, sniff password in an open WiFi network. A malicious insider can decrypt private data frames of other wireless users in WPA-PSK or WPA2-PSK enabled wireless networks.

Packet injection capability can be exploited to launch denial of service attack, stealth mode ARP spoofing attack in an open Wireless Network and what not. It completely depends on the imagination of an intruder.

Figure 2: Raw Packet Injection

Tool #2: Aircrack-ng

Aircrack-ng is an 802.11 WEP and WPA-PSK keys cracking program that can recover keys once enough data packets have been captured. It implements the standard FMS attack along with some optimizations like KoreK attacks, as well as the all-new PTW attack, thus making the attack much faster compared to other WEP cracking tools.

In fact aircrack-ng is a suite of wireless tools that can be used to capture traffic, setup Access Point (AP), Launch denial-of-service (DoS) attack and cracking encryption.

Previous version of aircrack-ng was supported only on Linux distribution.  But the latest version is also supported on Windows. The software can be free downloaded from the Internet at http://www.aircrack-ng.org/

Tool #3:Mdk-3

MDK can be put in the category of denial-of-service (DoS) attack tool. It exploits the wireless driver of Commview software to do packet capture or injection. This is less heard tool and not much information is available on the Internet yet it's been tested and talked in hackers community.

More information about the software is available here.

Tool #4: Connectify 

Connectify is a third party application that allows user to run a full fledge WiFi hotspot on a WiFi enabled machine. While this is a great way of sharing the Internet with friends, co-workers, and mobile devices, it weakens the security cordon of a corporate network by simply converting WiFi enabled authorized corporate laptops into unmanaged rogue devices.

 

Current version of the software is compatible only with Windows 7.

 

In the same category falls Intel's  "My WiFi" wireless technology. It helps form a wireless Personal Area Network (PAN). Basically, you can run wireless access point if you have a laptop with Intel's latest wireless card inside e.g. Centrino Wireless-N 1000, 5100 or 6200. Intel provides MyWiFi software using which you can run virtual AP and choose any security configuration and in fact you can also run open WiFi AP. The technology is supported both on Windows Vista and Windows 7.

 

Tool#5: Meraki's "WiFi Stumbler" and WLANController's Virtual Access Point

These are the examples of cloud based tools. Installation is not needed. You just need to have access to the Internet, that's it.

The first is Meraki's WiFi Stumbler. It can be used for wireless network scanning. Using this tool you can instantly know various important attributes of a wireless network e.g. MAC address, signal level, encryption type, channel etc. This is a very powerful tool if you are interested in conducting wireless scan. No additional hardware is needed. You can use your own machine. But it can also be misused by attacker to scan and select the target.

 

Figure3: Meraki's WiFi Stumbler

Second interesting cloud based tool is "Virtual Access Point" software offered by www.virtualaccesspoint.com. If you want to run your own access point on Windows 7 and don't want take the risk of software installation then this would be the best bet. Enter the SSID and WPA2 Key and behold! Your virtual AP is up and running. Here is a video that shows how you can run your own AP in just 60 seconds.

 

 This can be misused in launching security enabled Honeypot AP. I have posted the technical details of WPA2 Honeypots here.

So the conclusion is that almost all attacks are possible using Windows based wireless attack tools. This is going to increase the security and manageability risk on network administrator. One more reason why you need to monitor your air 24 x 7.

If you are aware of any other Windows based wireless attack tool, please do share with us. I would love to test and write about that. Cheers!

Beware Road Warriors! WPA2 Honeypot APs Might Haunt You.

Did you know that security enabled Honeypot APs are also possible. If not, you must read this. Wireless clients configured to connect to WEP secured WiFi networks can be attacked even if they are roaming thousands of miles away from their trusted WiFi networks. Just recall, how WEP cracking is done. One can either passively sniff and collect enough WEP encrypted DATA traffic. An active attack on WEP encrypted WiFi network is also possible. It requires presence of a wireless client and an AP and one encrypted ARP frame from client to AP. Attacker can replay this frame to generate more encrypted data traffic. Once the sufficient amount of data traffic is collected then aircrack-ng tool can be used to crack the WEP key. But in Caffe Latte attack, researchers have shown that WEP key can still be cracked even if client is not connected to any AP and present too far from its trusted WiFi network. 

Now, you might think why you should worry about it. You do not use WEP any ways. Your wireless device is configured to connect to WPA-PSK or WPA2-PSK based WiFi network. Then, here is a bad news for you. Author of the most popular WiFi cracking open source software has presented about PSK cracking in UNAM, Mexico. His talk can be downloaded from here. As per him older version of aircrack-ng tool needed all four frames of 4-way handshake to launch dictionary attack against PSK. But the latest version of aircrack-ng attack tool has been enhanced and now it only requires any two subsequent frames to launch attack.

Does this mean a PSK enabled WiFi honeypot AP can be planted to lure WiFi clients which have been connecting to such WiFi networks in the past. The answer is yes. If you see the 4-way handshake in the figure above, WiFi client device is first authenticated by AP. AP sends a 256 bit random number called ANONCE to challenge Client. Client responds to the challenge by generating MIC using Pairwise Transient Key (PTK). PTK generation requires knowledge of Passphrase, SSID, ANONCE and SNONCE. SNonce is also a 256 bit random number generated by client device to challenge AP.

An attacker can configure a Honeypot AP with any "passphrase". When a roaming wireless client connect to WPA2-PSK honeypot, it initiates higher layer 4-way handshake with the AP. Since the AP is not configured with right Passphrase as attacker does know this now, client does not authenticate Honeypot AP and does not connect to it. But in lieu of this attacker is able to capture initial two frames of 4-way handshake as shown in the figure above. Only these two frames are enough for latest aircrack-ng tool to launch dictionary attack and crack the passphrase, 

In fact, there is an online PSK cracking service available. I have written about wpacracker in the past. The trace file captured earlier can be uploaded to the wpacracker site and PSK can be cracked.

A few wireless clients which connect to WPA2-802.1x secured WiFi network can be victimized by setting up Honeypot AP. The attack is known as PEAP attack. Only those wireless Clients are vulnerable to this attack which do not verify certificate sent by an AP.

So the conclusion is that security enabled Honeypots are also possible. If you connect to WPA-PSK or WPA2-PSK based WiFi network then make sure the passphrase is a random mix of aphanumeric characters and its size is more than eight characters. If you are using PEAP, then make sure that wireless clients verify certificate sent by an AP.

How Not To Kill Your Wireless Network Capacity

[Part 1]
This post of mine has nothing to do with wireless network security. But I have experienced people making mistakes and killing the overall network capacity by making mistakes during deployment. And hence, this time I am going to talk about how you should not kill your wireless network capacity.

The part 1 is basically focussed on a few tips presented here on how to maintain network performance. In future posts, I will present few more interesting stuff about the wireless network performance and monitoring.

Let's first recall and memorize rules of the game:

1. The overall network throughput of an IEEE 802.11 based wireless network is fixed. It depends on the protocol (a/b/g/n) you are using.


2. Should avoid deploying APs on the same channel. It cuts down the throughput offered by an AP present on the channel.


3. Should avoid deploying APs on adjacent channels (non-overlapping channel in 2.4 GHz band). It cuts down the throughput offered by an AP present on the channel.


4. Should understand the WiFi deployment requirements (Number of clients per AP, Average throughput per client or coverage area) and stick to these requirements while making any changes in the network.


5. Should try to minimizing the overhead of creating multiple wireless network on a channel without affecting the network deployment requirements

Though the observation presented by Mr. Andrew in his post is absolutely correct, the tips presented by him has some penalty that needs to be learnt in advance.

Though there should not be APs operating in the proximity of each other on the same channel, yet creating of multiple SSIDs does waste the bandwidth and only in 2.4 GHz band in mixed mode (b/g) deployment and not in pure 'a' or 'g' mode deployment. About 2% loss can probably be ignored. Further, the suggestion made here would help reduce the wastage of bandwidth due to multiple beacon transmission in 'g' and 'a' band as well. Let's take a loot at the penalty that we have to pay:

1. By limiting the active SSIDs per AP, you are basically limiting the support of segmented wireless networks created on an AP.
2. Disabling low data rates means reducing the range of network. This can create coverage hole. You may have to revisit your network deployment requirements and see if coverage was the important requirement.

Network bandwidth waste can be reduced by configuring APs to transmit beacons less frequently. For example loss of bandwidth in 2 SSIDs scenario can be compensated by doubling the beacon interval. By default APs are configured to transmit beacons every 100ms. The beacon interval can be increased or decreased. So just by doubling the beacon interval you should be able to support 6 SSIDs per-AP while limiting the bandwidth waste equivalent to the use of 3 SSIDs per-AP.

In fact, you can also compensate the data rate reduction by increasing the beacon interval to 400ms in a non-VOIP network deployment.

Point is, use of multiple SSIDs do cause waste of network bandwidth. There are many ways to compensate this loss. You should know all and choose the one which does not affect the operation of your existing network deployment, In the new deployment, you must include support for mutiple-SSIDs as deployment requirements and design the network accordingly.

Supporting low link speed network (11b or mixed mode ) itself is a big challenge as legacy wireless clients do kill significant network bandwidth by transmitting data frames at lower rates.

I would be happy to learn about your experiences and share my thoughts from a wireless researcher and developer perspective.