Rogue AP Prevention: Duping (802)Dot1X Access Control

Rogue AP Prevention: Duping (802)Dot1X Access Control

By CWNP On 08/19/2009 - 90 Comments

“You can't solve social problems with software” – Marcus Ranum

We have covered two sources of WiFi threats in my previous blog posts – Rogue AP and Client mis-configurations. It has been encouraging to see quality comments from readers – some of them have pointed out why 802.1X is the “preferred” way to mitigate the Rogue AP problem. In this post, we will dig a little bit deeper into this. IEEE 802.1X port-based access control provides an authentication mechanism for devices wishing to communicate via a port (e.g., a LAN port). If the authentication fails, it disallows further communication via the port. 802.1X is a simple form of Network Access Control (NAC) solution – a generalized NAC can provide additional functionality such as fine-grained access control, identity management, access management, and quarantining non-compliant clients (e.g., ones without proper anti-virus protection).

I think that 802.1X is a good first step in securing your network from Rogue APs. It does provide some control on the relatively deterministic part of the problem – the wire. However, as I had hinted in my earlier post, I believe that 802.1X (or even a generalized NAC, for that matter) alone is not sufficient for mitigating Rogue APs. Here are my reasons:

 

1. Inside Threats According to a recent survey, concern over inside threats is on the rise. Inside attacks can originate from a well-meaning employee (due to ignorance) or from a malicious employee (with some serious intent). Following is an example of an inside attack that can defeat 802.1X rogue AP prevention. Let us assume that one of your employees wishes to connect a Rogue AP to 802.1X-enabled Ethernet port. Here are two ways in which he or she can succeed with it.
1. Configure Rogue AP as the 802.1X supplicant: Your employee can configure the Rogue AP with necessary credentials to authenticate itself to the 802.1X infrastructure as a supplicant. Once the AP authenticates to the 802.1X framework, he can use it to access your enterprise over the air. Even if you combine 802.1X with MAC filters as suggested by some folks, it is no big deal. Many of the available APs do provide an option to change their wired side MAC addresses. By changing the MAC address of the AP to that of an allowed MAC (e.g., Ethernet MAC of an enterprise desktop), the employee can still succeed with the wireless access. If this AP happens to be “open” (by ignorance or on purpose), an attacker sitting in the parking lot can sniff the communication and also gain enterprise access via this AP. 
2. Hide Rogue AP behind an Ethernet Hub: Your employee can connect an Ethernet hub to one of your 802.1X-enabled ports. He can use a port in the hub to connect his Ethernet adapter. Then, he can authenticate to the 802.1X infrastructure via the hub. Once the authentication succeeds, he can connect a layer-2 bridge AP to the same hub. With this, he has effectively succeeded in connecting the AP to an already authenticated port. From this point on, he can start using this AP for accessing the enterprise network over the air. Again, combining 802.1X with MAC filters won’t help much. He can change the MAC address of his wireless adapter to that of an allowed MAC (e.g., Ethernet MAC of an enterprise desktop) and succeed with wireless access. If this is an “open” Rogue AP (by ignorance or on purpose), an attacker sitting in the parking-lot can sniff the communication and gain enterprise access via this AP. Note that, in this case, the AP need not be capable of 802.1X at all. Further, this AP can be completely hidden from the rest of your wired security infrastructure – a bridge AP simply relays packets and need not even have an IP address.

Thus, in the above cases, 802.1X (and to a good extent, a generalized NAC solution) can be helpless in preventing the Rogue AP. The above attacks extend the 802.1X MITM attack originally described by Steve Riley from Microsoft.  

2. Coverage Holes Due to several factors, it may not be possible to enable 802.1X authentication on all ports in your enterprise.

1. Certain legacy devices such as network switches, desktops, network printers, and scanners may not support it.
2. 802.1X does not get along well with certain products from Microsoft. Windows XP has major issues when the VLAN/IP address changes after 802.1X user validation. As acknowledged by Microsoft, XP simply cannot support dynamic VLAN switching. Apparently, fixing this issue (which involves a weird interaction between the .1X authenticator process and Netlogon process) requires a major change. Hence, Microsoft advises that the fix is only available in Vista. Similarly, Windows PE does not support 802.1X and hence, enterprises using Win PE for remote boot may not be able to enable this feature. 
3. If guest access is supported on some ports, logistical challenges may prevent the use of 802.1X on such ports.
4. There is a significant operational expenditure in ensuring correct operation of 802.1X on all ports. It can increase the number of IT support calls.  

For these reasons, an enterprise can deliberately choose NOT to implement 802.1X either completely or partially. This can leave gaping holes for Rogue APs.

 

Please note that I am not against the use of 802.1X or NAC to try to contain the Rogue AP problem. As I have mentioned earlier, it is definitely a good first step. We do need to be aware of its limitations when applied to a problem that it was not originally designed for! Hence, based on your risk analysis, you can augment it with wireless scanning for rogue AP detection and prevention. This can add another layer of protection to your enterprise security. Last, but not the least, educating network users about potential security issues can go a long way in solving such security issues. I look forward to hear your views.

Thanks,

Gopi

In the interest of full disclosure, the author works for a WIPS vendor. 

Tagged with: gopi

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.