McAfee researchers show that a common setting for the WPA Enterprise supplicant in Windows leads to credential ownership: I was aware of this problem when WPA Enterprise first started to become available, because some early gateways equipped to handle the port-based authentication protocol (802.1X + WPA, essentially) lacked certificate-authority (CA) signed certificates. What this means is that the operating system and supplicant, which have the root certificates installed to validate the CAs, which in turn validate certificates signed by the CAs, can't provide the out-of-band confirmation that a certificate presented by the authenticator to create a tunneled PEAP or EAP-TTLS session is valid. Got that?
Today, it's likely that you either have a CA-signed certificate, your IT department has preinstalled the root certificate needed on your machine, or you're using an outsourced provider (like WiTopia) which includes root certificates to install on your systems. I say likely, but Brad Antoniewicz and Josh Wright apparently have found that it's not entirely common.
The weakness they document is based on a setting in Windows supplicant for PEAP: Validate Server Certificate. When unchecked--its default state is checked--the authentication is bypassed. The researchers note that there are similar settings in other supplicants, covering both PEAP and EAP-TTLS.
With validation bypassed, an AP can spoof the protected network (becoming the authenticator in 802.1x parlance) and the researchers' modified FreeRADIUS server software (FreeRADIUS-WPE) can handle the authentication server component. The client doesn't notice, or a user isn't prompted to confirm or simply clicks through when prompted to trust a certificate that's unsigned. The credentials are then sent in the clear using EAP, which has no integral encryption, within the forged tunnel.
Easy solutions noted above: Only trust validated certificates; configure supplicants to require validation; install root certificates as needed when using self-signed certificates or those issued by firms outside of your operating system's chain of trust.
I came here to suggest a correction to your original version of this which stated, "The weakness they document is based on a setting in Windows supplicant for PEAP: Validate Server Certificate. When checked, the authentication is bypassed..." I see that you corrected it in the version above with, "When unchecked?its default state is checked?the authentication is bypassed." Good catch.
This setting is a valid concern that should be addressed by IT departments who roll out these EAP types. It is usually unchecked to make it easier for the user to gain wireless network access the first time. The problem is, it never gets reset to a "checked" state and that's what leaves the vulnerability. The fix is fairly easy and is resolved by having the user login to the network the very first time from a wired connection. This provides a way to provision the client with the certificate so subsequent logins are properly validated and successful.
Joel