I love this question! It’s a risky situation many organizations are in, but don’t even realize. In fact, I might be rich if I had a dollar for every client who told me “employees aren’t allowed to use personal devices on our network” but then didn’t have any controls to prevent it, or even monitor for it.
And, even if you’re using device certificates, you could still be at risk.
A gasp! A moment of confusion. No, he probably misread it. Or did he? He clicked back again, jaw tightening as he stared at the list of endpoints connected to Wi-Fi. How is there an unmanaged iPhone on the company’s secured 802.1X network? Who had the audacity to bring a personal phone and connect it here? And why? He took a deep breath before picking up the phone.
Maybe this is a page from your life book. Or maybe it’s a page you just haven’t reached yet, but it’s probably there, waiting for you.
The Nickel Tour Of 802.1X And EAP
Without going down the rabbit hole of IEEE 802.1X port security, EAP authentication, and RADIUS, here’s the down-and-dirty of it all. The authentication on an 802.1X-secured network (Wi-Fi or wired) is negotiated between the RADIUS server and the endpoint. The account lookup for managed users and devices is most often passed to a directory such as Microsoft AD, Azure AD, Jump Cloud, or other directory of choice. Extensive Authentication Protocol (EAP) is the framework inside 802.1X that’s used for authentication. It allows for a breadth of authentication types and protocols, such as username-password combos, certificates, and tokens, via MSCHAPv2, TLS, and POTP as a few examples. Here’s a quick overview of a few popular inner authentication methods in 802.1X. As a best practice, these authentication protocols (left column) are sent in a secured tunnel (right column), but that’s a conversation for another day.
Table from Wireless Security Architecture, Wiley 2022
How a user or device can authenticate (as in, using what method and protocol) is restricted by only two parameters – the policy for allowed EAP methods configured in the RADIUS server, and the endpoint’s 802.1X EAP options. In the end, the determining factor is the RADIUS policy, which specifies the allowed EAP methods, and it’s up to the endpoint to present credentials in one of the protocols allowed by the RADIUS server for that policy.
The components of 802.1X in Wi-Fi (image from Wireless Security Architecture, Wiley 2022)
Risk Of Messy RADIUS Policies
The RADIUS server (which may be a NAC product) might be doing more than just authenticating whatever it is you’re configuring. It may be authenticating admin logins for network device management, proxying VDI logins, or firewall and SSL-VPN account lookups. So, there will likely be other policies there. And that’s the first place things may go awry. Sometimes there’s a generic policy below (in processing order) your policy, and the authentication hits that policy and RADIUS returns an “access-accept” response, allowing network authentication against an unintended policy.
For example, as in the screenshot below, it’s common to set the Network Policy to match against a media type (e.g., Wi-Fi) but it could also be looking for source IPs, such as requests from the IP address of a Wi-Fi controller. If additional Wi-Fi infrastructure were added, and this policy (Secure Wireless Policy) wasn’t updated, the incoming request would get processed against the rules below it.
For giggles, let’s say the Wi-Fi request didn’t match the “Secure Wired (Ethernet) Policy” because that’s looking for wired connections, but then it falls through to the “SSL-VPN” Policy. In our example, it could be that policy was ACME Corp’s first/original policy and it didn’t have any incoming condition restrictions to match, and it will just process any request against a user group. With a condition match misconfiguration like that, it’s possible for the Wi-Fi request to fall through to a lower policy and the server to return a “yes, authenticated” when it shouldn’t have.
There may be multiple RADIUS policies
But – there’s a different issue that’s far more prevalent than this little boo-boo. In fact, I’d say that this next issue may plague as many as 70% of organizations, putting them at risk for malicious attacks and vulnerabilities related to unauthorized devices on the network.
Top Risk In 802.1X Even With Device Certificates
Remember that the authentication methods and protocols allowed are specified by the RADIUS server. The #1 security issue I see in 802.1X misconfigurations is that the policy allows too many EAP authentication methods, some of which are not secure, or were not intended to be used.
The network can be at risk if your intention is to force authentication with device certificates, but the policy allows for both TTLS/TLS (certificates) and PEAP/MSCHAPv2 (username-password). There are myriad use cases for username-password authentication even if some devices are using certificates, so it’s not uncommon for this to be an intentional configuration. For example, the organization may be supporting authentication for managed endpoints using TLS (certificates) and allowing users on corporate managed (but not domain joined) devices to use PEAP/MSCHAPv2 (username-password).
Example of a policy that allows both certificates and username-password authentication
The result, if both certificates and username-passwords are allowed in the same policy, is that the user can connect with either. So, there’s likely nothing stopping them from bringing a personal device and connecting to the secured 802.1X network if that’s how the policy is configured.
In Microsoft NPS, the policy elements are logic OR statements, not AND statements. If you list that the USER must be a member of a USER GROUP, plus that the COMPUTER must be in a COMPUTER GROUP, that’s an OR, not an AND. It will match and accept on EITHER of those.
I’m tackling the issue of employees joining personal devices to the network with domain credentials, but there’s a much longer list of vulnerabilities introduced through misconfigurations and/or certain default configurations with other less secure EAP methods. Ask me next time how several organizations with 802.1X have failed pen tests and audits.
Now that you know the foundation of when, where, and how this happens, let’s talk about how to prevent it.
How To Prevent Users From Joining Personal Devices
There are several ways to work around or through this challenge. Here are three options; the first is the quick and easy option to triage, especially if you’re using Microsoft NPS. The second option adds the benefit of credential chaining to authenticate both user and device. And the third option helps bolster security when both certificate and username-password need to be supported.
- Write the policy for device authentication only
This solves one problem but may give you reduced visibility in other areas and prevent tools that rely on role-based access. But it is a quick and easy way to solve the problem for organizations that are relying on Microsoft NPS as the RADIUS server. Users won’t be able to authenticate with a username-password.
- Use a RADIUS server that supports credential chaining
Credential chaining lets you authenticate both the user and the device: instead of an OR you can use an AND logic statement. This can be accomplished a few ways. NAC products that allow advanced RADIUS policies will let you create logic statements, including complex nested logic with all the ANDs, ORs, and IF-THEN-ELSE you can dream up. You’ll find this in products like Cisco ISE, Aruba ClearPass, Fortinet FortiNAC, Forescout, Steel-Belted RADIUS and others. For a non-NAC route, a couple of EAP methods support credential chaining. An industry standard and most secure option is EAP-TEAP, which I happen to love.
- Break it into two policies
If your policy intentionally allows both certificates and username-passwords, then consider breaking the one policy into two, with the certificate (TLS only) policy first, and the username-password (PEAP-MSCHAPv2) second. Further restrict the username-password policy to only the users that need it, and if possible (if using a NAC product) use an advanced policy to also look for known devices, which may be via an MDM connection or other database lookup.
Tackling Security From All Sides
These are a few sure-fire ways to lock down your network authentication to ensure only authenticated devices are connecting, or at least to greatly reduce the risk of employees connecting personal devices.
Every security control should be accompanied by user awareness training, and robust monitoring, and this is no exception. Make sure your acceptable use policy addresses the use of personal devices, including a definition of personal devices, and when, where, and how they’re allowed access to corporate networks and other resources.
In addition, show a little NOC-SOC love and get together with your counterparts to ensure proper monitoring is in place to identify users that may be bringing person devices onto the network. If you have a NAC product, you can use device registration in a more structured way to support BYOD. In your network tools and in RADIUS, user accounts used across multiple devices may also be a clue.
For more on wireless security including BYOD and NAC, check out my book Wireless Security Architecture (Wiley 2022).
Join the Conversation!
Do you have you ways you’ve prevented or alerted on unauthorized personal devices? Share them in the comments!
Remember, you can ask me (almost) anything! Each month I’ll be responding to a reader’s question.
Submit your questions in any of these ways:
- My blog contact form https://securityuncorked.com/contact/
- Twitter @jjx with hashtag #AskJJX
- Mastodon @[email protected] and #AskJJX
- Packet Pushers follow-up form https://packetpushers.net/fu/
See more ways to interact and get ideas for topics at our intro blog.
