You can spend as much time as you want securing your RADIUS server infrastructure and the rest of your network. But are you really secure against WiFi spoofing attacks?
In this article, we show just how easy it is to convince supplicants to send user credentials such as names and passwords to pretty much anyone through fake networks and man in the middle attacks. Ouch!
This article is based on a 2016 presentation done by Arran Cudbard-Bell at NetworkShop 44 .
Understanding WiFi spoofing and 802.1X vulnerabilities
WPA (and WPA2) enterprise networks use 802.1X for secure network access. In practice, this means that when an end-user device wants to talk to a wireless access point (AP), the device has to use EAP. The device sends EAP packets to the AP, which in turn forwards them to authentication servers running RADIUS.
The most common EAP methods are PEAP, TTLS, and EAP-TLS. Like HTTPS, these methods use TLS and digital certificates in order to authenticate the parties involved and establish secure connections.
The problem is that when you log into a website, your browser shows the URL (or domain name) and a lock icon in the address bar, providing clear visual confirmation of the site's identity. No such information is available for EAP. As a user, you are left “flying blind” with network access, and can only hand your passwords blindly to a random server which does something with them. You can only hope for the best.
The question, then, is “How can a user trust an EAP server?” In an ideal world, that trust would be automatically verified, as with HTTPS. But EAP isn’t like that.
Instead of sending credentials only to trusted servers, EAP clients follow the practice of “I have no idea who you are, but you can still have the user name and password!” This practice makes for poor security and leaves wireless networks vulnerable to WiFi spoofing attacks where attackers can intercept user credentials.
What we did: Testing WiFi spoofing vulnerabilities
We ran tests with some common operating systems, as shown below. Each test system was preconfigured with the correct information for the network. In an ideal world, this configuration would prevent the systems from connecting to malicious networks.
To test this theory, we created a malicious network. We set up an AP which broadcast a known SSID. However, we configured the AP to talk to our own RADIUS server, instead of the real one—essentially creating a man-in-the-middle attack scenario.
We still needed a server certificate, though. If we created an obvious “fake” certificate, then the user could trivially tell that the certificate was wrong.
Since we are the authors of FreeRADIUS, the simple solution was to modify the server. We modified the server to automatically create certificates based on the realm (domain name) that the user presented. Even better, the various fields in the certificate (domain name, email, telephone, etc) were taken from the real certificate that was presented by the domain!
The steps taken by the server were then:
- The server receives an EAP connection attempt from user@example.org.
- The server strips the realm to get example.org, then uses curl to get the HTTPS certificate from example.org, or www.example.org.
- The various identification fields are taken from that certificate and used to create a new “fake” certificate.
- The “fake” certificate was then signed by an internal fake certification authority (CA).
- The “fake” certificate was presented to the user as the RADIUS / EAP server certificate.
The process was fast enough that there was no noticeable delay for the user. We also had the server return “success” where possible (TTLS + PAP, or TTLS + CHAP). That success was not as important, as we were not interested in collecting credentials, or having the user access a fake network. Instead, we wanted to see what the client machines did with the fake certificates and how vulnerable they were to WiFi spoofing.
Oh, boy, were the results disappointing.
Windows operating system vulnerabilities
We tried connecting to our fake “eduroam” SSID. Windows determined that the SSID supported WPA-Enterprise and prompted for a name and password.
Surprisingly, Windows asks the user for a name and password before the EAP method is selected. This flow is entirely inverted from the WWW process, where the browser verifies the server before the user is asked for any credentials.
Being the naive user, we just shrugged and entered our credentials.
The system noticed that the certificate had changed, and presented the following popup.
What is anyone supposed to do with that information? The system presents nothing more than an opaque series of hex numbers. It did not even present a summary of the certificate information, so all of our hard work in creating the realistic fake certificates was wasted.
We just clicked “Connect”. We had configured the RADIUS server to automatically select TTLS. Windows successfully negotiated that, and used PAP (clear-text passwords). A short time later, we had a network connection.
That is disappointing. Maybe another operating system will be better.
OSX security weakness
We next tried OSX. As with Windows, the user is asked to enter a name and password before the EAP method is selected.
We entered the credentials, and saw the following popup.
The good news here is that OSX noticed that the certificate changed, and is asking the user if the new certificate is OK. We clicked on “Show Certificate”, and got the following popup.
Again, good news here. The user gets a bit more information than just a series of meaningless hex digits. All of the information in the fake certificate is presented to the user, including the fake CA. This data allows the user to make a much more informed decision.
However, unless the user is willing to examine the fake CA, and understands what a fake CA is, they are not much better off than the case for Windows.
We clicked “Continue”, and the system asked us to authorise the changes.
We entered our password, and the OSX certificate store was updated to cache our fake certificate!
This network profile (SSID + credentials) will be cached until the fake certificate expires. That caching can be good, in that it allows for quick reconnection to the same SSID. However, that profile will also be re-used on networks with the same SSID, but which present a different certificate!
So in the end, OSX is not much better than Windows at preventing WiFi spoofing.
The summary
End user systems are terrible at too many things related to EAP security and WiFi spoofing prevention. They ask the user for credentials before verifying the server's identity. They do not adequately verify the server certificate. They rely on the user to make decisions based on data that is opaque or meaningless to the user when facing potential cyber threats.
All of these issues result in systems that are incredibly insecure. The good news is that it is possible to fix this behaviour with better network security solutions.
The fix for WiFi spoofing vulnerabilities
Operating system vendors are gradually getting better over time. However, there is still substantial room for improvement. The last few years have shown OS vendors making random changes to the behaviour of their supplicants, which makes life harder for everyone.
Alan DeKok (FreeRADIUS project leader and CEO of InkBridge Networks) has written a draft for the IETF that summarises these issues, and proposes a series of fixes. The end result is that 802.1X and WiFi authentication is just as easy to use, and just as secure, as logging into to an HTTPS server.
We will be working this document through the IETF process. We have
already had confirmation from a number of vendors that they support
it, and are planning on implementing the standard. We hope that this
proposal will be standardized quickly, and will be widely used in the
near future.
Need more help?
InkBridge Networks has been at the forefront of network security for over two decades, tackling complex challenges across various protocols and infrastructures. Our team of seasoned experts has encountered and solved nearly every conceivable network security issue. If you're looking for insights from the architects behind some of the internet's most foundational authentication systems, you can request a quote for network security solutions here.
Related Articles
Three Reasons to Protect Your Network Against BlastRADIUS
While the flaw in the RADIUS protocol has existed for a long time, the BlastRADIUS exploit elevates this threat. An enterprise data security team may choose to deprioritize this issue, but 25 years of experience tells me that is not the best option. There’s no value in leaving known security issues unresolved.
How to set up a wireless RADIUS server for secure Wi-Fi authentication
When setting up a Wi-Fi network at home, you typically set up an SSID and password, accept the defaults for any other options, and be done with it. (In some cases, these are done for you by your service provider — you don’t even have to think.) You share the password with family and visitors, and everyone is happy.