Breaking Enterprise Wireless

Published: 08 March 2020

In our previous posts we discussed how WEP is completely broken, known weaknesses with WPA, and bruteforcing WPA using AWS. This time around it’s time to look at “Enterprise” Wireless security. These are networks protected with EAP – Extensible Authentication Protocol.

In our previous posts we discussed how WEP is completely broken, known weaknesses with WPA, and bruteforcing WPA using AWS. This time around it’s time to look at “Enterprise” Wireless security. These are networks protected with EAP – Extensible Authentication Protocol.

However EAP is not just one protocol, but a collection of protocols – such as:

  • EAP-MD5
  • EAP-TLS
  • EAP-TTLS
  • EAP-FAST
  • PEAP (EAP-MSCHAPv2)
  • and more…

We won’t be breaking down every authentication method here, we’ll simply be highlighting that using Enterprise security for a wireless network doesn’t immediately remove all risk – and can in fact introduce more risk.

Both EAP-MSCHAPv2 and EAP-TTLS utilise password based authentication; for example to authenticate to Active Directory. This could be a machine account or a user account. This addresses one of the issues with WPA, which is the difficulty in revoking a user’s access to the network – as all devices use a single Pre-Shared Key (PSK).

Utilising Active Directory credentials instead mitigates this issue, by allowing a single user’s access to be revoked, however introduces the additional risk of the network only being as secure as the weakest password.

Capturing the Keys

For protocols such as EAP-MSCHAPv2 and EAP-TTLS it may be possible to set up a malicious access point which accepts EAP authentication, and if the device or user enters their credentials they can be captured.

Generally these networks should be protected by a trusted X.509 certificate, although an attacker may be able to use an illegitimate certificate (such as a self-signed one) and the user may connect any.

A simple way to set up a network of this nature is using hostapd-wpe, which will set up a network with a chosen SSID, a crafted certificate, and listed for EAP authentication attempts.

It can be installed on Kali Linux with the following command:

apt install hostapd-wpe python-jinja2

It’s also advised to stop NetworkManager to prevent it interfering.

service NetworkManager stop
killall wpa_supplicant

Setting up the malicious access point can be done by modifying the configuration file at /etc/hostapd-wpe/hostapd-wpe.conf, however there’s a tool which will set up both the configuration file and the certificates for you:

wget https://raw.githubusercontent.com/WJDigby/apd_launchpad/master/apd_launchpad.py

You can then set up the network with:

python apd_launchpad.py -t [target] -s [ssid] -i [interface] -cn [common-name]
e.g.
python apd_launchpad.py -t TestNetwork -s TestNetwork -i wlan0 -cn TestCompany.local

You may wish to change the eap_user_file variable in the resulting file to be the default:

eap_user_file=/etc/hostapd-wpe/hostapd-wpe.eap_user

A configuration file has been created using apd_launchpad.py

This can be launched by specifying the configuration file to hostapd-wpe:

hostapd-wpe ./TestNet/TestNet.conf

The access point is now listening for user connections

If a user attempts to connect to the network they will be asked for credentials, as such:

The login box may be shown.

The username will be send to the network (and displayed in the output of hostapd-wpe). The user will then be prompted with a warning asking the user if they were expecting the network:

A warning of sorts will be shown to users

If they click to connect, hostapd-wpe will capture the credentials and display hashes to the screen:

Here the captured NETNTLM hashes are displayed by hostapd-wpe.

These hashes will also be logged in the hostapd-wpe.log file.

These can be cracked with hashcat using the following option:

hashcat -m 5500 hashfile.txt wordlist.txt

Hashcat has been used to crack the hash revealing the plaintext as “password”

Here this tiny travel laptop has achieved 12860H/s, if you need more then check out our post on running Hashcat on AWS! A p3.16xlarge instance on AWS benchmarks at around 418GH/s.

Securing the Network

Here there are two weaknesses being exploited, the fact that the client device is connecting to a network with an invalid (self-signed in this case) certificate.

The second issue is the use of passwords that can be cracked. However given the speed of AWS GPU instances and the commonality of weak credentials in use in Active Directory domains this is very likely.

The most secure alternative is to utilise mutual authentication (where both the server and the client authenticate to each other) using digital certificate based authentication, such as offered by EAP-TLS. However, there can be more administrative overhead involved in the deployment of these networks.

Alternatively, PEAP (EAP-MSCHAPv2) can be used with the device’s machine account – which would likely mitigate the risk of users choosing weak passwords and thereby reducing the security of the wireless network.

Read more: