It is well known now that setting up a secure wireless network can be tricky to get right. Most organizations do not do this optimally on their first attempt and set up an insecure network just to get what they need connected. Often later, lessons are learned and the older networks are decommissioned, with newer, more secure networks set up in their place. But what about all the wireless clients that previously connected to those insecure networks? Although there isn’t much in the way of new techniques needed to abuse these clients, there currently isn’t much out there research-wise about doing so.
Forgotten Clients
On a typical wireless network penetration test, we are given in-scope wireless networks across several locations. Sometimes these service set identifiers (SSIDs) are not identical to those from previous tests. Advice from previous reports has been followed, with some vulnerable SSIDs having been decommissioned. This is a positive change, as often the prior SSIDs used older EAP protocols that are vulnerable to well-known Evil-Twin attacks that make Active Directory compromise trivial. However, although decommissioned, a common case is that wireless clients are still configured to use them. By exploiting the behavior of these clients, it’s possible to obtain plaintext credentials by abusing their configurations to join the decommissioned wireless network. Because the underlying Active Directory user accounts don’t change between the decommissioned and new wireless networks, we end up getting internal network access with an AD foothold.
Detecting Client Probes
So, if that SSID had been decommissioned, how do I know that there were clients configured for a network that no longer exists? Part of the 802.11 standard for WiFi networks specifies that wireless clients may send probe requests for networks that may not be broadcasting their SSID. These probe requests can contain the SSID of the network they are looking for, which also reveals the channel they are searching on, along with the unique MAC address of the device.
Using a tool like Kismet, along with a wireless card that supports monitor mode, we can listen for these probe requests and learn about the clients in our local area:
The screenshot above shows a selection of SSIDs that have been probed for by local wireless clients but have no responding or advertising access points in range. This practice has some significant security and privacy implications, as these probes can be received by anyone. The SSIDs can be correlated with the physical locations the device has traveled and connected to, such as someone’s home Wi-Fi. There are even datasets online that can be searched to find the home SSID without needing to wardrive and find it.
Exploitation Using a Malicious Network
The bigger concern for corporate environments, however, is the potential disclosure of credentials. If a malicious actor detects a client broadcasting an out-of-range SSID, it’s possible for them to deploy a fake network and RADIUS server with the same SSID. This prompts the client to automatically connect and depending on the configuration of the original SSID, clients will send valid credentials for the original legitimate network.
Let’s take a look at an example of this attack. We’ll use a simple WPA2 PSK hotspot and one of the iPad’s we use for testing mobile applications. The SSID we will use will be “Depth Security” with a PSK of “Brown Cow”.
Even with an up-to-date version of iOS, we can see that that the default setting is to Auto-Join the known network, and there is no clear option to disable probing behavior. Next, we’ll take the hotspot offline and leave the wireless configuration on the iPad.
Then we’ll move over to the perspective of the attacker, on a nearby Kali Linux host with attached wireless card. We’ll start Kismet to get an idea of the wireless networks in the area, and then filter the results to the “Depth Security” SSID we are interested in.
As we can see, there is no available “Depth Security” SSID. However, if we go over to the SSIDs tab we can see that “Depth Security” is listed with one client probing (our iPad) and no advertising or responding routers. Notice that the encryption is listed as “Open”, typically an 802.11 probe will not include what the original authentication mechanism was for the network. As an attacker we will have to make an educated guess. The most common method of WPA2 authentication is the Pre Shared Key, and if you know nothing else about the target network that is probably a safe bet. If your target corporation is known to use EAP-PEAP MS-CHAPv2, configuring the evil-twin network to use that may be better.
Now that we are aware of the target network, we can use eaphammer to create our evil-twin network and record the handshake process.
In this example I chose to set up the network on a common 2.4GHz channel, 6, in order to maximize the compatibility of the attack, since we may not know if the original network was 5GHz or 2.4Ghz. With eaphammer, you also have to provide absolute file paths for its arguments or it may place the files relative to the script location installed on the machine.
Typically, if the attack works the client should almost immediately try to associate with our evil-twin network since there is no legitimate network in range to compete with. Although we can expect the association not to complete without knowledge of the PSK, the client still transmits the hashed passkey to our network, which is logged to our capture file.
Eaphammer will save the captured handshake traffic to a file in the now deprecated HCCAPX format, we will use some utilities from the hcxtools project to extract the PSK hash. First, we’ll need to use the “hcxhash2cap” utility to convert to the better supported pcap format.
From there we need to extract the hashes from the formatted network traffic, for this we will use “hcxpcapngtool”. Once this is complete, our hash is outputted into a file and is ready for cracking.
Finally, we will use the well-known hashcat tool to crack the extracted hash. Using this example, the hash cracks quickly, and we are presented with the plaintext credential for our target network!
At this point, the usefulness of the credential will be highly situational in a real-world scenario. If the targeted client is simply out of range of the legitimate network, then the credential can be used to access that network. If the original network was taken down, you may need to try this credential on other networks to see if it is reused or try PSKs that are related to the base phrase of your cracked password.
It is also important to note that this is primarily a client-centric attack and works with other authentication types and network configurations. If the credential is MS-CHAPv2 (EAP-PEAP) backed by Active Directory, there is a high chance that credential may be useful for other MS-CHAPv2 networks, and for getting a foothold in the Active Directory environment beyond that. GTC downgrade (EAP-GTC) is also an option here, which is even better than MS-CHAPv2 since you’ll get a cleartext username and password with no cracking needed.
Remediations
So what methods are there to mitigate or remediate this issue? The most straightforward solution is to configure wireless clients to never perform wireless probing. Unfortunately, this fix is device-specific and relies on the implementation of the wireless client’s manufacturer. Both Android and iOS can disable this behavior through the “Wi-Fi Scanning” option in their respective Location Services menu. Windows requires the “EnableActiveProbing” registry key to be disabled under “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet”.
Another solution is to explicitly remove the old wireless configuration from client devices when decommissioning an SSID. An MDM solution can make pushing these changes to the various client devices less of a hair-pulling task when there are many devices owned by an institution that must be updated.
If the SSID being decommissioned uses a PSK, be sure that the private key is not used with other services. Treat that key like it will become public knowledge. Remember that having knowledge of a previous password can reveal patterns in passwords, so keep them totally unique.
When deploying an EAP-PEAP network, be sure that the certificate is explicitly trusted by the clients. The clients should be configured only to trust the certificate of the legitimate RADIUS server and should not connect to a malicious network automatically. It’s also important that users understand that if a connecting to an EAP network asks them to trust an unknown certificate, there is likely something wrong. Alternatively, deploying an EAP-TLS network authenticates both the client to the router and the router to the client. Although more difficult to manage, EAP-TLS mitigates most of the basic attacks that can be used to exploit wireless networks entirely.
Lastly, keeping networks segmented by trust level mitigates the access of a compromised credential. If a network requires IoT devices to do a specific task, that network probably shouldn’t have access to an Active Directory environment, let alone unfettered corporate internal network access. A network like this should be configured with the minimum access necessary to do the required task.
Conclusion
Planning a secure wireless network deployment can be a daunting task. There are many things that can be misconfigured, and the nature of wireless clients means that it is hard to control everything. It’s important to sit down and think about what a network is going to be used for and to plan accordingly. Hopefully this information can help to make some of the threats that arise from client mismanagement more understandable and prompts manufacturers and network operators to create more secure networking schemes.