WPA2-PSK vs WPA2-Enterprise: hacking and hardening

This post has the aim to summarise the security aspects of WPA2, with a focus on WPA2-Enterprise hacking. At the end, EAP-TLS is presented as a pretty secure implementation.

WPA2 in brief

The Wi-Fi Protected Access is a wireless technology designed to secure the communiciations between stations and the Access Point from eavesdropping and tampering attacks. It is defined in 802.11i standard and has been adopted in home, small business (WPA2-Personal) and enterprises (WPA2-Enterprise) since 2004. 

The WPA2 implementation is based on the 4-way handshake.

The PMK (pairwise master key) is the value that both station and AP know and from which the PTK (pairwise transient key) is calculated and valid for the session. The station MAC, the AP MAC and two nonces (A-Nonce, S-Nonce) that are exchanged during the 4-way handshake are also part of the PTK generation process.

From an offensive point of view, capturing the messages of the 4-way handshake that are transmitted in clear is crucial to crack the passphrase of the ESSID (in case of WPA2-PSK) or of a single user (in case of most WPA2-EAP types).

WPA2-PSK (Personal)

In WPA2-PSK, all station shares the same passphrase and therefore the PMK, which is calculated from the password and the ESSID name, is the same among all stations.

Weaknesses of WPA2-Personal

The major security issue of WPA2-PSK is the compromise of the shared passphrase. If its value is leaked accidentally (or intentionally), the network is at risk because an attacker could both authenticate to the network and perform targeted attacks against the devices connected or can just capture the encrypted traffic of other users and then decrypting it with the PMK he knows. 

Note that in the latter scenario, for succesfully decrypting the data exchanged over WPA2-PSK, the attacker needs, of course, the value that are part of the PTK generation (MACs, nonces) but to retrieve them he has only to sniff a 4-way handshake (indeed, just 2th and 3rd packet or 3rd and 4th).

If an attacker does not know the passphrase, he can retrieve it by sniffing a 4-way handshake of a station connecting to the target ESSID and then performing a brute-force/dictionary attack.

Lastly, another common threat to WPA2-PSK is the insecure presence of WPS (Wi-Fi Protected Setup) enabled on some routers. WPS feature is considered very bad for security concerns because a bruteforce on the 8 PIN value allows to retrieve the cleartext value of the passphrase in few hours.

WPA2-EAP (Enterprise)

WPA2-Enterprise reduces the attack surface by adopting multiple implementations that have in common the uniquess of PMK (derived from password, security certificates, smartcards, OTP tokens) for each station client. The Access Points verify users identity through a RADIUS server, which has the duty to supervise the AAA process for all clients that want to connect to the network. The RADIUS server is usually combined with Active Directory or LDAP to monitor domain accounts activity, password complexity and expiry. 

Weaknesses of WPA2-Enterprise

The practical attacks against WPA2-EAP are addressed to the cracking of the passphrase of a single user. 

For implementations that use an outer tunnel for mutual authentication, these attacks are more articulated and possible in case of a misconfigured deployment.

We need to briefly have a look to the EAP types available, separating them based on the additional security provided by the outer tunnel. The outer tunnel, in fact, is the game changer in the wireless security because it encapsulates and encrypts the 4-way handshake that in the other wireless implementations is performed in clear.

EAP Types

Here I shortly present some EAP variations. For a full reference, have a look at IANA reference.

EAP types without an outer tunnel

These solutions do not protect against the capture of the 4-way handshake  and the cracking attempts to recover the passphrase of a single comprimised user.

• EAP-MD5: transmits username in cleartext 'EAP Response Identity' message and the 4-way handshake can be sniffed in order to launch an offline bruteforce attack.

• EAP-LEAP: it is based on the MSCHAPv2 challenge-response protocol, that uses DES encryption. Challenge and response are trasmitted in clear and therefore cracking attempts are still possible.

EAP types with an outer tunnel

The idea behind this type of more secure WPA2-EAP is to encapsulate the 4-way handshake inside an outer tunnel that provides authentication (ideally mutual). This way a TLS tunnel protects the inner authentication (generally MSCHAPv2) from being captured.

• EAP-FAST: it is the safer version of EAP-LEAP and similar to PEAP and EAP-TTLS but with a peculiarity: there is a PAC file that contains the secret and other infos necessary to validate a user authentication attempt. The weak aspect of this implementation by Cisco is that the phase 0 timeframe (PAC provisioning) allows an attacker to setup a fake AP and possibly capture the encrypted credentials of the user. This attack is possible under the condition that 'unauthenticated PAC provisioning' option is set in the Cisco wireless client software.

• PEAP (protected EAP) and EAP-TTLS: these two types both allow mutual authentication by firstly establishing the TLS tunnel between the station and the RADIUS and secondly sending credentials in the inner authentication protocol. This is called mutual authentication because in the outer tunnel the client station validates the RADIUS identity based on its TLS certificate and in the inner tunnel the RADIUS validates the user's credentials. The vulnerability lies when there is a misconfiguration in the client validation of the TLS certificate of the RADIUS. Id est, the client has not been configured to validate the certificate that it receives from the AP. Therefore, an attacker could setup a fake AP with better signal, send its fake certificate, waits the client to leak the credentials and brute-force them offline.

• EAP-TLS: this is truly the safest way to provide mutual authentication with a double verification of the certificates owned by both the RADIUS and the station client. Once the identity of both parts is verified, a random key for the session is generated and then used to create the PMK.

Wireless lab| hacking bad configuration and deploying a secure one

Now I show the results of a test I have done regarding the attack scenario for WPA2-Enterprise. 
The devices involved in this test are:

1.      two stations: a windows 10 pc and an android 8 phone

2.     an attacker OS: a simple kali does its job here ;-)

3.     SSID that uses WPA2-EAP: a OpenWRT router that integrates a RADIUS server (in my case freeradius3 package)

4.     Packet injection capable antenna: TL-WN722N

5.     Fake AP software: Hostapd-WPE

/etc/config/wireless file of the Access Point

The target SSID name that implements WPA2-EAP is GL-AR750-444-5G.

Note that auth_server and acct_server are the value of the RADIUS.

In case of Hacking section, the AP is set to accept PEAP and EAP-TTLS connections. 

[Hacking] PEAP/EAP-TTLS with no RADIUS certificate verification from client

If the CA certificate that signed the RADIUS certificate is not imported on the stations, the following hacking scenario is possible.

An attacker starts a fake AP with hostapd-wpe as shown below:

The extract of the hostapd-wpe file that needs to be changed accordingly to the target

The fake AP is now ready

We now wait a station to connect to our malicious AP (... or we can de-authenticate it, if Management frame protection is disabled). 

The station leaks its challenge and response contained in the 4-way handshake of the inner authentication protocol

Once we captured these credentials, the process of cracking them is very similar to the one for WPA2-PSK.

Ok, I cheated with the dictionary attack :-)

[Deploying] EAP-TLS in a home environment

We now deploy EAP-TLS to avoid that a malicious AP can fool to be the legitimate Enterprise Access Point when a station interacts with it. This is possible by ensuring the use of TLS certificates for both stations and the RADIUS server that authenticates them.

Note: creating a minimal PKI is not the goal of this article, but I provide a good guide available at this link.

For EAP-TLS to work, the clients and the RADIUS certificate must be signed by an internal Certificate Authority and its CA certificate must be imported on the stations and the RADIUS.

This time eap configuration file allows only EAP-TLS among EAP types

Installing the certificate of the Windows client

Installing the certificate of the Android client

Installing the RADIUS server certificate

Let's try to authenticate to the AP with the certificates imported.

The windows client provides its certificate to the AP

The Android phone provides its certificate to the AP

The stations alerts that the RADIUS server is not signed by a known certificate authority

So, the attack has failed. At this point I thought that this article was come to the end. 

Indeed, a look to the above images of the installation of the certificate on the android phone and the windows 10, a comparison of the different way the CA certificate is imported and a thrilling lateral thinking approach pushed me to an additional analysis. As you may notice, for the connection of the windows client only the client certificate is asked... but what about the CA that signed the RADIUS? Ok, it is imported in the Windows certificate store, but what if we sign the RADIUS certificate with a different CA that a victim is fooled to install on the Windows certificate store?

Well, what I would expect is that the windows 10 client connects anyway to the fake AP. But the question is, what the client will possibly leak in such remote scenario? Credentials? No, there is not an inner-authentication in EAP-TLS. However, curious about the result of this test, I fired hostapd-wpe and... the result was the same: the client alerts unkown CA. Game over :-).

Bottom line

As discussed in this post, WPA2-PSK and even WPA2-Enterprise (without a secure configuration) can easily leak the messages of the 4-way handshake and an attacker can perform a cracking attempt to retrieve the correct wireless password. However, the WPA2-EAP is always the desiderable method because reduces the attack surface due to the absence of a shared passphrase and a granular control over the wireless accounts.

A very secure implementation is EAP-TLS, which is based on the mutual authentication of the stations and RADIUS by using TLS certificates signed by a CA. The limitation of this solution, however, is the difficult manageability inherited from the deployment of a Public Key Infrastructure.