How secure is your WPA2-Enterprise WLAN?

If you let your client’s control their supplicant, you have NO control...

When you deploy your WLAN, with the advent of changes in standards for 802.11n/ac, you have effectively three modes you can support and still be granted WiFi Alliance certification.

• Open (No encryption)
• WPA2-PSK (Pre-shared Key encryption)
• WPA2-ENT (or WPA2-Enterprise, with RADIUS/802.1X and per-user keying based upon authentication key exchange)

When possible, it is recommended to always use WPA2-ENT on all of the devices that can support it, falling back to PSK as a last resort and utilize Open only for “guest” networks (although we’re seeing a trend to deploy PSK or other options for guest networks as well).

Once you’ve decided to leverage WPA2-ENT, you have a few choices for an inner EAP-type. Microsoft clients (as well as MAC and most Linux distributions) support PEAP/MS-CHAPv2, as well as EAP-TLS out of the box. It is estimated that 85% of deployments are EAP-PEAP/MS-CHAPv2, with the majority of the remainder EAP-TLS.  (There are other methods such as EAP-FAST and EAP-GTC, but they comprise a very small share of the real world deployments.)

So why does any customer choose to deploy EAP-PEAP/MS-CHAPv2?

Because it is the easiest to deploy and only requires the installation of a certificate on the RADIUS server.  EAP-TLS requires a certificate on the client, as well as on the RADIUS server and thus EAP-PEAP/MS-CHAPv2 is the simplest path (and if deployed properly, it is on par with EAP-TLS from a security perspective).

The big caveat in that last statement is “if deployed properly”.

In order to secure the “username/password” exchange between your AP/WLC and the RADIUS server, there is a TLS tunnel (think secured SSL/HTTPS tunnel) built between the client and authenticator to “secure” that data.  There is a checkbox in the client that effectively wipes out any security gains and today, we still find deployed networks without “server certificate validation”.

This checkbox when unchecked essentially says “exchange my credentials with any server, regardless of its name, certificate signer or any other validation”.  If this sounds like a bad, bad idea, you are correct!  Now here is why.

Any hacker can then build (for the cost of a Raspberry Pi at approximately $30) a Kali Linux server running hostapd-wpe (Wireless Pwnage Edition) and collect your credentials.  They simply masquerade their Raspberry Pi as your corporate ESSID and start gathering data from clients that do not perform certificate validation.  There is even a WRT-DD distribution that can run on Linksys Router/APs as well…

What they collect may only be MS-CHAPv2 hashes, but services like “CloudCracker” will brute force any collected password for $100 (generally in less than 24 hours).

So how do you resolve this?

1. Control your WLAN supplicants via Group Policy or an OnBoarding service that makes the profile “read-only” on configured devices.
2. Ensure those mechanisms deploy only WLAN profiles that have “Validate Server Certificate” enabled and the details on how to validate them successfully.

References:

• https://www.acrylicwifi.com/en/blog/attacks-on-wpa-enterprise-infrastructures-with-hostapd-wpe/
• http://phreaklets.blogspot.com/2013/06/cracking-wireless-networks-protected.html