Building a Separate Infrastructure for Guest Access
One of my readers sent me an age-old question:
I have my current guest network built on top of my production network. The separation between guest- and corporate network is done using a VLAN – once you connect to the wireless guest network, you’re in guest VLAN that forwards your packets to a guest router and off toward the Internet.
Our security team claims that this design is not secure enough. They claim a user would be able to attach somehow to the switch and jump between VLANs, suggesting that it would be better to run guest access over a separate physical network.
Decades ago, VLAN implementations were buggy, and it was possible (using a carefully crafted stack of VLAN tags) to insert packets from one VLAN to another (see also: VLAN hopping).
I haven’t heard of VLAN hopping exploits1 in ages, and I’ve never heard of bidirectional communication enabled by VLAN hopping, but maybe inserting a single packet is good enough – the Slammer worm needed a single UDP packet to spread. Anyway, the myths of VLAN hopping (and the myths of hypervisor escapes) refuse to die.
Just to cover all bases: a layer-2 switch that crashes and loses its configuration might wake up in a state where all ports are in the native VLAN (VLAN 1), but it’s easy to mitigate that — use VLAN trunking without a native VLAN on the uplink, and while everyone might be in the same VLAN on the switch, they won’t get anywhere else.
Finally, I’m positive there are ultra-high-security environments where separate infrastructure for guest access is a must2, but I’m guessing that engineers working in those environments don’t expect to get security-related advice from a random blogger.
Anyway, how could one deal with an overzealous security team? Be polite. For example, “looking from the networking perspective, and considering industry best practices, I can’t see what you’re so worried about. Could you please help me by pointing out the actual problem in our infrastructure (after all, you’re the security experts) and we’ll fix it.”
In the ideal case, they’d hire a third party to prove you wrong, and while I would be surprised to see someone hop out of a VLAN, expect a decent pen tester to find a bunch of real-life security vulnerabilities well worth fixing. Not sure about that? Maybe you should listen to a few episodes of the Darknet Diaries podcast ;)
This feature is related to authentication (802.1X or MAC) and VLAN assignment on a port where an wireless AP is discovered. AP is discovered using "lldp.tlv.enable_system_cap.wlan_access_pt == 1".
The switch assume the AP is in a NON-tunnel mode and that he will proceed authentication and tag traffic into the proper VLAN himself. The idea is to avoid several authentication at AP and switch and speedup the process.
So the switch is not authenticating devices seen on the AP port. => authentication bypass Switch is also trusting all the VLAN tags coming from this port. => VLAN hopping
This features is enabled by default. You can still disable it. When upgrading from a previous version that doesn't support it, the configuration is converted to enable it.
I discovered it at a customer's place because they connected an AP to a unmanaged switch with an uplink to the ALE AOS6 switch. PC connected to the unmanaged switch were not getting DHCP or network access.
I connected my PC, did a wireshark and saw 802.1q trafic. I configured an 802.1q interface and got access to all VLAN on the switch.
I was able to exploit it at several customers by forging LLDP to look like an AP.
I was not able to exploit it on AOS8. While AP-mode is also enabled by default, it doesn't work the same way as in AOS6.
ALE doesn't consider it a security issue and won't change the default behavior of AOS6 as it's becoming end of life. Unfortunately, it's still used on a lot of switches.
Thanks a million for this gem. When I think I've seen everything, someone sends me another vendor stupidity that makes my day (in some sense).
However, this is not VLAN hopping, at least not the "original" data-plane SNAFU. This is unprotected control plane due to vendor stupidity. Cisco has (had?) a similar problem with VTP:
https://designclinic.ipspace.net/topic/network-device-hardening/
Finally, if I understood it correctly, this particular stupidity requires access to a physical switch port, not guest VLAN access. If someone can access a "core" (intra-network) port you have bigger problems than VLAN hopping ;)
Yeah, not exactly "dataplane VLAN hopping". Refering to your Wikipedia link, it's more "Switch/AP spoofing".
About Cisco, it's more DTP wich is vulnerable to "Switch/AP spoofing" to exploit "VLAN hopping" instead of VTP.
About AP-mode exploit condition, you just need to be connected to a port that require authentication like 802.1x or MAB with AP-mode enabled (default configuration). Most of the time, it's the kind of access port facing employees or guests. If authentication succeed, employee can access the LAN. If not, guest will access a guest VLAN with very restricted access or will not access anything.
I actually discovered the vulnerability because of a guest reporting network access issue to customer while he should had access to internet.
I have actually already reported this stupid vulnerability more than two years ago and Ialso sent the reproduction steps to ALE PSIRT. They then only implemented a fix so that you could disable the ap-mode. AOS 6.7 if i remember it correctly. Tough luck for the ones using the AP functionality though. ALE is working on making code changes to solve this and from what I have heard it will be made available even in the AOS6. But I haven't seen the code yet so it's still vapor ware.
This year i met incident on the customer wireless infra (only Cisco HW/SW AIR-OS; APs in flexconnect mode with guest WLAN locally switched). Due to bug in SW, under certain conditions APs have been losing configured guest VLAN totally & somehow assigned office VLAN to the guest WLAN bridge. Effectively guests obtained full connectivity in the internal office VLAN still being connected to the Guest SSID. It shouldnt happen ever but it did.
Often it's not the security team you need to convince, but auditors. Having a guest network -- or an outsourced OT network for building controls, or surveillance cameras etc. -- be physically completely separate makes that aspect of the job a lot easier. In short, it's easier to make fit the checkboxes for audits, and it's simple to explain to even non-technical people. From an engineering standpoint a waste of money, but from a sanity perspective sometimes worth it.
"Often it's not the security team you need to convince, but auditors" << in which case you're absolutely right, it's often more efficient to retain your sanity and waste some money on extra boxes. Fortunately I was always working with auditors who knew what they were doing.
Also, I've heard it's easier to get budget to fix the audit findings than to improve the network ;))