Attacking and Securing PEAP
Protected Extensible Authentication Protocol (PEAP) is often regarded as a secure 802.11 wireless authentication protocol. Whilst PEAP has the ability to become a secure protocol it is certainly not without its deficiencies. I thought I would take this opportunity to provide everyone with an overview of the PEAP protocol by examining what it is, how it works, where its shortcomings lie, and how to secure it.
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:
Attacking PEAP
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.
Securing PEAP
In order to secure PEAP deployments from RADIUS impersonation and authentication attacks the following client-side configurations should be deployed:
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.
Attacking PEAP
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.
Securing PEAP
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.
have heard a lot about PEAP but here i get accomplishing idea on it, thanks to the reader. I read the post thoroughly and gather some useful knowledge on the authentication protocol for the wireless system. Need some more cool stuffs on it.
ReplyDeleteThis comment has been removed by the author.
ReplyDeletePatrick,
ReplyDeleteI can't make up my mind. Which RFC should I be reading to be sure about this? Just taking the simple interpretation of the steps you've listed above, would suggest that the TLS Tunnel exists, BEFORE the PMK is sent. (Vivek Ramachandran has demo'd capturing the PMK in EAP-MD5, however, I am skeptical that it's available outside the TLS tunnel in PEAP. Have you read these....
http://rfc-ref.org/RFC-TEXTS/3579/chapter4.html
I fear I'm getting confused the more I read the RFC. Ugh. Thanks for any help you can provide here.
~Paul
"PEAP can only authenticate clients using Microsoft’s challenge-handshake authentication protocol known as MS-CHAPv2."
ReplyDeleteThis has never been true. PEAP can use whatever method is on the system as long as it is properly designed. By default, PEAP supports MS-CHAPv2 and EAP-TLS as inner methods on a Windows system.
I re-read the RFC and you are correct. I've never seen it used with anything other than MSCHAP. Thanks for pointing this out :)
Delete