David Taylor
July 12, 2000
** Archived / No Longer Maintained **
Introduction
This document details the testing methodology and results of security
testing conducted against Cisco’s VLAN implementation. The results
presented were gathered entirely from this testing. The applicability
of the results to other Cisco switch models, or other vendors’ products
is limited.
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.
Equipment
The following equipment and software was used during testing.
- 2 x Cisco 2924 Ethernet switches. Each with 24 x 10/100 UTP
- 2 x Generic PCs. Each with one 10 Mbit ethernet NIC.
- 1 x UTP crossover cable for trunking
- 2 x UTP cables for PC connectivity
- Switch console cable and PC adaptors
- Windows NT operating system on both PCs
- Network Associates’ Sniffer Pro v.2.0.01
Preparation
The switches were both prepared
with a similar configuration. Ports 1-8 were assigned to VLAN 1. Ports
9-16 were assigned to VLAN 2. Ports 17-23 were assigned to VLAN 3. Port
24 was designated as an 802.1q trunk port.
A sample switch configuration can be found in Appendix A.
The two PCs were configured with IP addresses on the same C
class subnet. This is largely irrelevant, due to the VLAN’ing being
implemented at OSI layer 2, but it did remove the ICMP net unreachables
and other errors that would otherwise have been experienced during the
testing.
Methodology
Sample frame capture
The two PCs were attached to the same VLAN of one of the
switches. An ICMP echo (ping) packet was sent from PC 1 to PC 2. This
was captured with Sniffer Pro on PC 2 and the packet was viewed in raw
hex. This packet was recorded for further use in testing.
The packet generation component of Sniffer Pro was started on
PC 1 and the packet data captured above was entered into the tool. It
is important to note that the packet generation tool in Sniffer Pro
takes care of the ethernet preamble and frame check sequence.
When the data was fully entered, the constructed packet was
sent from PC 1 to PC 2, and was captured on PC 2 to ensure that it was
correctly identified.
Insertion of 802.1q tag
Next, PC 2 was shifted to port 24 on switch 1 (the trunk port)
and the sniffer software was started on this machine. PC 1 was left on
a VLAN 1 port of the same switch. From the command prompt on PC 1, a
non-existent IP address was pinged. As this non-existent IP address did
not have an entry in PC 1 ARP table, the machine broadcast an ARP
lookup and this lookup was captured on PC 2. As PC 2 was listening on a
trunk port, it received the ARP lookup in 802.1q format, containing the
4 byte 802.1q tag. This process was repeated, with PC 1 moved to a VLAN
2 port and from these two captures, the format of the 802.1q tag was
found to be "81 00 0n nn", where nnn is the VLAN number.
For example, frames on VLAN 1 would have a tag of "81 00 00 01", frames on VLAN 2 would have a tag of "81 00 00 02".
The 802.1q tag is positioned directly after the source MAC
address of the frame and before any of the IP header information.
Taking into account this frame format and placement information, an
802.1q tag was inserted into the ethernet frame that was generated in
the previous section.
802.1q Frames into non-trunk ports
For the next test, PC 2 was moved to a VLAN 1 port on the
second switch. PC 1 was moved to a VLAN 1 port on the first switch. The
trunk cable between the two switches was reconnected.
The 802.1q frame generated in Sniffer Pro was sent from PC 1
and was received by PC 2 as a plain ICMP echo ethernet frame, without
the 802.1q tag. This test was repeated with both PCs on VLANs 2 and 3
also. In each case, the handcrafted frame was delivered to the
destination machine.
| Src Switch |
Dst Switch |
Src VLAN |
Dst VLAN |
Tag ID |
Success? |
| 1 |
2 |
1 |
1 |
1 |
yes |
| 1 |
2 |
2 |
2 |
2 |
yes |
| 1 |
2 |
3 |
3 |
3 |
yes |
Hopping VLANs
For the next test, the PCs were connected to different VLANs on
each of the switches and an attempt was made to get the generated frame
to ‘hop’ from one VLAN to the other. Various VLAN ID’s were used in an
effort to cover as many combinations as possible. Additionally,
attempts were made to get frames to hop VLAN boundaries within the same
physical switch. The following results were collected.
Different Switches
| Src VLAN |
Dst VLAN |
Tag ID |
Success? |
| 1 |
1 |
1 |
yes |
| 1 |
1 |
2 |
no |
| 1 |
1 |
3 |
no |
| 1 |
2 |
1 |
no |
| 1 |
2 |
2 |
yes |
| 1 |
2 |
3 |
no |
| 1 |
3 |
1 |
no |
| 1 |
3 |
2 |
no |
| 1 |
3 |
3 |
yes |
| 2 |
2 |
1 |
yes |
| 2 |
2 |
2 |
yes |
| 2 |
2 |
3 |
yes |
| 2 |
3 |
1 |
no |
| 2 |
3 |
2 |
no |
| 2 |
3 |
3 |
no |
| 3 |
3 |
1 |
yes |
| 3 |
3 |
2 |
yes |
| 3 |
3 |
3 |
yes |
Same Switch
| Src VLAN |
Dst VLAN |
Tag ID |
Success? |
| 1 |
1 |
1 |
yes |
| 1 |
1 |
2 |
yes |
| 1 |
1 |
3 |
yes |
| 1 |
2 |
1 |
no |
| 1 |
2 |
2 |
no |
| 1 |
2 |
3 |
no |
| 1 |
3 |
1 |
no |
| 1 |
3 |
2 |
no |
| 1 |
3 |
3 |
no |
| 2 |
2 |
1 |
yes |
| 2 |
2 |
2 |
yes |
| 2 |
2 |
3 |
yes |
| 2 |
3 |
1 |
no |
| 2 |
3 |
2 |
no |
| 2 |
3 |
3 |
no |
| 3 |
3 |
1 |
yes |
| 3 |
3 |
2 |
yes |
| 3 |
3 |
3 |
yes |
The two combinations of note are in the first table (different
switches) where traffic was sent from VLAN 1 to VLAN 2, and from VLAN 1
to VLAN 3.
Native VLAN of trunk port
Following the previous test, prolonged discussions took place
with the switch vendor to discuss the implications of the results
above. After consultation with their developers it was concluded that
the traffic from VLAN 1 was allowed to hop to other VLANs because the
trunk port was also set (implicitly) to native VLAN 1.
They suggested that by changing the native VLAN of the trunk
port the VLAN hopping could be eliminated. This was tested and was
found to be true. The results are shown below. In each case, the tag
VLAN ID was set to the destination VLAN (This was found to be the most
likely to succeed in preceding tests).
| Src VLAN |
Dst VLAN |
Native Trunk VLAN |
Success? |
| 1 |
2 |
1 |
yes |
| 1 |
2 |
!1 |
no |
| 2 |
3 |
2 |
yes |
| 2 |
3 |
!2 |
no |
Implications
- In a default configuration it is possible to inject 802.1q frames
into non-trunk ports on a switch and have these frames delivered to the
destination.
- It is possible to get 802.1q frames to hop from one VLAN to another
if the frames are injected into a switch port belonging to the native
VLAN of the trunk port. It is also necessary for the source and
destination ethernet devices to be on different switches.
This vulnerability could be exploited if the following conditions were met:
- The attacker has access to a switch port on the same VLAN as the native VLAN of the trunk port.
- The target machine is on a different switch in the same trunk group.
- The attacker knows the MAC address of the target machine.
- Some layer 3 device exists to provide a connection from the target VLAN back to the source VLAN.
Unconfirmed Findings
In our discussions with Cisco they stated that this issue was present
in all of their VLAN switches and all of the competitors switches that
they tried. This is assumed to include Nortel and 3Com devices.
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.
References
Cisco Systems. "Cisco IOS Commands." Catalyst 2900 Series XL Command Reference. Dec. 1998. URL:
http://cco.cisco.com/univercd/cc/td/doc/product/lan/c2900xl/c2900sa4/sa4cr/macrcli.htm (12 Jul. 2000).
Interworking Task Group of IEEE 802.1. "Tagged Frame Format."
Draft Standard P802.1Q/D9 IEEE Standards for Local and Metropolitan
Area Networks: Virtual Bridged Local Area Networks. 20 Feb. 1998. URL: http://www.ieee802.org/1/mirror/8021/q-drafts/d9/q-d9.pdf (12 Jul. 2000).
Network Associates Technology, Inc. "Getting Started Guide." Sniffer
Pro. 23 Dec. 1999. Location: Sniffer Pro v3.5 CD from Network
Associates Technology, Inc.
Appendix A
Sample switch configuration:
switch1#show conf
Using 1559 out of 32768 bytes
!
version 11.2
no service pad
no service udp-small-servers
no service tcp-small-servers
!
hostname switch1
!
enable secret 5 $1$Qv8m$zgc7W6iaRNRHEvKodVLnG.
!
!
no ip domain-lookup
!
interface VLAN1
ip address 10.0.0.1 255.0.0.0
no ip route-cache
!
interface FastEthernet0/1
!
interface FastEthernet0/2
!
interface FastEthernet0/3
!
interface FastEthernet0/4
!
interface FastEthernet0/5
!
interface FastEthernet0/6
!
interface FastEthernet0/7
!
interface FastEthernet0/8
!
interface FastEthernet0/9
switchport access vlan 2
!
interface FastEthernet0/10
switchport access vlan 2
!
interface FastEthernet0/11
switchport access vlan 2
!
interface FastEthernet0/12
switchport access vlan 2
!
interface FastEthernet0/13
switchport access vlan 2
!
interface FastEthernet0/14
switchport access vlan 2
!
interface FastEthernet0/15
switchport access vlan 2
!
interface FastEthernet0/16
switchport access vlan 2
!
interface FastEthernet0/17
switchport access vlan 3
!
interface FastEthernet0/18
switchport access vlan 3
!
interface FastEthernet0/19
switchport access vlan 3
!
interface FastEthernet0/20
switchport access vlan 3
!
interface FastEthernet0/21
switchport access vlan 3
!
interface FastEthernet0/22
switchport access vlan 3
!
interface FastEthernet0/23
switchport access vlan 3
!
interface FastEthernet0/24
switchport trunk encapsulation dot1q
switchport multi vlan 1-3
switchport mode trunk
!
interface FastEthernet2/1
!
interface FastEthernet2/2
!
!
line con 0
stopbits 1
line vty 0 4
password cisco
login
line vty 5 9
login
!
end
|
