Experimenting with VLAN hopping
Most network engineers have been told at one point or another never to use VLAN 1 for user access. The motivation behind this warning is the result of fear concerning VLAN hopping attacks, wherein an attacker can send packets with a specially-crafted 802.1Q header(s) to "hop" from one VLAN to another. This theory relies on the assumption that a switch will happily forward 802.1Q-tagged frames ingressing an access port.
We can devise a simple scenario to test this by injecting crafted packets toward an access switch port on VLAN 1 and monitoring the traffic traversing the upstream trunk. If the attack succeeds, we will see our crafted packets appear on the trunk side of the switch with the VLAN ID of our choosing.
Both switches used for the lab are Catalyst 3550s running IOS 12.2(44)SE2. FastEthernet0/11 on S1 has been configured as a static access port in VLAN 1, and FastEthernet0/13 has been configured to trunk all VLANs, with VLAN 1 as the (default) native VLAN:
interface FastEthernet0/11 switchport mode access switchport nonegotiate ! interface FastEthernet0/13 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate
We can use Scapy to craft arbitrary frames with the necessary 802.1Q headers. The following command within Scapy generates an ICMP echo request (ping) with two 802.1Q headers (VLAN 1 and VLAN 10):
Welcome to Scapy (2.0.0.5 beta) >>> sendp(Ether(dst='ff:ff:ff:ff:ff:ff', src='00:01:02:03:04:05')/Dot1Q(vlan=1)/Dot1Q(vlan=10)/ IP(dst='255.255.255.255', src='192.168.0.1')/ICMP()) . Sent 1 packets.
Monitoring eth0 with Wireshark, we can verify that the frame was sent out with two 801.Q headers with the desired VLAN IDs.
If the VLAN hopping attack theory is valid, we should observe our frame exiting S1's FastEthernet0/13 onto the trunk with an 802.1Q tag specifying VLAN 10. However, by monitoring eth1, we can observe that this frame is not switched out onto the trunk. Rather, because S1 detected an 802.1Q-tagged frame ingress on an access port, the frame was discarded. (Interestingly, though, the receipt of such a frame does not increase any interface error counters.)
I've tried crafting the malicious frame in several ways, including swapping the order of the headers and sending only one header, but none of my attempts were successful in getting a tagged frame onto the trunk in any VLAN, even the native (untagged) VLAN. Only by transmitting the frame without any 802.1Q header was it successfully switched onto the trunk (untagged). These observations suggest that VLAN hopping attacks are not effective against modern switches (or at least the Catalyst 3550 running 12.2(44)SE2), in contrast to the findings of an @stake security assessment (PDF link) performed in 2002.
Still, an engineer might wish to enable the vlan dot1q tag native feature on platforms which support it. This forces the tagging of all traffic traversing 802.1Q trunk links, including that belonging to the native VLAN. Note that it is important that this feature be enabled on both ends of a trunk.
Finally, I feel inclined to include a footnote here regarding DTP, as it will no doubt come up in the comments if I do not. Switchports configured as switchport mode dynamic are left vulnerable to the unintended formation of trunks when an attacker spoofs DTP negotiation with the switch. This is not VLAN hopping; rather, it is a simple (yet very dangerous) misconfiguration issue. Note that DTP is enabled on Cisco switch ports by default.
About the Author
Jeremy Stretch is a networking engineer and the maintainer of PacketLife.net. He currently lives in the Raleigh-Durham area of North Carolina. Although employed full-time out of necessity, his true passion lies in improving the field of network engineering around the world. You can contact him by email or follow him on Twitter.
Comments
Been awhile since I've seen this work... but back in the early 2000's if you flooded a switch with tons of traffic it would become a hub basically and forward traffic out all ports. Only some models did this.
Interesting comment on VM, wonder if we'll see this again more often with the virtualization stuff going on now.
Great article stretch! This'll def be of use to me
Given that port Fa0/11 is configured as "switchport mode access" what's the point of the "switchport nonegotiate" line? As I read the Cisco command references it seems like "nonegotiate" doesn't do anything beyond what's already been done by "mode access". (I can understand why "switchport nonegotiate" is useful alongside "switchport mode trunk" but not access.)
There is a tool that automates this process: http://voiphopper.sourceforge.net/
@jbond00747: Though there are other reasons to include switchport nonegotiate, its primary purpose here is to help clarify that the access port is not susceptible to DTP negotiation.
@Guest: VoIP Hopper is a utility to exploit the inclusion of voice VLANs on access ports (which effectively enable limited trunking). It's simply a convenient tool for encapsulating traffic into the voice VLAN which has been explicitly configured; it doesn't accomplish hopping into a VLAN which the user would otherwise be unable to access.
@jbond00747: "switchport mode access" will still use DTP (though it will not form a trunk), "switchport nonegotiate" will not use DTP at all. "switchport host" is a shortcut for access/host ports which turns off DTP negotiation, sets the port as access, and enables PortFast.
If you are running an ESX farm that has multiple VLANs assigned to the ESX host, the port on the network switch is assigned as a trunk. Has anyone looked at hoping in the virtual switch or across the trunk port on the physical switch?
Stretch,
A couple of problems with your otherwise-informative posting:
-
The reason you avoid using vlan 1 is not because of hopping attacks, but because vlan 1 is used for all the switch control plane traffic, like spanning tree protocol (STP), port aggregation protocol (PAgP), Dynamic trunking protocol (DTP), Virtual Trunking Protocol (VTP), etc. To prevent users from monitoring or potentially manipulating that traffic, it is good practice to keep your user traffic off of vlan 1.
-
In your VLAN hopping attack scenario, did you allow vlan 10 on the trunk? Since you're not running VTP (I assume) you will have to do that explicitly, otherwise the switch will not forward frames tagged with vlan 10:
interface fastEthernet 0/13 switchport trunk allowed vlan 10
Here's a reference for you and your readers: Link
thnx stretch,
i was preparing my net for change of native vlan.
now I know, that's not necessary with proper cfg of access ports.
thnx for saving time.
@ron:
-
Users can monitor and manipulate any traffic egressing an access port, regardless of what VLAN it is in; all traffic appears untagged to the host. It is only when frames must be switched onto a trunk where VLAN tags (or the lack thereof) come into play, hence the concern about VLAN hopping. However it's also worth noting that another reason for discouraging the use of VLAN 1, or any native VLAN, for that matter, is the lack of 802.1p (layer two QoS marking) support.
-
All VLANs are allowed across a trunk by default. Only when a
switchport trunk allowed vlancommand is configured is a restriction put into place.
Users can monitor and manipulate any traffic egressing an access port, regardless of what VLAN it is in; all traffic appears untagged to the host.
Yes indeed. But if the access port is on, say, vlan 5, you will not see vlan 1 (control) traffic. That is what you're trying to prevent.
All VLANs are allowed across a trunk by default. Only when a switchport trunk allowed vlan command is configured is a restriction put into place.
Did you put vlan 10 in the vlan database?
@ron:
Layer two control traffic like STP/DTP/VTP/etc. all occur between layer two endpoints; an attacker needs only to compromise his local access switch (for example, by sending STP BPDUs and pretending to be a bridge, or by using DTP to form a trunk). This is possible regardless of which VLAN the user is in.
And yes, of course. Without the VLAN in the database (or configuration, on more modern switches), no traffic within that VLAN would be passed.
an attacker needs only to compromise his local access switch (for example, by sending STP BPDUs and pretending to be a bridge, or by using DTP to form a trunk). This is possible regardless of which VLAN the user is in.
The problem with vlan 1 is that the attacker can attack all the switches, not just the one she is connected to.
The vlan hopping attack will succeed if the access port is a trunk, as it would be if IP phones were being used. The defense is to use a different vlan for the trunk native than the user native.
(P.S. thanks for forcing me to dig into this a little deeper than I normally would).
@ron: But these protocols are only sent between directly connected devices at layer two. A switch will not forward STP BPDUs, for example; rather, it accepts those it receives and generates new ones. To actually switch these types of traffic, you would need to enable Layer two protocol tunneling.
Also, if an access port is a trunk anyway, that's not much of an attack. =)
@jbond00747: according to the CCNA security book, SWITCHPORT MODE ACCESS blocks all trunking on that port.
SWITCHPORT NONEGOTIATE is for use on a port that is a trunk, but doesn't want to participate in dynamic trunking
Also here is an interesting paper from @stake on Cisco layer 2 security.
http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/tech/stake_wp.pdf
It's from 2002 but as we all know, network operating systems often go unpatched due to down time concerns.
This article piqued my interest so I had to try it myself. Using a couple 2950s running 12.1(22)EA9 I was able to successfully pull off this attack (I used yersinia 'cause I'm lazy). Using 3550s and 12.2(44)SE2 did not work. I guess the newer IOS is a bit smarter in it's handling of tagged packets.
If you are interesting in other kind of layer 2 attacks, I'll suggest you to look at http://www.yersinia.net/ and give it a try. have a nice day
The conclusion is that the IOS become smarter ,Haha.
One thing I discovered with using wireshark on a laptop was that the laptop NIC driver was actually removing the VLAN tag from the frame before the data got to wireshark.
Their was a windows registry setting that needed to be set to pass the frame through w/o altering the data...
The fidelity of the recorded data is important and may lead to false conclusions.
I wrote about this two years ago and agree that VLAN hopping is a myth. http://thinkingproblemmanagement.blogspot.com/2008/10/dmz-hopping-gobbledygook.html Unluckily it is a bone of contention between Ivan and myself!
RE:erics (guest)
Yes you are right. I have observed that with certain NIC you are actually able to pass packets with the dot1q tags intact. Or in some cases, a Registry Edit or a firmware flash of the NIC will also obtain the same result.
hello stretch!
cisco switches drop all frames with ethertype 0x8100 on access ports, with exceptions of frames belonging to voice vlan and 802.1p.
please can you try following scenario: first 802.1q tag contains vlan id 0 (802.1p tag), second 802.1q tag contains vlan id 10?
You set the port as a static access port, thats why the frame was dropped. An "out of the box" switch by default will negotiate trunking on all ports...
Also, it is NOT a myth. It is covered in CCNA Security by Cisco Press
Also, it is NOT a myth. It is covered in CCNA Security by Cisco Press
Are those two statements supposed to be related? Try the experiment yourself if you don't believe the article.
thanks for the article Stretch
i have question what's meaning this steps
Always use dedicated VLAN IDs for all trunk ports.
Do not use the user native VLAN as the trunk port native VLAN.
can you say which command for this step ))
Thanks
any one ?
Cisco SWEARS disabling DTP prevents VLAN hopping, along with placing unused ports in an unused VLAN and implementing port security (but not all at the same time, changes from question to question)...Gotta love 'dem cert exams!
I'm taking my CCNP SWITCH tomorrow for the 2nd time, not looking forward to it in the least bit...
Regarding the article, nice! You've inspired me to go back on Linux for a while to play with all these pentesting tools ^^
What about an interface in trunk mode being used as the point of entry, similar to what obtains when an IP phone and PC are connected to the same switch port. Wouldn't VLAN hopping be possible here?
@jahmikes: As mentioned in earlier comments, if the port is already a trunk, it's not an attack at all; that's how trunks work. Access ports should always be configured as static access ports.
@jahmikes:
You could simply force only "allowed" vlans on those ports as well which would restrict the traffic that goes across.
Further to my previous comment (maybe not yet published), someone claims to have actually demonstrated the VLAN-hopping attack involving the Voice VLAN ... and on a 3570 at that.
Despairing of my original comment being published, I will post a fresh one. As per the experiment in this blog post, Cisco seem to have gotten wise to ingress of dot1q-tagged frames on an access port. But how wise? Stretch says "well, if you've got a trunk port in an access location, you're hosed anyhow". But "switchport voice vlan 100" - the recommended voice configuration, is just such a trunk. It is supposed to be a 'limited' trunk, but is it vulnerable to VLAN hopping?
If ports configured with a 'voice VLAN' merely assert that tagged frames are for the voice VLAN, but fail to check for multi-tagging (up to the diameter of the broadcast domain) then then a VLAN-hopping attack might still be possible.
Really, a more general anti-VLAN-hopping precaution would be to ensure that if an egress trunk had a native VLAN and it was necessary to de-tag, then make sure that the de-tagged frame no longer begins with a tag. If it does, drop the frame. That would also catch double-tagged packets arriving on trunks where an upstream switch blindly forwarded a double-tagged frame.
But it doesn't seem like that's how they do it.
Cool stuff, Stretch. I always theorized that setting a port to access mode would defeat the VLAN hopping issue you discussed (and that we've all heard). My next thought, though, is whether this type of attack could work on a VM server of some kind since tagging may have to be enabled on the uplink to the host/chassis.