Contents

Insecure PEAP Networks?

mgp25 included in research infosec

2019-07-26 866 words 5 minutes

Contents

As part of part of a red team exercise, gaining foothold is key in our path to achieve AD control. In this post I will be talking about WPA2 Enterprise Networks, how PEAP works, why many deployed PEAP networks are insecure and how to take advantage of this to gain access and finally how to prevent it.

What is PEAP?

PEAP (Protected Extensible Authentication Protocol) is a version of EAP, this type of authentication protocol is used in wireless networks.

PEAP authenticates the server with a public key certificate and carries the authentication in a secure Transport Layer Security (TLS) session, over which the WLAN user, WLAN stations and the authentication server can authenticate themselves. Each station gets an individual encryption key. When used in conjunction with Temporal Key Integrity Protocol (TKIP), each key has a finite lifetime.

How PEAP works?

The best way to understand it is with a ladder graph showing communication between the device and server:

Are they insecure?

No, they aren’t. It is true that some of the algorithms inside the TLS tunnel like MSCHAPv2 has been broken (More info on Moxies video), however since it is inside the TLS tunnel it doesn’t represent a security issue at all. In fact, we should worry about the encryption algorithms like GTC. EAP-Generic Token Card (GTC) enables the exchange of clear-text authentication credentials across the network. EAP-GTC is used inside a TLS tunnel created by TTLS or PEAP to provide server authentication in wireless environments. And still this is not the main issue about enterprise networks but who should I trust.

The main issue: Should I trust?

When it comes with PEAP deployments is that it relies on public certificate authority trust to protect the TLS tunnel. Although using public CAs sounds good, the problem is, unlike with web browsers, wireless clients will only check that the cert is signed by a trusted certificate authority; The certificate CN is not tied to the SSID or AP at all. Because of this, an attacker can simply purchase a certificate for a domain they rightfully own, and host a malicious access point with this certificate. Clients configured to trust public CAs, or a specific CA used by a particular deployment, will connect to this evil access point without complaint, allowing us to capture the certificate. [6]

The attack

The attack can be done manually using hostapd and freeRadius, and you can set a more granular configuration [7]. However, there are tools that already gives you the possibility to do this faster and very easy to do. I found two tools that worked really well:

rogue [8]
eaphammer [5]

In this post I will be showing EAPHAMMER.

Certificate identification

Identify the certificate authority being used to sign the targets AP cert. If it is a public authority, we often can purchase a certificate from the same public authority and gain the trust of most target clients. If the target clients are configured to trust only the specific certificate used, rather than the CA this will not work.

EAPHAMMER has an option I haven’t tried yet to pull information about the AP certificate. Nevertheless, there are other ways to obtain this information.

tshark

The following command will get certificate information from our capture:

1

tshark -nr capture.pcap -2 -R "ssl.handshake.certificate" -V

This could be potentially be automated using scapy, parsing PCAP files or parsing live packets. As per my research, I found a tool that does this and it is called EAPeak. EAPeak is a suite of open source tools to facilitate auditing of wireless networks that utilize the Extensible Authentication Protocol framework for authentication. It is meant to give useful information relating to the security of these networks for pentesters to use while searching for vulnerabilities.

EAPHammer

EAPHammer is a toolkit for performing targeted evil twin attacks against WPA2-Enterprise networks. It is designed to be used in full scope wireless assessments and red team engagements. As such, focus is placed on providing an easy-to-use interface that can be leveraged to execute powerful wireless attacks with minimal manual configuration.

You can create self-signed certificates using eaphammer wizard:

1
2


# generate certificates
./eaphammer --cert-wizard

Or you can purchase certificates using the same CA as the target for more sophisticated attacks.

Now lets start our roque AP:

And here we have user credentials in plan text! How easy and how awesome is that:

How to prevent this attack?

The key link in this chain then is the mutual authentication between the RADIUS server and the wireless client. The client must properly validate the RADIUS server certificate first, prior to sending it’s credentials to the server. If the client fails to properly validate the server, then it may establish an MS-CHAPv2 session with a fake RADIUS server and send it’s credentials along, which could then be cracked using the exploit that was shown at DEFCON. This is commonly referred to as a Man-in-the-Middle attack, because the attacker is inserting their RADIUS server in the middle of a conversation between the client and the user database store (typically a directory server). [2]

References