Date: Wed, 1 Sep 1999 16:44:36 +0800
From: [email protected]
To: [email protected]Subject: VLAN Security
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 ([email protected])
Steve Schupp ([email protected])
