Can you possibly defend the statement that 802.1x with PEAP or EAP-TTLS can be worse than open wireless with no authentication or encryption? Remember the old Cisco LEAP implementation that was vulnerable to offline brute-force attacks due to sending users’ MS CHAP v2 challenge/response outside of a secure connection? Joshua Wright has documented this in detail and even wrote a very popular tool, ASLEAP to exploit the issue. ASLEAP captures MS CHAP v2 challenge/response pairs and/or can be used to crack users’ passwords via dictionary attacks or even brute-force when combined with tools like John The Ripper (JTR).
A wireless network that is open with no authentication or encryption provides an attacker one thing: Network access. It’s up to the attacker to then use that network access to do what he or she wants to do. That’s bad enough but a network running LEAP without a sufficiently complex and uniformly enforced password complexity policy nets an attacker two things:
- Network access
- The exploited user(s) credentials, usually Active Directory
So enough about LEAP; the world moved past LEAP and on to other EAP variants such as PEAP, EAP-TTLS, and EAP-TLS that “protect” inner EAP authentication within SSL/TLS sessions. Yay, SSL saves the day. Sure, SSL provides encryption, but what’s encryption worth if you’re actually connected to an attacker and not your legitimate destination? That’s why SSL uses trust chains and relationships to provide . SSL supports user to server authentication with client certificates but that’s not what I’m talking about. I’m talking about server to client authentication, which is to say, “I am indeed the server you intend to connect to and here’s the certificate to prove it.”
Your machine has a certificate store with certificates from trusted certificate authorities, most public, some possibly internal or intermediate. Applications that use SSL can be configured to trust all or certain authorities in the store. Properly configured at both the client and server levels, 802.1x with PEAP or EAP-TTLS is solid. Improperly configured, 802.1x using PEAP or EAP-TTLS can give an attacker internal access to your network from outside your building along with user credentials to actually login to internal network resources.
Here’s how:
- An attacker sets up a fake (well, real to the attacker) RADIUS instance. In this case, FreeRADIUS – Wireless Pwnage Edition is used, which is totally embarrassing to say so I’ll say use FreeRADIUS WPE from now on. FreeRADIUS WPE is a patch for FreeRADIUS that configures it to automatically allow authenticators (APs) from all private address ranges, automatically accept any EAP-type, automatically accept any user credentials, and automatically log MS CHAP v2 challenges and responses.
- The attacker sets up a fake AP that supports 802.1x authentication and points it to the fake RADIUS server. The attacker can impersonate a target SSID or look for SSID probes with monitoring tools like airodump-ng, kismet, kismac, netstumbler, and etc to target suspected 802.1x SSIDs. The attacker can spoof the legitimate APs MAC address if they’d like or not.
- The attacker sets up in a location near users of the wireless network and waits for clients to authenticate to the fake AP and RADIUS server.
- The attacker obtains user names and MSCHAPv2 challenge/response pairs.
- The attacker cracks the victim users’ passwords using a variety of methods.
- The attacker now has not only internal, remote network access but likely has Active Directory credentials from some user. These may work on external websites, remote access VPNs, OWA, internal file shares, etc.
Here’s why:
- Self-signed SSL certificates that are not trusted by wireless clients are often installed on RADIUS servers in 802.1x environments. Wireless clients are then forced to trust any certificate presented to them.
- 802.1x supplicants (wireless clients) are often configured to not validate RADIUS server certificates.
- 802.1x supplicants are often configured to trust public CAs from which an attacker can obtain a fake certificate.
- 802.1x supplicants often prompt the user as to whether a RADIUS certificate is trustworthy. Leaving it up to the user is never a winning bet.
What to do?
- If you’re ok with and understanding of the overhead of managing client certificates, implement EAP-TLS as it is not vulnerable to these types of attacks.
- Install a certificate signed by an internal CA that is trusted by all wireless users on the RADIUS server.
- Avoid using RADIUS certificates signed by public CAs.
- Enforce validation of RADIUS certificates and manually select the internal CA to be trusted. Do this centrally, via tools like Active Directory Wireless Group Policies if possible. Ensure help-desk personnel and users are not capable of modifying this configuration since it has a way of becoming disabled when people are troubleshooting wireless issues.
- As always, ensure that a strong password complexity policy is uniformly applied to all users, with no exceptions.