::: d q n e t w o r k s - VLAN-Hopping :::
dq networks


There seems to be a certain amount of FUD around about the security of VLANs for traffic-segregation. Some members of the information-security community will tell you that VLANs are not secure and cannot safely be used for traffic-segregation. When asked to elaborate they will respond with vague, hand-waving arguments along the lines that it is possible to get traffic to "hop" between VLANs as if no boundaries existed at all and they will tell you that they have seen this happen.

If this was true it would be a very serious matter indeed. Increasingly we live in a world dominated by Ethernet. It is almost universal on enterprise LANs and is fast becoming the medium of choice for carriers also and both camps make extensive use of 802.1q to segregate traffic. As adoption of Ethernet and 802.1q by carriers becomes more prevalant it would be very worrying if VLANs could easily be hopped.

So lets take a look. Based on a quick Google "poll", at least some of the fear seems to stem from the "802.1q and ISL Tagging Attack" section in this Cisco white paper. Sean Convery of Cisco gave this excellent presentation at the Black Hat USA 2002 conference which goes into much more detail. Both of these propose two mechanisms by which VLANs could potentially be hopped:-

Let's examine each of these in turn.

Trunk Autoconfiguration

By default, when a switch port comes up a Cisco switch will use DTP to try to determine automatically whether the port should operate as a trunk port or as a plain old access port. Normally, end-hosts will not respond to DTP configuration packets and therefore the ports they are connected to will operate as regular access ports. If, however, an attacker has some way to inject DTP packets (such as Mausezahn or Yersinia, for example), he can (relatively) easily negotiate with the switch for his port to act as an 802.1q trunk. Having done so the attacker has full access to all VLANs (unless some VLANs are pruned off his interface but if the network admin doesn't have enough sense to disable DTP autonegotation it is unlikely he will think to prune VLANs either !): all he needs to do is apply appropriate 802.1q tags.

Let's see it in action. We start off with a very basic switch configuration:-

Switch#show running-config interface fastEthernet 0/1 Building configuration... Current configuration : 33 bytes ! interface FastEthernet0/1 end

There's nothing there that will scare the children. There is a Linux box connected to that port. As you would expect, it is operating as an access port:-

Switch#show interfaces trunk Switch#

Now I run Yersinia and tell it to use DTP to negotiate trunking on the port:-

[root@chipmunk src]# ./yersinia dtp -attack 1 -interface eth1 <*> Starting NONDOS attack enabling trunking... <*> Press any key to stop the attack <*>

On the switch I see the interface bounce. When I check the status of my trunks again, magically I have a new one:-

00:16:41: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down 00:16:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up Switch#show interfaces trunk Port Mode Encapsulation Status Native vlan Fa0/1 desirable 802.1q trunking 1 Port Vlans allowed on trunk Fa0/1 1-4094 Port Vlans allowed and active in management domain Fa0/1 1-4,10-11,20,26,30-33,123,999 Port Vlans in spanning tree forwarding state and not pruned Fa0/1 1-4,10-11,20,26,30-33,123,999 Switch#

Sure enough, if I inject tagged packets into the newly-created trunk (I used Mausezahn for this), 30 seconds later (after Spanning Tree has gone through its "listening" and "learning" phases) the switch happily accepts them

This form of attack is pretty easy to defend against: all end-user ports should have DTP autonegotiation disabled. In my view all ports should have DTP autonegotiation disabled. If you want a port to be a trunk, explicitly set it to be a trunk. Really DTP shouldn't exist at all and it certainly shouldn't be enabled by default.


This form of attack is a little more subtle and is much less well described. The cynic in me will speculate about why this is a little later ;-). The idea is that if an attacker is connected to an access port which is in the 802.1q native VLAN (1, by default), that he can cause traffic to hop VLANs by injecting double-tagged packets. Consider this network configuration:

The theory is that the attacker can inject double-tagged packets. The switch will strip off only the first tag and will fail to "notice" the second tag. When the packet is transmitted to another switch over an 802.1q trunk, no VLAN tag is applied because the packet belongs to a VLAN which is the native VLAN for the trunk (because the access port on which the packet was received is a member of the native VLAN). The packet reaches the other switch which sees the remaining VLAN tag (i.e. the second tag which the attacker applied) and will forward the packet on the VLAN specified in that tag. Voila...the attacker has successfully caused a packet to hop into a different VLAN.

I did a little experimentation and it turns out that this attack does work. The trick is that the "outer" tag which the attacker applies must identify the packet as belonging to the attacker's VLAN (=the 802.1q native VLAN). In that case, the switch will accept the packet, even though it is arriving on an access port. The first tag is stripped off but the second tag is unaffected. When the packet is transmitted on the 802.1q trunk, no tag is applied because the packet belongs to the native VLAN. This means that when that packets reaches another switch the second tag applied by the attacker is still visible and this causes the second switch to place the packet in the wrong VLAN.

According to the Cisco white paper:-

This scenario is to be considered a misconfiguration, since the 802.1Q standard does not necessarily force the users to use the native VLAN in these cases.

This is a poor attempt to cloud the true cause of this vulnerability and it is nonesense. The reason this attack succeeds is because the switch doesn't discard tagged packets received on an access port. If the switch simply discarded all 802.1q packets received on access ports then this problem wouldn't arise.

In fairness to Cisco, it looks like they are not alone. I happened to have a Dell PowerConnect switch sitting on a shelf which exhibits exactly the same behaviour.

So how do you defend against this weakness ? Cisco's recommendation is:-

As a matter of fact, the proper configuration that should always be used is to clear the native VLAN from all 802.1Q trunks (alternatively, setting them to 802.1q-all-tagged mode achieves the exact same result). In cases where the native VLAN cannot be cleared, then always pick an unused VLAN as native VLAN of all the trunks; don't use this VLAN for any other purpose. Protocols like STP, DTP, and UDLD should be the only rightful users of the native VLAN and their traffic should be completely isolated from any data packets.

The reference to "802.1q-all-tagged mode" is a little disingenuous because Cisco switches don't support such a mode (as far as I know). So the correct solution is to

With these simple precautions VLANs provide the same level of traffic-separation as MPLS, Frame Relay, or ATM. It is intuitively obvious that it should: all of these work by tagging packets with an identifier which defines their "membership". Whether that tag is an MPLS label, a Frame Relay DLCI, an ATM VPI/VCI or an 802.1q VLAN identifier is only a matter of sematics...all of them work in exactly the same way and it really doesn't make any sense to say that any of them are inherently more or less secure than any other. So there.

References & Further Reading