Attack
To demonstrate an attack against WPA enterprise,
we will target a network called, Playtronics.
Let’s take a moment to summarize our attack.
We will be creating a rogue AP
to match the settings of our target as closely as possible.
We will use hostapd-mana to create the rogue AP and match the target settings.
This will help us capture the credentials, which we will crack later.
We will also need freeradius, which is an open source RADIUS server.
We won’t need it for its RADIUS capabilities, but it contains scripts that
will help us generate the certificate for hostapd-mana.
We will exploit either the misconfiguration of the security settings
in client devices,
the lack of proper certificate set-up on the RADIUS server, or both.
After putting our wlan0 interface in monitor mode,
we now have an interface called wlan0mon.
We will identify the channel of the target AP and gather its ESSID and BSSID.
Our target is the Playtronics AP,
which operates on channel 2,
And we have captured its BSSID.
And the MAC address of a connected client.
The AUTH column shows the AP has an authentication type of MGT,
meaning WPA Enterprise.
While its usually not necessary, we will create a certificate similar to the one
from the RADIUS server that the AP serves to its clients.
Next, we will restart the capture similar to what we did when cracking WPA-PSK.
We will listen on the same channel as the AP.
And save the data to disk as Playtronics.
In order to get the certificate, we can deauthenticate a client.
We’ll do this the same way we would with a WPA-PSK client, using aireplay-ng.
Deauthenticating once,
targeting the AP,
and the client.
When the client reconnects it will redo the authentication.
Once airodump-ng indicates we’ve captured a handshake, we can stop the capture.
In most instances, a certificate is present.
We will get the certificate from the enterprise authentication
that happened before the handshake.
We can now disable monitor mode.
We have to open the capture file with Wireshark
and locate the server certificate frame.
First, we can use the BSSID as a display filter to narrow down the AP.
Appending eap to the display filter will also show the full authentications.
To quickly narrow down on the certificate, we can append these TLS handshake filters,
which will show the exact frames where the certificate is given.
From there, in the Packet Details pane,
we'll open Extensible Authentication Protocol,
and Transport Layer Security
We now have to open the TLSv1 Record Layer: Handshake Protocol: Certificate.
Once there, we will have to expand Handshake Protocol: Certificate item,
then Certificates.
Inside Certificates, we can see one or more entries named Certificate.
Each of them will be preceeded by the length.
For each certificate, we can right click and select Export Packet Bytes
to save the data into a file with a .der extension.
These certificates, which are in binary form,
can either be opened in the file manager,
or we can display information about them using an OpenSSL command.
These are the details we will need for our attack.
While this step isn’t necessary, we can convert it to PEM format.
PEM format is basically a base64 version of the .der certificate, limited to 64
columns, with a header and a trailer to indicate it is a certificate.
Before we dive into the configuration files,
we need to learn a little bit about Public Key Infrastructure.
PKI is a vast and complex subject,
but we’ll focus our attention on the parts of it that are useful for us.
As such, the certificate authority is an entity which issues digital certificates.
While a CA can issue server and client certificates, we will skip the client ones
as they are used to authenticate clients to a server.
To understand the relationship between two configuration files,
CA and server, we can draw a parallel to HTTPS.
Certificate authorities, such as Let’s Encrypt issue certificates to servers
so that servers can provide encrypted communications to their clients.
Web browsers verify websites’ certificate validity using various criteria,
and one of them is being issued by a trusted certificate authority.
If it is not, we are warned by the browser.
Verifying a server certificate that has been issued by a CA is easy.
However, it is important to note that the CA certificate is most often self-signed.
What makes it trusted
is it is in the trusted root CA certificate store of our system.
In WPA Enterprise, the RADIUS server is in the same boat as a regular web server.
It is a “server” as well, and it needs a certificate issued by a CA.
This is why we will have to modify the CA file and the server file later.
The RADIUS has to provide its certificate through the AP to potential clients.
It will need to provide the public CA certificate as well,
because the CA isn’t in the user trusted root certificate store.
We will now use freeradius, an open source RADIUS server,
which can be installed with apt.
We’ll use its scripts to generate certificates
that look similar to the ones we captured.
We’ll need to change the settings of ca.cnf.
We edit the [certificate_authority] fields to match our target CA certificate
to appear less suspicious to clients in case they inspect the certificate.
The information needs to be updated in the server file.
This should be similar to what we did with the CA.
We will edit the [server] fields to match our target server certificate.
We’ll skip the client certificate because we don’t need it.
Next, we’ll build the certificates.
First, we need to regenerate the Diffie- Hellman parameters, with a 2048 bit key
When freeradius was installed, a 1024 bit key size was used for the DH parameters,
but if we use this DH file, hostapd-mana will throw an error and abort startup
because it is too small.
We’ll avoid this by deleting the DH file before running make.
Although we get an error,
the client side doesn’t matter because we don’t use any client certificates.
We were able to successfully generate the Diffie-Hellman parameters,
CA certificate, and the server certificate correctly.
If we run make but the certificates already exist,
we will not be able to overwrite them.
We have to run make destroycerts to clean up first.
Now that we’ve generated the certificates, we will create our own Playtronics AP
with hostapdmana that can be installed with apt.
We will first create the hostapd-mana configuration file,
In this configuration, we will be using the same SSID as our target, Playtronics.
It also uses the certificates we edited.
We’ll next create the EAP user file referenced in the configuration file,
And captured credentials will be saved in a file in the temp directory.
We will now create a hostapd-mana user file.
The format of the hostapd eap user file has the first column indicating
a specific user by username
or, in the event of wildcard character, any user.
It can contain a domain name as well.
The second column contains the protocols allowed for the specific users
and authentication phase.
The third column is optional and is used for the password
when a specific user is mentioned.
The fourth column indicates that the settings on this line
are for phase 2 authentication.
There are additional flags,
but we won’t cover them here as they aren’t necessary for this attack.
The file format allows for a variety of configurations.
Although a system administrator could limit certain protocols, we’ve enabled
as many combinations as possible, in order to increase our chances at capturing
hashed credentials, even from users with limited choices.
On the first line we can see a few protocols which are to be accepted
by the RADIUS server in hostapd-mana for any user.
On the second line, we are working with protocols for phase 2 authentication
(or inner authentication) as denoted by the [2] at the end of the line.
In this instance, the “t” is for the username,
which is a hardcoded value in hostapd-mana, followed by the protocols,
and the second string, “pass”, is its password.
We’re ready to continue.
Next, we’ll start hostapd-mana with the configuration file we created earlier.
Depending on the operating system from which a user logs in,
they may be prompted to verify our Playtronics certificate.
Clicking on Show Certificate will display basic certificate information,
with the CA and the certificate itself.
The arrows in the bottom section allow to expand the information
and look at the details:
When a victim attempts to authenticate to our AP, the login attempt is captured.
The output shows that the chosen authentication is PEAP,
and the line below that one includes the username cosmo.
We will be using asleap, another password cracking tool that can be installed
with apt, to crack the password hash.
We can copy/paste the mana output, starting with asleap,
and append the JtR wordlist to the -W parameter.
We recovered the password.
Even if these credentials are not immediately useful to us,
we’ll make a note of them as they may be of use later in the pentest.
These credentials are also in the temp file referenced earlier.
In a live scenario, it is likely the device will keep connecting
and hostapd-mana will keep showing challenge/responses.
There are a number of attack escalation opportunities at this point.
A tool called crackapd,
can automatically run asleap when it sees credentials in the log file.
If crackapd successfully recovers credentials,
it adds the user to the hostapd-mana eap_user file.
This allows the user to successfully connect to our rogue AP.
We could also provide Internet access by adding a DHCP server
and a few nftables rules to enable routing,
although we won’t describe that approach in detail here.
We could push the attack further and authenticate ourselves to the real AP.
This, along with some different nftables rules,
would provide the user access to the actual company network.
If clients don’t connect to our rogue AP, we can use another wireless card
and look for the clients connected to the legitimate APs with airodump-ng.
We would then use aireplay-ng and keep deauthenticating them.
They may eventually connect to our AP, except in cases when the configuration
has been locked down or if the network uses 802.11w.