The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
Experimenting with VLAN hopping
By stretch | Monday, February 22, 2010 at 2:41 a.m. UTC
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.
Posted in Security
Comments
February 22, 2010 at 3:30 a.m. UTC
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.
February 22, 2010 at 3:52 a.m. UTC
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.
February 22, 2010 at 3:54 a.m. UTC
Great article stretch! This'll def be of use to me
February 22, 2010 at 4:06 a.m. UTC
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.)
February 22, 2010 at 4:21 a.m. UTC
There is a tool that automates this process: http://voiphopper.sourceforge.net/
February 22, 2010 at 4:36 a.m. UTC
@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.
February 22, 2010 at 12:05 p.m. UTC
@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.
February 22, 2010 at 4:54 p.m. UTC
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?
February 23, 2010 at 3:11 p.m. UTC
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
February 23, 2010 at 3:17 p.m. UTC
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.
February 23, 2010 at 3:35 p.m. UTC
@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.
February 23, 2010 at 3:48 p.m. UTC
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?
February 23, 2010 at 4:17 p.m. UTC
@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.
February 23, 2010 at 4:43 p.m. UTC
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).
February 23, 2010 at 5:34 p.m. UTC
@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. =)
February 23, 2010 at 11:47 p.m. UTC
@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
February 23, 2010 at 11:55 p.m. UTC
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.
February 24, 2010 at 5:12 a.m. UTC
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.
February 24, 2010 at 10:53 a.m. UTC
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
February 26, 2010 at 7:25 a.m. UTC
The conclusion is that the IOS become smarter ,Haha.
February 27, 2010 at 12:51 a.m. UTC
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.
March 12, 2010 at 8:10 p.m. UTC
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!
March 19, 2010 at 9:43 a.m. UTC
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.
March 22, 2010 at 5:42 a.m. UTC
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?
June 11, 2010 at 9:16 p.m. UTC
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...
June 11, 2010 at 9:18 p.m. UTC
Also, it is NOT a myth. It is covered in CCNA Security by Cisco Press
January 26, 2011 at 10:22 p.m. UTC
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.
June 9, 2011 at 3:56 p.m. UTC
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
June 21, 2011 at 5:41 p.m. UTC
any one ?
August 18, 2011 at 6:22 p.m. UTC
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 ^^
March 19, 2012 at 2:21 p.m. UTC
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?
March 19, 2012 at 4:47 p.m. UTC
@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.
April 2, 2012 at 3:58 a.m. UTC
@jahmikes:
You could simply force only "allowed" vlans on those ports as well which would restrict the traffic that goes across.
July 18, 2012 at 6:10 a.m. UTC
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.
August 13, 2012 at 1:25 p.m. UTC
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.
March 10, 2015 at 10:52 p.m. UTC
Hello Stretch, Thank you for the explanation. Now i am trying to sum up all the configuration needed to mitigate this attack but i keep on getting different recommendations and i was hoping you would help explain which one is really needed and which is not: 1. For the access ports make sure to specify the access vlan: Example : interface fa1/0/1 switchport mode access switchport access vlan 100
- For the trunks:
- disable the negotiate.
- allow only vlans needed.
- specify the native vlan
- tag all native vlans
Example:
vlan dot1q tag native interface fa1/0/10 switchport trunk encap dot1q switchport mode trunk. switchport trunk native vlan 100 switchport trunk allowed-vlan 1-99, 101-4094 switchport nonegotiate
so my questions are: 1. Is it needed to have native vlan tagged in addition to the interface config as indicated above? 2. If the native VLAN is tagged, would we need to add it to the allowed VLAN list (switchport allowed-vlan 1-4094)?
Thank you in advance
August 1, 2015 at 9:25 p.m. UTC
First of all you must have two switches connected So connecting port 0/13 which is a trunk port to the second nic on your pc does not make the link between "trunk" link.
Even if you configured the interface on the second nic as trunk (if the OS on the pc is linux flavor) you should monitor the traffic on all interfaces for all the created vlans.
September 12, 2016 at 1:29 p.m. UTC
Stretch, great post. A man after my own heart trying to simplify understanding of networks.
Tested out the scenario above and found that the double tag us unnecessary. Scapy only needs the VLAN 10 tag added when sending the packet, and it'll jump vlans, and the trunk link to the other switch is not necessary.
But this is just how trunk links work, as you said in the comments.
I'm having a hard time conceiving of the case where a double tag would work. Ideally one would carry out the attack version of this by having the packet generator connected to an access port on the native VLAN(as you have in the drawing), but the switch seems to drop tagged frames arriving on access ports. Right now I'm dorking with the type field and FCS to try to get the tagged frame into the access port.
Any insight is appreciated.
Bagurdes
September 12, 2016 at 4:18 p.m. UTC
I must have been living on a different planet when I wrote what I did.....I see that you had the same results I did.
Thanks for the great insight.
-Bagurdes