0

I need to ensure that no un-authorized DEVICE gains access to a wireless LAN network.

Notice I said, "device". This means that I need to ensure that only authorized personnel can join the LAN and also that they can't use a non-authorized device.

A RADIUS WPA2-Enterpise network is set up.

My concern is that authorized individuals that have been given a device such as a phone may extract the login credentials (username and password) and or the certificate stored in their device (android phone, iphone, windows laptop, mac laptop, linux laptop).

Then with the extracted username/password and or certificate, they can join an unauthorized device to the LAN.

Is the attack as I've described possible? If so, how can I protect against it?

  • Yes, it is certainly possible, because the only identity checking mechanism is client certificate presence. Unless you defined something else that could prove that this particular device is authorized. – Crypt32 Nov 2 '17 at 5:36
  • MAC whitelisting can prevent few, but not effective against those who want to evade. Read this security.stackexchange.com/questions/129382/… – Krishna Pandey Nov 2 '17 at 6:13
  • @Crypt32 , what would be that something 'else' to provide device authentication? – user162881 Nov 2 '17 at 16:08
  • @KrishnaPandey , yes, I know MAC whitelisting does not work. That is why I don't even mention it. MAC's can be spoofed a lot easier then stealing/copying credentials from phone. – user162881 Nov 2 '17 at 16:10
  • @user162881 something that can distinguish genuine from non-genuine device. I don't know how do you do that. What makes genuine device to be genuine, not something else. That's the point you should think about. – Crypt32 Nov 2 '17 at 20:31
1

It is possible, and you cannot prevent it.

Most devices will allow administrators to backup or extract certificates, including the private key. Your perception of security is not in line with the actual, real world practice.

Someone (or some group) must authorize the devices. Typically, the technical authorization mechanism is handled as a completely separate process from the management review and approval. These processes are usually performed by two entirely different sets of people. The key element here is trust.

So how do you have any security at all?

Your only choice is to trust your administrators. In the interest of robust security, however, you always verify when you are forced to trust.

How do you verify? You can review logs from your 802.1X or RADIUS network devices for problems. Does the "same" device have an active connection in multiple places at the same time? Does the "same" device show up with many different MAC addresses when it only has one NIC?

If you have an asset tracker or a vulnerability scanner, you may detect rogue devices this way as well.

The bottom line: You should perform regular monitoring and enforcement of the security policy, or eventually things will go as badly as you fear.

What about things you can't trust?

Some devices are inherently untrustworthy. E.g., your admins might not have complete control over a personal smartphone connected to the network. In that case, it is best to put those devices on a restricted VLAN.

You should always setup monitoring, detection, and barriers between the important things and the untrustable things on your network. If you ever find that it is impossible to do so, then your organization has a serious risk that must be escalated to management for resolution.

  • 1
    Word of warning about acting on changing MAC addresses: It is extremely common for modern smart devices (laptop, phones, etc.) to offer the option to randomize MAC addresses. – Nic Hartley Jul 13 at 20:05
  • Yes, and that is something that a brief investigation would uncover. Company-owned devices can have that feature disabled, but BYOD laptops/phones really belong on restricted VLAN. For the sake of simple monitoring, it would be ideal to put all MAC-changing devices on a restricted VLAN. The alternative is that the security team learns which devices legitimately change MAC addresses, and they accept the behavior as normal (while implicitly accepting the risk that this allows unauthorized access if those particular certs are compromised). – DoubleD Jul 18 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.