EAP-TLS — Blog

Breaking WiFi with EAP-TLS

Introduction

Securing Wireless Networks in the Enterprise environment is paramount and a few options exist today that can help professionals achieve this goal. Some of these options, however, although being built securely and remaining not cracked as of the time of writing this article can become vulnerable if misconfigured. In this article we will speak about one of these options, namely EAP-TLS authentication method.

EAP-TLS?

EAP-TLS (Extensible Authentication Protocol–Transport Layer Security) is a Wi-Fi authentication method that uses digital certificates to securely identify both the client and the authentication server. It establishes a mutual TLS handshake, where the client proves its identity with a personal certificate and private key, and the server proves its identity with its own certificate. Because of this strong, certificate-based mutual authentication, EAP-TLS is considered one of the most secure Wi-Fi authentication methods, often used in enterprise networks with WPA2-Enterprise or WPA3-Enterprise.

There are two main advantages:

This method involves no password. Clients do not need to remember, store, or change passwords. IT staff avoid password brute-forcing, storage, rotation, and helpdesk overhead.
It is secure by design as it relies on a TLS handshake, which is not vulnerable to Man-in-the-Middle (MiTM) attacks today.

Overall, these two factors make EAP-TLS very attractive to implement in enterprise environments.

What can go wrong?

Almost all security issues in modern wireless authentication methods involve some sort of a man-in-the-middle attack. This is when an attacker intercepts traffic between client and server to capture sensitive information.

With password-based methods, attackers seek the password. With passwordless methods, attackers want something that convinces the server to trust them. In EAP-TLS, that sensitive item is the client’s certificate.

Unless the server is misconfigured to accept any certificate (unlikely in practice), attackers can only connect if they steal a legitimate client certificate. One way to attempt this in a Wi-Fi assessment is via an Evil-Twin attack.

What is EVIL-TWIN attack method?

Evil-Twin is an attack where the attacker creates a Rogue Access Point that mimics a legitimate AP and lures clients to connect. The client believes it is connecting to a real network because the SSID, channel, authentication, and encryption all look identical, but it is in fact rogue.

In EAP-TLS, the attacker sets up a rogue AP with:

Offering EAP-TLS authentication (same as legitimate network)
Same SSID and channel (and possibly BSSID) as the legitimate AP
Presenting a supposedly valid CA certificate to the client

If these are met, the client may try to connect to the rogue AP.

The big prerequisite

This attack only works if the client is misconfigured to not validate CA certificates or accepts rogue (self-signed) ones. If clients are properly configured to validate server certificates, this attack fails.

Demo

***Please note that all the screenshots provided in this walkthrough are taken from demos and not from a real engagement. That being said, this attack has been proven to work on a real engagement. Well you will have to take my word on it.***

In this section we will demonstrate a successful EVIL-TWIN attack against a client configured to connect to a corporate EAP-TLS authentication based network.

Find the target
Here we will target the abc-mobile2 network, a network we know uses EAP-TLS.
Capture the handshake
We can either capture the handshake by sending deauthentication frames to clients or by just waiting for one client to connect / reconnect to the target SSID.
Extract certificate information
Next, we will examine the handshake to extract public information about the certificate the client and the server exchanged. This information about certificates is always public.
We open a captured .pcap file in Wireshark and navigate via filtering to:
```
tls.handshake.certificate
```
After selecting the server certificate we press CTRL+SHIFT+X to save the certificate, and we save it in the .der format on our machine.
Next, we view the public information about the certificate:
```
openssl x509 -inform der -in cert.der -text
```
Our next step is to generate a self-signed certificate that we will present to the client.
We can generate a self-signed certificate using FreeRADIUS on a Linux machine. We use the public information about the Server and the CA to fill the fields in the RADIUS configuration and use them to generate certificates. (See Appendix for more info).
Enable Rogue AP
Our next step is to use a self-signed certificate and enable a rogue access point that will offer EAP-TLS authentication to the client.
Wait for the client to connect to the access point
Once the rogue network is enabled, the client will see it appearing with the same SSID and details of alegitimate network. The client will see “Action needed” before connecting to the network.
The client will need to press connect.
The misconfigured client will be asked to accept the certificate and to connect:
Once the client clicks connect it will authenticate against our rogue AP.
We will see an authenticated message in our rogue AP output:
The client has been connected.

Why This Happens?

Usually the misconfiguration exists, because clients are not configured to validate the server identity against a valid list of servers. Also, if the "Don't prompt user to authorize..." setting is not selected, the client's machine will allow the user to trust and accept certificates. In my opinion, this option should be selected unless there is a specific business justification to not do so.

n0blinder