PEAP (Protected EAP) is one of the most commonly used EAP methods for strong wireless 802.11 authentication in WPA/WPA2 Enterprise mode (using 802.1x/EAP), as native support is available in the Windows, Mac OS X and Linux supplicants (like xsupplicant). When PEAP is used, the user is authenticated through username and password using MSCHAPv2, and the infrastructure (specifically the RADIUS server) is authenticated through digital certificates using TLS/SSL.

Recently, multiple vulnerabilities on the digital certificate validation process associated to PEAP have been released, due to the supplicant or the deployment failing to properly validate the RADIUS server certificate:

• During the Shmoocon 2008 conference, Wright and Antoniewicz released the details about how the Windows XP, Mac OS X and other commercial supplicants are affected by the lack of certificates verification. All the details are available on their presentation.
•  Vocera's VoIP handsets do not perform certificate validation because it's too much "processing overhead required", as is clearly stated in the documentation.
• Cisco's 7921 Wi-Fi VoIP model does not validate certificates. EAP-TLS is Cisco's suggested short term workaround, what implies a full PKI.

In the first case (best scenario), by using the default PEAP settings on Windows the certificate is validated, but the matching between the name (common name or CN) of the RADIUS server and the name on the certificate are not. As a consequence, an attacker can provide its own infrastructure (access-point plus malicious RADIUS server) and present a valid certificate (signed by a trusted CA), but belonging to  the attacker's RADIUS server. The client will accept it as valid, and the attacker will get access to inner EAP authentication credentials (MSCHAPv2 challenge and response) and can perform dictionary attacks on the credentials.

Do not think just on wireless deployments! If you are using strong layer-2 authentication through 802.1x in your wired network (something I've always promoted), you may be using the same vulnerable supplicant. Since 2005 I've been teaching the renamed SANS "Wireless Security Penetration Testing" course, and during the last day we build up a complete WPA Enterprise setup in class, using a CA, RADIUS, 802.1X & PEAP, where I do not provide any DNS infrastructure on purpose to show this flaw.

For the first scenario, the workaround is to properly configure the supplicant using strict authentication settings. Be very careful on configuring the supplicants appropriately and validate the digital certificate for the server, the CA, plus the common name. For example, on Windows this means to check (see slide 37 of 42 on the presentation above):

• Validate server certificate
• Connect to these servers, and provide the hostnames for the servers
• Select the CA you used to issue the certificates for your network infrastructure
• Do not allow users to authorize new servers or CA's

For the VoIP network devices there is no easy and overall solution right now, so it is recommended to select long and complex passwords to avoid the dictionary attack to succeed.

My guess is that we're going to start seeing more and more issues like this one in other supplicants from various wireless and wired network devices, and for other EAP types that also use digital certificates, such as EAP-TTLS, and PEAP v1 and v2. Most EAP types are complex authentication protocols.

--
Raul Siles
www.raulsiles.com