EAP WPE Attack Theory
- Running & Configuration
Clone this wiki locally
Most enterprise EAP deployments make use of a tunnelled EAP protocol, typically PEAP or TTLS. Both set up a TLS tunnel between the client (supplicant) and RADIUS server (authenticator) with the AP in the middle passing the EAP packets back and forth.
However, the security of this TLS tunnel is down to whether the client correctly validates the certificate presented by the RADIUS server. In the browser world, this is done by both checking that the certificates common name (CN) matches the server name of the website, and that the certificate is signed by a trusted certificate authority. However, in the wifi world, CAs can’t issue certificates for wifi networks, because wifi network names aren’t globally unique and tied to an organisation in the same way domains are. This means a client needs to be told how to validate the certificate.
If a user connects to the network themselves, they often don’t configure robust certificate validation or validate the certificate on easily spoofable criteria (because humans aren’t good at memorising fingerprints and validating by hand). See Apostille for an example of how a certificate and it’s signing chain can be copied.
Many default configurations provide an opportunity for bypassing the validation. In the case of the validation being done by CA, it may be possible to purchase/procure another certificate from the same CA. Notably, in Linux or Android, wpa_supplicant has no ability to validate the specific server certificate only the CA! In the case of iOS/macOS no certificate is considered trusted, even if signed by a trusted CA, and so the presented certificate must be inspected by hand, making cloning attacks possible.
Thus, the only way to robustly validate that the RADIUS cert is correct, is to validate that the presented certificate is the exact certificate we expect, not just that it has the right CA or words i.e. certificate pinning. This can be done in Windows via Group Policy and iOS/macOS via Apple Configurator profiles. However, the RADIUS server can’t validate that the client has done this, so if a single client or many disable strict checks, the organisation would be unaware, which means typically many clients are vulnerable.
Inside the TLS tunnel, a protocol such as MSCHAPv2 is used for the supplicant and authenticator to prove to eachother that they know the password. MSCHAPv2 is a simple challenge response protocol. If the client connects to a rogue access point due to the difficulties with validating server certificates described above, then the rogue RADIUS server can intercept the response from the client and crack it using tools such as asleap, john the ripper or hashcat. As MSCHAPv2 is based on DES, this can be done fairly quickly.
Other forms of inner authentication, such as CHAP (aka MD5) or MSCHAPv1 or even PAP/GTC (plaintext) can be used as well. These can also be captured and cracked.
As a solution to this problem, EAP-TLS is often suggested. EAP TLS makes use of mutual TLS authentication, thus both the RADIUS server and the supplicant require certificates. The thinking is that if a client has a certificate, they won’t be sending credentials that can be cracked, and the user can’t connect to a network with just their username and password, and so IT must have configured their wifi, leading to fewer exceptions.
Notably, EAP-TLS does not fix the problems described with outer authentication, it merely makes it harder for users to connect and forces IT to be involved.
In the worst case, if the server certificate validation has any of the myriad possible problems described above, the rogue AP can just accept the certificate the client presents, and the client will connect to the malicious network.