Public Trust with PEAP Networks

PEAP Basics

With PEAP networks, authentication is performed via an MSChap handshake protected by a TLS tunnel. Since MSChap has been effectively broken (GHOST_URL/quick-tip-crack-ntlmv1-handshakes-with-crack-sh/) for years, the TLS tunnel is essentially the only security provided.

Since the TLS tunnel is the key security control, the security of a PEAP network hinges upon the proper configuration of client trust. Since PEAP networks are commonly deployed to avoid the difficulty in configuring certs for EAP-TLS, yet it’s security is dependent on a similar process, many PEAP networks are deployed insecurely. Put another way, it is easy to deploy PEAP in an insecure manner, but just as difficult to deploy it securely as it is to deploy EAP-TLS, making it basically the worst of both worlds option.

One of the key difficulties in deploying PEAP securly is that all the security is in the client’s certificate trust configuration, and unlike EAP-TLS, if this client configuration is insecurely set, PEAP will still work, but it will be insecure. There are many cases where a subset or majority of wireless clients are securely deployed, however, a number of clients are not securely configured and can be exploited. Since these incorrectly configured clients still work, however, they often go unnoticed as being bad.

When PEAP is Worse than no Security

PEAP deployment issues are widespread, and not only allow attackers to get on to your corporate Wi-Fi network, but often provide them an AD credential in the process. With internal network access, and an AD credentials, a signficant number of attack paths are open to an attacker inlcuding kerberoasting, using BloodHound to track down paths to domain admin, read access to the domain, potential RDP or local admin rights to servers, and access to internal directories/emails. Typically an attacker with this level of access is able to pivot and escalate to Domain Adminsitrator or a similar high level of access within days.

Trust and Betrayal

One of the common systemic issues Tevora sees with PEAP deployments is reliant 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.

Performing the Attack

Over the course of the last few years the tools to audit PEAP networks have become increasingly more robust. Although it is still possible to patch freeradius and setup a full wifi setup with as much granular control as you’d like, its become much easier to bootstrap a rogue PEAP access point. s0lst1c3 has put together a great tool called eaphammer (https://github.com/s0lst1c3/eaphammer) that builds upon hostapd-wpe to create an easy to use commandline tool and is our preferred tool for the job.

Step 1

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.

The certificate used by the AP can be seen with EAPHammer or we can pull it from network traffic. The following command will use tshark to find certificate information in a PCAP file:

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

We can also script out utilities to parse only the certificate information needed for our evil access point in network traffic.

The following script will parse a pcap and return the requested certificate fields:

Step 2

With the certificate identified, if it is a public cert, purchase a certificate from that same public authority. This as simple as using EAPHammers built in certificate wizard (https://github.com/s0lst1c3/eaphammer#xiii2c—using-external-ca-certs-and-keys—cert-wizard-create) to generate a self-signed cert for your controlled domain, and taking the generated csr from EAPHammer’s certs folder and uploading that to be signed by the chosen CA. Copy back the certificate to overwrite EAPHammer’s self signed cert with the propper chain, and run the tool.

Step 3 Perform the attack

With the publicly trusted certificate configured, you can now start the rogue access point to collect MSChap handshakes. Luckily EAPHammer again makes this simple, follow their instructions here: https://github.com/s0lst1c3/eaphammer#iii—stealing-ad-credentials-using-hostile-portal-attacks

Step 4 Crack the Handshake

The MSChap handshake can be cracked as a NTLMv1 handshake in hashcat, or in crack.sh to get the underlying NTLM hash: GHOST_URL/quick-tip-crack-ntlmv1-handshakes-with-crack-sh/. We recommend using hashcat initially to try and get the password, and falling back to the crack.sh service if needed.

Securing your Wireless

Due to the fundamental issue being PEAP relying on client trust being correctly configured, but still working albiet insecurely when it’s not, Tevora recommends migrating to EAP-TLS. EAP-TLS can be more difficult to get working, however, it is typically easier to get working than it is to get PEAP working securely.

If PEAP needs to be kept, it is critical that client trust is deployed securely. Typically, the best way to do this is using an internal Public Key Infrastructure (PKI) to sign the keys instead of a public authority and ensure that all client devices have the internal CA trusted, and are configured to only accept trusted certificates. In practice, however, there are often client devices that slip through this provisioning and can connect to the network without verifying certificate trust, re-iterating the point that EAP-TLS is a better solution as when this misconfiguration occurs it simply won’t work, instead of continuing to work but insecurely. Certificate pinning also works by telling the clients to trust only a single certificate instead of any certificate signed by the trusted authority