These days, wired and wireless (Wi-Fi) networks are ubiquitous. Organizations need these connections to perform critical business functions, but these connections are susceptible to various ever-evolving cyber threats. As a result, many different ways of protecting networks exist, including using authentication protocols such as PEAP-MSCHAPv2, EAP-TTLS/PAP, or EAP-TLS.
PEAP-MSCHAPv2 (a combination of the Protected Extensible Authentication Protocol and the Microsoft Challenge Handshake Authentication Protocol Version 2) remains a standard method of securing networks. However, PEAP security becomes increasingly unreliable by the year. In this analysis, we’ll explore PEAP-MSCHAPv2, its workings, and the most modern threats to this authentication protocol.
What is PEAP-MSCHAPv2 and How Does it Work?
Extensible Authentication Protocol and its Variations
To understand the Protected Extensible Authentication Protocol (PEAP), you first need to understand the Extensible Authentication Protocol. EAP authentication uses a transport layer security (TLS) tunnel protected by encryption that links clients to servers. There are numerous variations of EAP, but the types we see most often are PEAP-MSCHAPv2, EAP-TTLS/PAP, and EAP-TLS.
Except for EAP-TLS, all the most common EAP methods we listed above rely on passwords for authentication.
How Protected Extensible Authentication Protocol (PEAP) Works
PEAP-MSCHAPv2 is a network security protocol that combines the PEAP-TLS protocol and Microsoft Challenge Handshake Authentication Protocol Version 2. It aims to secure user authentication by encrypting the credentials sent within the PEAP tunnel, where it performs the “handshake” with the corresponding RADIUS server to begin the actual authentication process.
Authentication begins when a client connects to the network via username and credentials. It follows these steps:
- The PEAP protocol creates an encrypted tunnel, and MSCHAPv2 verifies the user’s password through a challenge handshake response mechanism.
- Working at the Transport Layer, MSCHAPv2 concurrently authenticates both the client and server certificate while keeping the user’s password “blank” to maintain security. The server certificate validation confirms that the user connects to the correct server.
- MSCHAPv2 presents a challenge-response that the user must complete for the server. After the server verifies the user’s response, it grants the user access to the network.
This authentication process has been highly secure for the most part, which is why so many organizations have implemented it. Unfortunately, this authentication method has a growing number of software issues and other vulnerabilities.
Vulnerabilities that Impact PEAP-MSCHAPv2 in 2024 & Beyond
Windows Credential Guard Issues with PEAP-MSCHAPv2
Recently, it was discovered that PEAP-MSCHAPv2 and Windows Credential Guard can cause security and organizational productivity issues. Users still face authentication vulnerabilities despite the tunnel encryption and challenge-response security implementations.
SecureW2 investigated the issue to determine whether using PEAP-MSCHAPv2 and Windows Credential Guard was a true error in a sandbox environment. The main issue is that Windows Credential Guard doesn’t allow users to save PEAP credentials, so end-users must manually enter their credentials for each authentication. Each time you send credentials over the air in this way, you expose them to various attack scenarios.
One example of a scenario that could exploit this vulnerability is an Evil Twin AP attack. In this scenario, attackers can imitate a trusted access point from their device and position themselves near a public place where people might connect to the false SSID, such as a college campus. A student whose device has not been appropriately configured for the school’s legitimate SSID will connect automatically to the nearby imitation SSID and attempt to auto-authenticate with the attacker’s spoofed network. In doing so, it sends encrypted packets containing the user’s password to the attacker’s computer.
Because of a weakness in the MD4 hashing algorithm used by PEAP-MSCHAPv2, the attacker can easily decrypt the packets containing the user’s login credentials. Since many people reuse passwords across multiple accounts, the hacker has likely gained access to more than just the fictional student’s school Wi-Fi credentials.
Wi-Fi Authentication Bypass Vulnerability for Android & ChromeOS Devices
The National Institute of Standards and Technology (NIST) recently discovered a new vulnerability affecting networks that use PEAP-MSCHAPv2. The vulnerability can lead to authentication bypass attacks on WPA2 and WPA3 networks in Enterprise mode with a misconfigured server certificate. It impacts explicitly the following types of devices and systems:
- Intel’s iNet Wireless Daemon (IWD)
- WPA_supplicants on ChromeOS devices
- WPA_supplicants on Android devices
- Linux distributions using a default Wi-Fi client
For Android devices, 802.1X configuration can be a bit more time-consuming because users must manually configure network settings to trust server certificates. There are currently no alternative methods of configuration, and Android users may need to wait a while before a security patch is available to address the issue with wpa_supplicants.
Linux devices that carry older versions of IWD put their home network at risk, while wpa_supplicants put enterprise networks at risk. Because this article focuses more on enterprise networks, we’ll limit our discussion to how home networks are impacted and discuss the threat to enterprise networks in more detail.
The hacker will use the Evil Twin strategy we discussed to carry out the authentication bypass attacks. This is done by tricking the victim into connecting their device to a spoofed network that resembles the name of a legitimate network. From then on, they can see what credentials were used to login to that spoofed network and begin infiltrating it. When exploiting wpa_supplicant vulnerabilities, the attacker will have limited access depending upon the user credentials they have stolen and will look to start privilege escalation to attain their goal.
For wpa_supplicants implementing PEAP to be compromised, the device must be configured not to require verification of the authentication server’s TLS certificate. During the PEAP handshake, the supplicant will connect to the spoof network because it is not correctly configured to validate the server certificate’s authenticity.
Protecting Your Organization’s Network from PEAP-MSCHAPv2 Vulnerabilities
Enforce Server Certificate Validation on Every Device
By checking the authentication server’s certificate, server certificate validation is verifying you are connecting to the correct network. This prevents Evil Twin AP attacks from occurring and provides enhanced security.
Unfortunately, setting up server certificate validation is device-specific and difficult for many users to configure independently. Relying on end-users to manually configure their devices poses a security risk because users tend to miss steps and accidentally trust rogue networks.
Using auto-configuration technology such as JoinNow MultiOS to automate the process saves time for your administrators and saves you end-users the headache of configuration for their BYODs. JoinNow correctly configures the device to check for specified certificates to verify that the device is connected to the trusted network.
Consider Using More Secure Authentication Protocols Like EAP-TLS
EAP-TLS is a certificate-based authentication protocol that does not require a password to authenticate securely to the network. Instead, digital certificates are used by both clients and authentication servers.
Because it’s passwordless, EAP-TLS is inherently more secure than password-based authentication. Once configured, it’s also easier for the end user because they no longer need to type in passwords repeatedly, deal with disconnects when their passwords expire, or develop complex new passwords. This allows the organization to increase productivity and grants protection from network-based attacks because only devices enrolled with a certificate can access the network and domain’s resources.
The main challenge to implementing EAP-TLS is establishing the Public Key Infrastructure (PKI) necessary to manage the certificate lifecycle. Thankfully, more solutions, such as managed PKIs, are available today to make certificates accessible.
Make the Switch from PEAP Security to EAP-TLS with SecureW2
With increasingly complex attack vectors becoming available almost daily, credential-based authentication unnecessarily leaves your organization vulnerable. Switching from credential-based authentication to certificate-driven EAP-TLS doesn’t need to be challenging, either.
SecureW2’s passwordless platform gives you all the tools to implement certificates. We have a managed cloud PKI that can be deployed rapidly and onboarding technology to roll out certificates to your endpoints. Our advanced gateway APIs can automatically enroll managed devices for certificates, while our self-service JoinNow MultiOS application can empower end-users to configure their unmanaged devices quickly.
Reach out to us today for a free demo and see for yourself how our solution works.
