COMMAND
VLANs
SYSTEMS AFFECTED
Thise having VLAN
PROBLEM
Dave Taylor and Steve Schupp 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.
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 -
they 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 take a look at:
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.
Testing team 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, ...
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.
SOLUTION
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.