Monday, May 17, 2010

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:

  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.

Tuesday, May 4, 2010

Password Wordlists and Dictionaries

Password wordlists and dictionaries are an often imperative resource for any password auditing exercise. I thought I would take this opportunity to consolidate a list of wordlists/dictionaries for ease of access. Please feel free to post any resources I have omitted in the comments below.

I will periodically update this post with any new resources I come across.

Sunday, March 14, 2010

RSA Encryption Broken

A recent Engadget article made popular through and has (incorrectly) claimed that 1024-bit RSA encryption has been cracked and is no longer secure. I would like to reassure everyone that the RSA algorithm is indeed cryptographically secure, with the Engadget article nothing more than poorly researched journalism.

The research in question, titled Fault-Based Attack of RSA Authentication, actually describes how a private key can be recovered by injecting power faults into a system by manipulating a computer's voltage supply. Vulnerabilities found within both the OpenSSL implementation of RSA and circuit-level vulnerabilities in digital hardware devices have made the attack possible.

Attacks on the hardware and software surrounding private keys are nothing new, however. In 2008, researchers at Princeton University released a paper on the preservation and extraction of encryption keys from random access memory (RAM) through the use of a freezing process. Their research can be seen here.

Whilst interesting, the newly described research is far from world-ending. In order for this attack to be successfuly implemented, both physical access to the target machine and access to a large cluster of machines is required -- leaving this form of an attack with a very limited scope.

The Engadget author foolishly concludes his article by hoping "...RSA [will] hopefully fix the flaw".

Saturday, February 27, 2010

Is WPA Secure? - Part 1

Recently I have noticed quite a bit of conjecture surrounding the Wi-Fi Protected Access (WPA) protocol and its use. With media hysteria now promoting WPA as no longer secure, wireless security has, unfortunately, become another great unknown to many people.

In this three-part series I would like to delve into the WPA protocol and provide a background on its history, how it works and assess whether WPA is indeed insecure. By the end of this series I will have provided a foundation which will hopefully help answer two of the most common questions surrounding the wireless-security space: “Is WPA secure?” and “Should I be using WPA?”.

To be comfortable in understanding the insecurities of the WPA protocol, Part 1 of this series will provide a brief background on 802.11 security.

Designed as a basic security measure to secure 802.11 wireless networks, Wired Equivalent Privacy (WEP) was implemented to provide simple confidentiality to wireless networks. Soon after its inception, weaknesses were being discovered in the WEP protocol. Among these weaknesses were:

  • key selection weaknesses,
  • no replay protection,
  • weak message integrity checking,
  • no key rotation mechanism,
  • short initialization vector (IV),
  • pseudo-random generation algorithm (PRGA) revealed in challenge/response, and
  • key was reversible from cipher-text.

By 2007, attacking WEP had become so effective that the cracking probability of a 104-bit WEP key was:

    • 50% success after 60 seconds
    • 80% success after 90 seconds
    • 95% success after 128 seconds

Source: Tews, E, Weinmann, R, Pyshkin A 2007, Breaking 104 bit WEP in less than 60 seconds

To combat the deficiencies of the WEP protocol, the Institute of Electrical and Electronics Engineers (IEEE) decided to come up with a new, more secure protocol: WPA. Designed specifically to work within the design constraints of existing WEP hardware, WPA could be adopted with a firmware upgrade to existing WEP-enabled infrastructure.

WPA was able to improve security over its WEP counterpart by implementing the Temporal Key Integrity Protocol (TKIP). Based on the RC4 cryptographic cipher (like WEP), The TKIP algorithm was designed to overcome the security deficiencies discovered in WEP by:

  • defeating key reuse attacks,
  • defeating forgery attempts, and
  • defeating replay attacks.

Whilst these mechanisms would provide consumers with a secure alternative to the broken WEP protocol, the IEEE only intended WPA to have a 5-year life span (1999-2004). This life span would provide organisations with a transitional period for the arrival of WPA's new companion, WPA2.

Requiring a hardware upgrade from old WEP/WPA technologies, WPA2 was based on the 802.11i security specification (which was not yet ratified at the time WPA was introduced). Designed on a completely new encryption protocol, WPA2 implemented a new algorithm known as Counter Mode with Cipher Block Chaining Message Authentication Protocol (CCMP). CCMP offered several enhancements to the TKIP standard, including the use of the AES cryptographic cipher (as opposed to RC4 used in WEP/WPA). WPA2 was also given the ability to utilise the TKIP encryption protocol for backward compatibility.

Note: Vendors will often (incorrectly) refer to WPA2 as WPA2-AES. This would be fine if WPA was referred to as WPA-RC4. For the sake of consistency, I will refer to WPA2 as WPA2-CCMP throughout the remainder of this series.

Apart from brute-force attempts on weak passwords, both WPA-TKIP and WPA2-CCMP have been considered ‘secure’ up until recently. In November 2008 Erik Tews and Martin Beck, researchers at two German University, published a paper that highlighted a weakness in the TKIP algorithm. Their paper demonstrated how plain-text could be recovered from an encrypted WPA network and injected back into that network. Tews and Beck’s attack method was later enhanced by two Japanese researches whose research caused wide-spread panic among information technology (IT) journalists.

In Part 2 of this series we will take a deeper look at how the TKIP protocol works, how TKIP can be attacked, and look at answering the two pertinent questions: “Is WPA secure?” and “Should I be using WPA?”.