Link Search Menu Expand Document

Exploiting Insecure Server Identity Validation with Deploying Custom Signed Certificates

A common re-occuring test case from Wi-Fi penetration testing projects of corporate WLANs that use WPA2-Enterprise is that client corporate devices have been configured to insecurely validate the RADIUS server’s identity. The Rogue toolkit by default uses self-signed certificates generated in the Evil Twin Attack (ETA) performed against the corporate WLAN. By default Wireless Network Profiles (WNPs) that are created on windows corporate devices are instructured to validate the server’s identity. Therefore when Rogue presents a self-signed certificate to connecting corporate devices, said devices will be the certificate and the authentication process ends.

However, the insecurity arises from the common observation that while the device is instructured to validate the server identity but have not to use an specific trust root Certificate Authourity (CA) to validate the server’s identity. Maybe the client organisation has gone as far as importing custom root CA certificates for their internal Public Key Infrastructure (PKI) infrastructure into the device’s certificate store, they have not explictly selected the trusted CA certificates. In these instances, an adversary could present certificates that have been signed by a default trusted root CA, which the device will trust to validate the server’s identity, and will then complete the authentication process.

The following screenshot illistrate the default configuration for a WPA2-Enterprise WNP using EAP/PEAP/MSCHAPv2. In the screenshot, the validate the server’s identity tick box has been selected. But neither of the conditions have been met, therefore any of the certificates oaded into the device’s trusted root CA certificate store can be used to validate the server’s identity:

  • The connect to these servers (examples:srv1;srv2;.*\.srv3\.com) tick box has not been selected and therefore no CA hostnames have been specified for internal PKI infrastructure.
  • No default Trusted Root Certification Authorities have been explicitly selected, therefore all are selected.


The following screenshot illistrates the same insecure server identity validation configuration for a WPA2-Enterprise WNP using EAP/TLS.


Ultimately, the absence of explicitly selecting the trusted root CA used in the server identity validation process means a Windows-based device will use any trusted root CA certificate that has been loaded into it’s certificate store in the validation process. In a penetration test, the Rogue toolkit can be used to identity and abuse this insecure server identity validation process to present certificates signed by a default trusted root CA to still capture WPA2-Enterprise credentials using the standard ETA process.

The process of getting a certificate signed by a trusted root CA is fairly straightforward depending on the signing CA selected. My preferred choice is to use letsencrypt to generate a certificate for a provisioned EC2 instance, letsencrypt is specifically chosen because the certificate chain generated are signed by the ISRG Root X1 CA.

Generating the External Certificates

The process for generating external certificates is fairly typical:

  1. deploy an EC2 instance
  2. create a record for the EC2 instance in the public DNS zone file
  3. install Apache and configure/enable mod_ssl
  4. install certbot
  5. run certbot and package the produced certbot files
  6. Download and unpack the certbot files on the device running the Rogue toolkit

Using Externally Generated Certificates

The Rogue toolkit supports the use of externally generated certificates with the integrated freeradius-wpe installation and is as simple as the example command.

sudo python3 --preset-profile wifi4 --essid rogue -i wlan0 --auth wpa-enterprise --channel-randomiser --default-eap peap -E all --server-certificate /home/vagrant/fullchain.pem --ca-certificate /home/vagrant/chain.pem --server-private-key /home/vagrant/privkey.pem

The below screenshot shows that at frame 45 the client device rejects the self-signed certificate generated as per the standard Rogue practice python3 --cert-wizard, which reveals the presence of the server identity process. Then new ETA instance is deployed using the above command with the externally generated certificates, the device no longer rejected the certificate as seen in frame 65.