To Bugtraq, We have recently conducted some testing into the security of the implementation of VLANs on a pair of Cisco Catalyst 2900 series switches and we feel that the results of this testing might be of some value to the readers. Testing basically involved injecting 802.1q frames with forged VLAN identifiers into the switch in an attempt to get the frame to jump VLANs. A brief background is included below for those that might not be too familiar with VLANs. Others should skip to the end for the results. Background ========== Virtual LAN (VLAN) technology is used to create logically separate LANs on the same physical switch. Each port of the switch is assigned to a VLAN. In the case of the Cisco Catalyst, VLAN'ing is done at layer 2 of the OSI network model, which means that a layer 3 device (router) is required to get traffic between VLANs (possibly a filtering device). In addition to the above, VLANs may be extended beyond a single switch through the use of trunking between the switches. The trunk allows VLANs to exist on multiple switches. To preserve VLAN information across the trunk, the ethernet frame is 'wrapped' in a trunking protocol. Cisco have their own proprietary trunking protocol, but they also support the emerging 802.1q standard - we used 802.1q trunking in these tests. Basically, 802.1q adds a tag to the ethernet frame that specifies the VLAN that the frame belongs to. Thus, when it is transported between switches over the trunk, it is possible for the receiving switch to send the frame to the correct VLAN. In Cisco's implementation of 802.1q the tag is four bytes long and has the format "0x 80 00 0n nn" where nnn is the VLAN identifier. The tag is inserted into the ethernet frame immediately after the source MAC address. So, an ethernet frame entering switch 1 on a port that belongs to VLAN 4 has the tag "80 00 00 04" inserted. The 802.1q frame traverses the switch trunk and the tag is stripped from the frame before the frame leaves the destination switch port. For more information on 802.1q - http://grouper.ieee.org/groups/802/1/vlan.html During our tests we used the packet generation tool of Network Associates' Sniffer Pro v 2 to generate 802.1q frames with modified VLAN identifiers in an attempt to get frames to hops VLANs without the intervention of a layer 3 device. Findings ======== We found that under specific conditions it was possible to inject frames into one VLAN and have them 'hop' to a different VLAN. This is a serious concern if the VLAN mechanism is being used to maintain a security gradient between two network segments. This has been discussed with Cisco and we believe that it is an issue with the 802.1q specification rather than an implementation issue. The trunk port, along with all the other ports, must be assigned to a VLAN. If some non-trunk ports on the switch share the same VLAN as the trunk port, then it is possible to inject modified 802.1q frames into these non-trunk ports, and have the frames hop to other VLANs on another switch. eg. Switch 1 has ports 1-12 on VLAN 1 Switch 1 has ports 13-23 on VLAN 2 Switch 1 has port 24 configured as an 802.1q trunk (VLAN 1) Switch 2 has ports 1-12 on VLAN 1 Switch 2 has ports 13-23 on VLAN 2 Switch 2 has port 24 configured as an 802.1q trunk (VLAN 1) Machine 1 is on port 1, switch 1. Machine 2 is on port 13, switch 2. We can send 802.1q frames with the following details... Source MAC = Machine 1 Destination MAC = Machine 2 VLAN ID = VLAN 2 ...from machine 1 and they will arrive at machine 2. This will only occur if the trunk port belongs to the same VLAN as machine 1. * We tried this only for the trunk belonging to VLAN 1. We expect that similar results would be achieve if machine 1 and the trunk port shared VLAN 3, 4, ... Implications ============ This is a problem if the following conditions are met: 1. The attacker has access to a switch port on the same VLAN as the trunk. 2. The target machine is on a different switch. 3. The attacker knows the MAC address of the target machine. In a real-life scenario, there may also be a requirement for some layer 3 device to provide a connection from VLAN 2 back to VLAN 1. Recommendations =============== Try not to use VLANs as a mechanism for enforcing security policy. They are great for segmenting networks, reducing broadcasts and collisions and so forth, but not as a security tool. If you MUST use them in a security context, ensure that the trunking ports have a unique native VLAN number. Final Notes =========== Thanks to those at Cisco who assisted in the handling of this issue. The two switches used for testing were WS-C2924M-XL's. They were both running 11.2(8)SA5. Additional information on test configuration will be made available on request. Regards, Dave Taylor (david.taylorat_private) Steve Schupp (steve.schuppat_private)
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:01:07 PDT