If you’ve never used Wireshark with promiscuous mode enabled, I highly recommend it – if you’re into geeky things that is. I know I am! This should go without saying, be responsible in what you do. Promiscuous mode allows a capable wireless network interface card (WNIC) to listen to all wireless traffic, regardless if the traffic is destined for your client machine or not. Otherwise, other modes generally only allow your machine to interpret traffic destined for it.
This post is based on a testing environment where I own all involved devices. My lab consists of a wireless access point (AP), a wireless client that is used to connect to the AP, and a third wireless-capable device listening in promiscuous mode – this third device is using Wireshark. Despite this, I will still mask involved MAC addresses from included images. The main scope of this post is to help you become more familiar with the WPA2 protocol and to recognize its threat landscape.
That said, this blog covers WPA2 Wi-Fi connections and some involved intricacies; 802.11 frame type subtypes (Beacon frames and Probe Requests and Responses) and the IEEE 802.1X authentication process (EAPOL, messages 1 – 4). This is by no means a full in-depth review of all of the different 802.11 frame type packets floating around unbeknownst to us. If you choose to test this yourself you will see why! Or you can simply check out the 802.11 frame type Wikipedia page. Let’s get to it!
Typical WPA2 / Wi-Fi Connection Process
When you enable Wi-Fi services on a respective device, typically a list of nearby APs is presented. You then select your desired SSID and if applicable (hopefully it is!) then enter the appropriate password to connect to that SSID. To be specific here, this process is geared towards the WPA2-PSK mechanism where pre-shared keys (PSKs) are used, WPA2-Enterprise uses a different mechanism and is more secure in its implementation. This is a great read expounding on differences between WPA2-PSK and WPA2-Enterprise.
Throughout this entire process, end users have already experienced the Beacon frame, Probe steps, and the EAPOL steps if and when the password requirements are met. I’ll expand on what these are in the next section. All these steps were completed in the time it took for a wireless client to scan the vicinity’s wireless electromagnetic spectrum, see their desired SSID, and enter the known password to authenticate to that SSID.
A slight deviation from this topic.
In order for the listed SSIDs to appear, the AP service provider must ensure “enable broadcast SSID” is checked. Otherwise, the SSID may not be made visible, at least not in the context of the above paragraphs. There is an option to not advertise a specific SSID, but this doesn’t prevent someone from manually sniffing all wireless packets (this is where promiscuous mode comes into play). This is known to some as “security by obscurity,” which alludes to a sense of security while not really offering any sort of security at all. To be clear, just because you opt to not advertise your SSID doesn’t mean there aren’t alternate means of obtaining this information.
Should one choose to not advertise their SSID, others can still connect to it as long as the SSID is known and they have the required password. In fact, in my testing, if I explicitly choose to make my device visible, I see Beacon frames containing my set SSID (Figure 1), otherwise I get an SSID of “Wildcard (Broadcast)” (Figure 2).
Ending this brief detour, even if an SSID is not made visible, if there is a client in the vicinity that connects to it, the SSID will be revealed. The next section covers this in a bit more detail.
Where Each Frame Applies
This section covers each of the frames I am going to talk about: Beacon frames, Probe Requests and Probe Responses, followed by the four-message EAPOL handshake.
Beacon frame
Above I used the term Beacon frame and the associated images display the same term. Just what is a Beacon frame? A Beacon frame contains all the network information pertaining to a specific SSID. Within Wireshark’s display, there are five main sections, and each have quite a bit of info.
The SSID is under the fifth section: IEEE 802.11 wireless LAN. Figure 4 shows the subsection with an SSID made visible; Figure 5 shows the subsection with an SSID not made visible.
Extending the previous section’s detour, if the SSID is not made visible, the IEEE 802.11 Beacon frame section lists the Transmitter address, Source address, and BSS Id address as that of the service provider. Note that all three are the same addresses but have been masked out.
To test this, I had Wireshark open with specific filter commands listening to the MACs of my wireless client and the AP. There were a few filters available, two are “wlan.sa == {MAC:ADDRESS} || wlan.sa == {MAC:ADDRESS}” and the other “wlan.bssid == {MAC:ADDRESS} || wlan.sa == {MAC:ADDRESS}”.
Once I turned on a hidden SSID, it started sending Beacon frames and Probe Requests to the Broadcast address with the SSID parameter set to “Wildcard SSID”. Then I enabled Wi-Fi on my client, the SSID was indeed not listed in the available SSIDs. However, when I clicked on “Join Network,” I was prompted for the SSID (go figure!) and this Probe Request was sent to the Broadcast domain with the source’s MAC address. Sure enough, the AP responded directly to the client via Probe Response.
As you can see, a client connecting to a hidden SSID will indeed reveal a hidden SSID! If you’re feeling geeky enough, do this yourself in your own lab and look through each of the five sections. There are a lot of details being passed around in addition to the SSID. You can see which supported data rates are available, the Channel being used, vendor information, and a lot of other data that may make your head scramble.
Probe Requests and Probe Responses
These two counterparts go hand in hand, if the naming wasn’t obvious enough. Probe Requests infer that something is desiring information, in this case our WNIC is interested in what frequencies are available in the vicinity. On the opposite side is Probe Responses, a reply to the Probe Request with the requested information pertaining to a network.
Here we can see the benefits of using the Broadcast address. Our request in Figure 8 is sent from my test wireless client seeking all available SSIDs in the area. Beacon frames are sent to this same MAC as well (ff:ff:ff:ff:ff:ff), this address is reserved for such use cases. Having done this, all listening service providers will pull the Requestor’s MAC address from within the packet and directly respond to that client as seen in Figure 9. Included in the response is the SSID of the respective network as well.
The contrast between these two sets of frames and of the Beacon frame isn’t terribly different. A Probe Response is more or less the same thing, in terms of the information included, as what is contained within a Beacon frame. Think of Probe Requests and Responses as direct correspondence between clients, a Beacon frame can be thought of as a general advertisement of service.
EAPOL Messages 1 through 4
Okay, so now we know how our wireless clients can scan, rather Probe, the invisible electromagnetic spectrum and how details are communicated by service providers. In my lab I have an SSID that I want to connect to, and it’s protected with WPA2, to which I know the appropriate password. The entirety of EAPOL exchanged messages is seen in Figure 10.
Each Message contains six sections as seen within Wireshark depicted in Figure 10. You can see that the first three sections resonate with either Probe mechanism or Beacon frames.
The exchanges of each of the four messages eventually leads up to authorizing a wireless client to connect with a respective AP offering wireless services. After this is completed, wireless clients are connected to the SSID and are allowed Internet access or access to do what needs to be done.
Conclusion
In summary, Probe Requests are wireless clients requesting network information associated with a wireless service provider or what’s available in the Broadcast domain. A Probe Response is the returned message from a specific wireless provider with the requested data about their network. The two of these work together to populate available nearby SSIDs. These two and the Beacon frame are somewhat the same but with minor differences. The main difference I see is that Beacon frames are continually broadcasted to all, Probes are more specific communication exchanges.
The goal of this post is to make you, the reader, more aware of the frequencies around us pertinent to the WPA2 connection process. There is a lot of information floating around and it’s all “visible” – you just have to know how to search for it and this blog aims at showing you how to do it. This post will also serve as the basis of how to crack WPA2-PSK passphrases, a future post on that to come!
Also, it’s worth repeating one more time. The information discussed here is for educational purposes. I, nor WatchGuard Technologies, condone illegal activities or illegal behavior. The target audience is for those seeking to learn how to conduct penetration testing or similar on their own network or on a network that they have explicit permission to conduct such testing upon.