.svg "2024_Full_Logo_Full_Color_SVG (1)"){kind=logo}
Is your corporate wifi as secure as you think it is?
A common configuration for WPA Enterprise wireless networks is to use a combination of PEAP (Protected EAP) and EAP-TTLS (Tunneled Transport Layer Security). Though this configuration solves several issues found in other configurations, it (sometimes) also has its own fatal flaw. If a client is able to connect without properly verifying the authenticity of the access point (through its certificate), then there is an opportunity to capture the username and handshake. This information can be used to attempt to crack the user’s password offline using a password dictionary. To capture the necessary information we will need to set up a rogue access point (AP) that masquerades as the target AP. Setting up the rogue AP can be a bit of a challenge, so this blog post is a walkthrough of a rogue AP setup on Kali 2.
The rogue AP we will use for this purpose is a modified version of the open source FreeRADIUS server, currently called hostapd-wpe (hostapd Wireless Pwnage Edition). The modifications were developed by Joshua Wright and Brad Antoniewicz.
Installing hostapd-wpe:
To get this solution running on Kali 2, you first need to be sure you are using the rolling sources. At a minimum, you must add the following line to your /etc/apt/sources.list file if it is not already there:
deb http://http.kali.org/kali kali-rolling main contrib non-free
More details about the rolling sources can be found on the Kali docs website. My understanding is that the current recommendation is to move over to rolling repositories exclusively, but that decision is outside of the scope of this post.
If you had to make any changes to your sources, you will want to do a apt-get clean
Then to install hostapd-wpe you will want to do:
apt-get update apt-get install hostapd-wpe
A sample configuration file will be produced at: /etc/hostapd-wpe/hostapd-wpe.conf. In most cases this file will require modifications before it can be used. Since this is a rogue AP used for a wireless assessment or pentesting engagement and not meant to be run as a service, it is easy enough to run it with a custom configuration file for the current engagement. So the easy way to manage this is to copy that file into an engagement working directory so that we have a record of the configuration used for the test. Then we simply edit the copy.
Verify your wireless interface:
Before we start editing the configuration file we should verify the name of our wireless interface. Typically this is wlan0 but if working with multiple cards it may be something else (e.g. wlan1, wlan2, etc…). You can use the iwconfig command to list wireless interfaces. If you don’t see any wireless interface listed, you may need to unplug and replug the USB adapter. This sometimes happens if running Kali inside a virtual machine.
Configuring hostapd-wpe:
The configuration file changes you will need to consider include:
- interface=wlan0 Set this to your wireless interface, usually wlan0.
- #driver=wired This is the default setting and must be commented out if using a wireless adapter (which is usually the case).
- ssid=impersonated_ssid Uncomment and set this value to the SSID that is being impersonated.
- hw_mode=g Uncomment and set to the value g for wireless g or n. Other values (e.g. a, b, ad) are possible. Ideally this should match the ap being impersonated.
- channel=1 Uncomment and set to whichever channel you want to broadcast you ap. Often this is 1 or 6.
- wpa=2 This should be set to 2 for wireless g, and 3 to support wireless n.
- wpa_pairwise=TKIP CCMP This may need to be modified to match the ap being impersonated. Removing TKIP from the list is likely for modern configurations.
“Unmanage” your wireless adapter:
With the configuration file ready to go there is still one step left before we can turn on the server. By default Kali will probably have the NetworkManager service running, which is going to try to manage the state of our wireless interface for us. This makes it impossible to switch to AP mode, which is what we need. To address this, we can tell the NetworkManager service to ignore our device. This is done by modifying the /etc/NetworkManager/NetworkManager.conf file and adding the following section:
[keyfile] unmanaged-devices=mac:00:aa:bb:cc:dd:ee
Note that the 00:aa:bb:cc:dd:ee should be the mac address of the ALFA. Multiple addresses can be specified if separated by a semicolon (i.e. ‘;’).
Once this change is made, unplug the USB, wait a few seconds, and plug it back in. The led on the ALFA should not be lit. The follow these steps:
- Type iwconfig to verify that the device and interface was recognized.
- Type ifconfig to verify that the interface is not up (it should not be listed).
- Type the following command, replacing wlan0 with your interface: ip link set wlan0 up
- Type ifconfig to verify that the interface is up (it should now be present). The led on the device should now be illuminated.
Start the rogue server:
If all of this works, you should be ready to go. Simply type:
hostapd-wpe ./hostapd-wpe.conf
Remember to replace ./hostapd-wpe.conf with the path to your custom configuration file.
You can test connecting to the rogue AP with any wireless device. Login will, of course, fail and you should get a certificate prompt, which is fine since most target users will click through and accept a bad cert. If all this passes you should start seeing stuff show up in the logs. A successfully collected credential will look something like:
mschapv2: Thu May 5 12:48:51 2016
username: test
challenge: 35:30:33:52:07:d1:8c:78
response: b8:53:4b:77:a5:a9:b2:ae:53:33:72:88:e4:d0:39:72:48:02:67:9b:b6:09:5f:c7
jtr NETNTLM: test:$NETNTLM$3530335207d18c78$b8534b77a5a9b2ae53337288e4d039724802679bb6095fc7
wlan0: CTRL-EVENT-EAP-FAILURE 08:74:02:5d:de:86
The values from the challenge and response can then be fed into the asleap tool, also written by Joshua Wright and also present Kali 2.
Closing Notes:
If you are trying to do something that is not covered in this blog post, I would encourage you to take a look at the latest edition of Hacking Exposed Wireless, by Joshua Wright and Johnny Cache. That is where I found much of the information covered in this blog post.
Jason Gillam is a Principal Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas – ProfessionallyEvil site for services provided.