blackhats.net.au

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:

1. Identity information is exchanged (in plain-text) between the supplicant and authenticator.


2. A secure TLS tunnel is established via a server side digital certificate.


3. Identity information is exchanged again within the TLS tunnel using the MS-CHAPv2 inner-authentication method.


4. 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.


5. The PMK is sent from to the RADIUS sever to the access point (AP).


6. 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:

1. 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.



2. 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.


3. 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.


4. 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.

To secure PEAP against key distribution attacks it is recommended that RADIUS shared secret is least 16 characters in length, consisting of a mixed-alphanumeric character set. The RADIUS shared secret should also be rotated on a semi-regular basis.

The Microsoft Windows platform uses a myriad of protocols to authenticate users across a network. Two such protocols widely in use today are the LANMAN challenge/response and NTLMv1 protocols. Whilst newer, more secure protocols (such as NTLMv2) are ready to take their place, LANMAN challenge/response and NTLMv1 are still widely deployed today for reasons of interoperability. As with most things Microsoft-related, ubiquity often equates to exploitability.

In this two part series I will discuss how the LANMAN challenge/response and NTLMv1 protocols operate, how malicious users can take advantage of their shortcomings, and best practice recommendations for securely deploying these protocols.

Microsoft Windows supports two primary algorithms for locally authenticating users. These algorithms generate what’s known as an “LM Hash” or an “NT Hash”.

Enabled by default in Windows NT, 2000, XP, and Server 2003, the LM Hash has become synonymous with bad hashing practices over the years. Used for backward compatibility, this older hashing method has several inherit flaws, making it trivial for attackers to crack LM Hashes within minutes.

The second, more secure, hashing algorithm generates what’s known as an NT Hash. Exclusively on by default in Windows Vista, 7, and Server 2008, this hash is generated using the MD4 hashing algorithm.
Note: By default, Windows XP stores both the LM Hash and the NT Hash.

Whilst this reading does not require a technical understanding of how the NT Hash and the LM Hash are generated, some readers may like to broaden their understanding of how these hashes are generated. The following paper provides an in depth discussion on the topic.

Before we begin looking at the Microsoft network authentication protocols, it is important to note that LANMAN challenge/response and NTLMv1 are the same protocol except for one key difference: LANMAN challenge/response utilises the locally stored “LM Hash” whilst NTLMv1 uses the locally stored “NT Hash”. Aside from this, the protocols (for all intensive purposes) operate exactly the same way.

The LANMAN challenge/response and NTLMv1 protocols authenticate users in the following manner:
1. Client sends an authentication request to the Server.
2. A protocol negotiation occurs between the Client and Server.
3. The Server sends the Client a (pseudo-random) 8-byte challenge.
4. The Client sends a 24-byte response.
5. The Server authenticates the Client.

The Client’s response is made up of the following steps:

1. Split the locally stored 16-byte hash (LM Hash for LANMAN challenge/response or NT Hash for NTLMv1) into three 7-byte portions.
2. Using the DES encryption algorithm, encrypt the Server’s challenge three separate times using each of the keys derived in Step 1.
3. Concatenate the response of all three outputs.

Now, at first glance this protocol seems fairly sensible. But you may have noticed something in Step 1 of the Client’s response. If the hash (LM or NT) is 16-bytes long, how do we break it up into three 7-byte portions? i.e. 7 does not divide into 16 evenly.

To combat this unevenness, the LANMAN and NTLMv1 algorithms pad the third key with 5 nulls. By doing this, we now have three evenly portioned keys.

So, the response process in its entirety looks something like this:
Now that we have an understanding of how the LANMAN challenge/response and NTLMv1 protocols work, let’s take a look at some of the deficiencies these protocols inherit.

1. There is no “diffusion” within the protocol. That is, there are three separate parts to the response that could individually be attacked. Diffusion would ensure each part of the DES output relied on the previous – increasing the overall complexity.
2. DES is old and considered cryptographically weak by many.
3. The third DES key is weak. As the third DES key is padded with 5 nulls, there are only 2^16 possible unknown values. This would take a modern computer seconds to crack.
4. There is a lack of randomness. The only randomness occurring within the algorithm is that provided by the pseudo-random challenge generated by the server.

In Part 2 of this series I will demonstrate how attackers can take advantage of the aforementioned deficiencies in the LANMAN challenge/response and NTLMv1 protocols.