Log InYou can spend as much time as you want securing your RADIUS infrastructure and the rest of your network. But are you really secure?
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. Ouch!
This article is based on a 2016 presentation done by Arran Cudbard-Bell at NetworkShop 44 .
Wi-Fi and 802.1X
WPA (and WPA2) Enterprise use 802.1X for secure network access. In practice, this means that the when the end-user device wants to talk to an Access Point (AP), the device has to use EAP. The device sends EAP packets to the AP, which in turn sends them to a RADIUS server.
The most common EAP methods are PEAP, TTLS, and EAP-TLS. Like HTTPS, these methods use TLS and certificates in order to authenticate the parties involved.
The problem is that when you log into a web site with a browser, the address bar shows both the URL (or domain name), and a “lock” icon. 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 users name and password!”. This practice makes for poor security.
What we did
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.
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) which the user presented. Even better, the various fields in the certificate (domain name, email, telephone, etc) were taken from the real certificate which 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 fromexamplee.org, orwww.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 noticable 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.
Oh, boy, were the results disappointing.
Windows
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
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 authorize 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.
The Summary
End user systems are terrible at too many things related to EAP security. They ask the user for credentials before verifying the servers identity. They do not adequately verify the server certificate. They rely on the user to make decisions based on data which is opaque or meaningless to the user.
All of these issues result in systems which are incredibly insecure. The good news is that it is possible to fix this behavior.
The Fix
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 behavior of their supplicants, which makes life harder for everyone.
Alan DeKok (FreeRADIUS project leader and CEO of Network RADIUS) has written a draft for the IETF which summarizes these issues, and proposes a series of fixes. The end result is that 802.1X and Wi-Fi 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?
Network RADIUS is the team behind FreeRADIUS. We develop and maintain the open source product, write the documentation, moderate the FreeRADIUS mailing list, and answer questions in public forums. Our team knows FreeRADIUS inside and out.
We have also written many of the standards for RADIUS and EAP. We are actively working with the relevant standards bodies to address the issues raised here.
In addition to supporting the free, open source community, we specialize in helping clients configure, deploy, and maintain complex RADIUS infrastructure. If you’d like help from the people that wrote FreeRADIUS, contact us for a customized quote.
