Analyzing Wireless Network Security at the Packet Level

The tricky thing about a wireless network is that you can't always see what you are dealing with. In a wireless network, establishing connectivity isn't as simple as plugging in a cable, physical security isn’t nearly as easy as just keeping unauthorized individuals out of a facility, and troubleshooting even trivial issues can sometimes result in a few expletives being thrown in the general direction of an access point. That being said, securing wireless networks will continue to be a challenge for the foreseeable future.

In this article I am going to discuss useful techniques for troubleshooting wireless security issues at the packet level. I will start by demonstrating methods for actually collecting wireless network packets properly. Once the right data is being collected I will discuss different analysis techniques including analyzing WEP/WPA authentication, filtering for encrypted traffic, and finding rogue access points.

Capturing Wireless Packets

At the packet level wireless networks are similar to wired networks in most ways. Wireless networks still use TCP/IP for data communication and abide by all of the same laws of networking as wired hosts. The major difference between the two networking platforms is found at the lower layers of the OSI model. Wireless networks communicate by sending data over the air as opposed to sending data across a wire. The air that wireless data is communicated on is a shared medium, and because of that special consideration must be given at the physical and data link layers to ensure that there are no data collisions and that data can be delivered reliably. These services are provided by different mechanisms of the 802.11 standard.

This is relevant to the troubleshooting of a wireless network because some additional effort has to be put forth to capture the layer two 802.11 information which is required for adequate troubleshooting. In order to do this you must be able to put your wireless network interface card (WNIC) into a special mode called Monitor Mode. Monitor mode is a special driver setting which limits a WNICs ability to send data and makes it so that the WNIC only listens passively on the selected channel.

In Linux based operating systems it is fairly easy to change a WNIC into monitor mode but most Windows drivers don’t allow for this functionality. As a result, a special piece of hardware is required to make this work. This piece of hardware is called AirPcap and is made by CACE Technologies. The AirPcap device is a basically a WNIC designed to be used in monitor mode with Windows and the Wireshark packet capture utility. Using this device you can capture the layer two 802.11 information from the wireless channel you are listening on.

Figure 1: The AirPcap configuration screen allows you to configure the channel you are listening on

The 802.11 Packet Structure

The primary difference between wireless and wired packets is the addition of the 802.11 header. This is a layer two header that contains extra information about the packet and the medium it is transmitted on. There are three types of 802.11 packets; data, management, and control.

Management - These packets are used to establish connectivity between hosts at layer two. Some important subtypes of management packets include authentication, association, and beacon packets.

Control - Control packets allow for delivery of management and data packets and are concerned with congestion management. Common subtypes include Request-to-Send and Clear-to-Send packets.

Data - These packets contain actual data and are the only packet type that can be forwarded from the wireless network to the wired network.

It’s beyond the scope of this article to discuss every 802.11 packet subtype so we will focus on a few fields that are interesting from a security perspective.

Finding Rogue Access Points

Physical security of IT assets is the most often overlooked security domain. One of the most common oversights in this domain is the addition of unauthorized devices onto the network. In the wired world an unauthorized router can cause a denial of service just by plugging it in right out of the box. Although that certainly has serious consequences, a rogue wireless access point (WAP) provides an even bigger concern because it may allow somebody from outside the facility to gain access to the network just as though they walked in and plugged in a laptop to a wall jack.

Fortunately, detecting a rogue WAP can be done in a fairly straightforward manner. In order to do this you must first start by capturing wireless traffic from several areas within your networks broadcast range. Once this is done there are several different filters that can be used to determine if rogue access points exist and if clients are associating with them.

One of the easiest methods for doing this is to know the MAC address of the known legitimate WAP. Using this information, you can input the filter !wlan.bssid == 00:11:88:6b:68:30, substituting your WAP MAC into the place of the sample MAC I provided. This will show you all wireless traffic that is going to or from a WAP other than the one specified. If you have more than one WAP in the area you can combine these filters with the OR (||) operator. In that case, you could use something like !wlan.bssid == 00:11:88:6b:68:30 || !wlan.bssid == 00:11:ff:a1:a4:22 to filter out two known legitimate access points.

That method should work for finding access points in general, but what if you wanted to go one step farther and find out if your mobile workstations are actually connecting to the rogue WAP? One way to do that would be to filter for association requests. In order to do that you can combine one of the previous filters with the filters wlac.fc.type_subtype eq 0 and wlac.fc.type_subtype eq 2. The first filter will show all association requests and the second will show re-association requests. When necessary you can combine either one of these filters with the previous filters by using the AND (&&) operator.

Lastly, you can go one step further by determining if there is any actually data being transferred between mobile clients and a rogue WAP. You can do this by filtering on all data packets that are being communicated with a non legitimate access point by using the filter wlan.fc.type eq 2 in conjunction with the filters shown earlier that exclude known legitimate WAPs.

Filtering for Unencrypted Traffic

The only real hope you have in defending packets from eavesdroppers as they fly through the air is to employ some type of encryption. This is typically done through implementation of WPA or WPA2 in modern systems. That being said, it’s good security practice to audit your wireless networks every so often and ensure that there are no wireless clients transmitting data in an unencrypted method. This can happen easier than you think as a WAP could be misconfigured, a rogue WAP could be present, or two wireless clients could be communicating directly in ad-hoc mode.

Finding unencrypted data on the wireless network is a matter of using another filter. In this case we can find all packets with unencrypted data by using the wlan.fc.protected == 0 filter. Now, if you use this right now you will find that it returns some unexpected results. 802.11 control and management frames are not encrypted because only perform administrative functions for WAPs and wireless clients. That being the case we must extend this filter by appending wlan.fc.type eq 2. This will ensure that the filter only displays data packets that are unencrypted. The final filter would be wlan.fc.protected == 0 && wlan.fc.type eq 2.

Analyzing WEP and WPA Authentication

The original preferred method for securing data transmitted over wireless networks was Wired Equivalent Privacy (WEP). WEP was mildly successful for years until several weaknesses were uncovered in its encryption key management. As a result of this, new standards were created which include the Wi-Fi Protected Access (WPA) and WPA2 standards. Although WPA and its more secure revision WPA2 are still fallible they are considered more secure than WEP.

It’s quite useful to be able to differentiate WEP and WPA authentication on the wire. If you are able to do this you will be able to spot a WEP authentication on a network that should be WPA only. Along with that, you should be able to analyze failed authentication attempts when they are present.

WEP Authentication

WEP authentication works by using a challenge/response mechanism. When the client attempts to connect to the WAP, the WAP issues challenge text. This challenge is acknowledged and then the client takes the text, decrypts it with the WEP key provided by the client, and transmits the resultant string back to the WAP.

Once the WAP verifies that the response text is what it should be, it transmits a message back to the client to notify it that the authentication process was successful. The filter to find successful authentication responses is wlan_mgt.fixed.status_code == 0x0000.

Figure 2: The WAP alerts the client that authentication was a success

In the case that the authentication is not a success, the WAP would transmit a message stating that it “Received an authentication frame with authentication sequence transaction sequence number out of expected sequence”.

Figure 3: The WAP alerts the client that authentication failed

The filter to find packet with this failure notification is wlan_mgt.fixed.status_code == 0x000e.

WPA Authentication

WPA authentication also uses a challenge/response mechanism, but it works in a much different fashion. At the packet level, WPA authentication uses EAPOL to perform its challenge/response. You can find these packets by using the simple filter EAPOL. In a successful authentication you should typically see four EAPOL packets representing two challenges and responses, consisting of four total packets. Each challenge and response can be paired together using the Replay Counter value within the packet.

Figure 4: The Replay Counter field is used to pair challenges and responses

In a situation where WPA authentication fails you will more EAPOL packets where the challenge/response is attempted several more times. Once this process eventually dose fail you should see a de-authentication packet.

Figure 5: After failing the WPA handshake, the client deauthenticates

There are two ways to filter failed WPA authentication. The first is to use the EAPOL filter and to count the number of packets transmitted between the WAP and wireless client. Another way is to filter for deauthentication packets using the filter wlan.fc.type_subtype == 0x0c. This will return quite a few additional results not related to failed authentication so in order to verify that the packets are related to this you will have to dig a bit deeper and create another filter encompassing all of the packets between the WAP and wireless client in question.