Before we dive into the security concerns surrounding PEAP it is important to know there are currently three versions of the PEAP standard. The version I will be referencing throughout the remainder of this post will be PEAPv0. This is the most common deployment of the PEAP standard.
PEAP is a widely deployed Extensible Authentication Protocol (EAP) type used to securely authenticate users against 802.11 wireless networks. Developed by Microsoft, Cisco and RSA, PEAP has been made popular through its continued support by the Microsoft Windows platform. PEAP has the ability to support a range of inner-authentication methods, most notably Microsoft’s challenge-handshake authentication protocol known as MS-CHAPv2.
Whilst several deficiencies have been discovered over the years in the MS-CHAPv2 protocol, PEAP overcomes these by protecting the MS-CHAPv2 authentication exchange through the establishment of a transport layer security (TLS) tunnel. Through the use of digital certificates PEAP is able to authenticate users over the MS-CHAPv2 protocol in a secure manner.
The PEAP authentication process can be summarized as follows:
- Identity information is exchanged (in plain-text) between the supplicant and authenticator.
- A secure TLS tunnel is established via a server side digital certificate.
- Identity information is exchanged again within the TLS tunnel using the MS-CHAPv2 inner-authentication method.
- The pair-wise master key (PMK) is sent from the Remote Authentication Dial-in User Service (RADIUS) server to the supplicant within the encrypted tunnel.
- The PMK is sent from to the RADIUS sever to the access point (AP).
- Encryption commences between the supplicant and AP.
There are three main attacks which can be used against the PEAP protocol:
1. Authentication Attack
The PEAP authentication attack is a primitive means of gaining unauthorized access to PEAP networks. By sniffing usernames from the initial (unprotected) PEAP identity exchange an attacker can attempt to authenticate to the target network by ‘guessing’ user passwords. This attack is often ineffective as the authenticator will silently ignores bad login attempts ensuring a several second delay exists between login attempts. Whilst a lockout policy will also defend against this type of attack, failed login attempts could trigger a denial of service (DoS) attack on the network.
2. Key Distribution Attack
The key distribution attack exploits a weakness in the RADIUS protocol. Whilst this attack is not specific to PEAP deployments, it is often regarded as the weakest point in an 802.11 PEAP/WPA infrastructure.
The key distribution attack relies on an attacker capturing the PMK transmission between the RADIUS server and the AP. As the PMK is transmitted outside of the TLS tunnel, its protection is solely reliant on the RADIUS server’s HMAC-MD5 hashing algorithm. Should an attacker be able to leverage a man-in-the-middle attack between the AP and RADIUS sever, a brute-force attempt could be made to crack the RADIUS shared secret. This would ultimately provide the attacker with access to the PMK – allowing full decryption of all traffic between the AP and supplicant.
3. RADIUS Impersonation Attack
The RADIUS impersonation attack relies on users being left with the decision to trust or reject certificates from the authenticator. Attackers can exploit this deployment weakness by impersonating the target network’s AP service set identifier (SSID) and RADIUS server. Once both the RADIUS server and AP have been impersonated the attacker can issue a ‘fake’ certificate to the authenticating user. After the certificate has been accepted by the user the client will proceed to authenticate via the inner authentication mechanism. This allows the attacker to capture the MSCHAPv2 challenge/response and attempt to crack it offline.
In order to secure PEAP deployments from RADIUS impersonation and authentication attacks the following client-side configurations should be deployed:
- Ensure the common name (CN) of the RADIUS server’s certificate is defined. This setting will ensure clients only accept certificates that contain the specified CN.
- Select only the trusted certificate authority (CA) that will be issuing the certificates. This will prevent attackers from using a certificate with the required CN but signed by a different CA.
- By not prompting users to authorize new servers the decision to accept or reject certificates from unidentified RADIUS servers is taken away from the user. This setting will silently drop all requests whose certificate CN does not match that which is specified in Step 1.
- By supplying an “anonymous” identity during the initial PEAP identity exchange attackers will be unable to leverage unencrypted usernames. This setting prevents against PEAP authentication attacks. Note: This configuration setting is only available in Windows 7 and above.