VLAN Hopping

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Dear René,

Thank you very much for this great job !

I have a couple of questions about double tagging :

To be effective and exploited, this attack means that the attacker frame is not already in a port with a vlan other than the native vlan ?

In this sentence : “When the switch receives the frame, it will remove the first 802.1Q tag and forwards the frame with the second 802.1Q tag on its trunk interface(s).” Why the switch remove the first tag when this one " enter " the trunk ? Removing tags occurs when the frame exit the trunk for being delivered to the destination host ? Isn’t it ?

If it is a " native vlan " does the switch remove the tag at the entry of the trunk ? We use the native vlan to specify untagged frames ?

To be honest, not very clear for me :slight_smile:

Prince

3

Hi Prince,

Normally when a switch receives a tagged frame, it will remove the tag and then forwards it on access interfaces or other trunks. If it is sent on other trunk interfaces, then it will be tagged again.

With VLAN hopping, the VLAN of the attacker has to be the same as the native VLAN on the trunk. Here’s what happens:

  1. The attacker sends a double tagged frame, an inner (20) and outer (1) VLAN tag. The outer tag matches the native VLAN of the trunk.
  2. The switch receives the double tagged frame, looks at the outer VLAN (1) tag and removes it.
  3. The switch forwards the frame on all interfaces that belong to the native VLAN (1), this includes trunks.
  4. The frame (with one tag left) is forwarded to the other switch, which looks at the VLAN (2) tag and forwards it on all interfaces that belong to that VLAN 20.
Hope this helps!

Rene

1 Like
4

For sure René, it helps a lot

Thank you again for the great job! Well done!

Prince

5

Hi, Rene.

I confess that this lesson be confused, since I know frames that are received by the switch on access ports are dropped. The SW1 FastEthernet0/1 interface should be configured in trunk mode for this attack to work, correct?

6

Hi Stefanio,

I understand this can be confusing. When you read about VLAN hopping, they usually talk about interfaces in access mode that accept frames with two VLAN tags. The first tag is ignored, the second one allows you to jump from one VLAN to another.

The 3560 switch that I used didn’t like this at all…it does not accept a frame that is tagged if the interface is configured in access mode. I didn’t test it but older switches (or IOS images), or other vendors switches, might accept a double-tagged frame on an access mode interface, making VLAN hopping possible.

In my example, I had to set Fa0/1 on SW1 to trunk mode for it to accept double VLAN tags. On modern IOS switches, VLAN hopping on access mode interfaces is no longer an issue.

1 Like
7

Will the switch accept the frame if the switchport is configured with a voice vlan?

1 Like
8

Hello Zahchary

This is a good point you make. A port that is configured with a voice VLAN is an access port, but it will accept tagged frames as long as they are tagged with the configured voice VLAN ID. A switch uses CDP to communicate with Cisco IP Phones and let them know what the voice VLAN ID is. If your phones are not Cisco, you will have to know the VLAN ID and configure it manually. If you know this VLAN ID you may be able to gain unauthorized access to the voice VLAN if you connect your own switch to the network jack where the phone is plugged in. For this you will have to employ additional Layer 2 security parameters like port security.

For more info on some of these topics, take a look at the following lessons:

I hope this has been helpful!

Laz

1 Like
9

Hello,

Thank you for another interesting and well-written article. I learned a lot again!

So does the double tagging attack work if the attacker negotiates a trunk with the switch? Of course, please correct me if I’m wrong, but if the attacker can negotiate a trunk, there’s no reason for him to launch the double tagging attack if the switch spoofing attack is successful (because both achieve the same goal). However, I just want to cover all possibilities.

In other words, the optional “switchport mode access” command should be used on all access interfaces in order to disable the DTP protocol and avoid even the possibility of both of these attacks? And to be even more thorough, should the DTP protocol be disabled on trunk interfaces as well, using the “switchport nonegotiate” command?

Thank you.
Attila

10

Hello Attila

If an attacker spoofs a switch (negotiates a trunk with the switch) then they have access to all VLANs. In this case, you wouldn’t strictly call it a VLAN hopping attack but it is an attack via which an attacker gains unauthorized access to a VLAN. So yes, I would agree with you that if an attacker can negotiate a trunk, there’s no reason to attempt a double-tagging attack.

Yes, both of these are considered best practices to protect against such attacks. By using these commands on access and trunk ports respectively, you are eliminating the vulnerabilities introduced by DTP.

I hope this has been helpful!

Laz

1 Like
11

Hello, everyone.

I understand these two attack types perfectly but I still feel a little confused about the mitigation of them.

I understand that in order to prevent the attacker from forming a trunk with the switch, the switchports should either be left as shutdown or configured as static access ports manually by using the switchport mode access command if they are connected to an end-host.

What I am still a little unsure of is whether switchport mode access also mitigates the double tagging attack. So will a switch accept double-tagged frames if the port is an access port? Rene’s switch didn’t like that but what about other vendors or modern switches? Even so, it might still be the best practice to change the native VLAN to a unique number, correct?

And this double-tagging attack can only work if the frame is tagged with the ID of the native VLAN? If I am not mistaken, this attack can only work if the access port is in the same VLAN as the native VLAN, could someone please help me confirm this?

Thank you very much for your help.

Kind regards,
David

12

Hello David

Take a look at this NetworkLessons note that sheds some more light on what happens when a tagged frame arrives on an access port.

Yes, even so, it is always best practice to change the native VLAN from 1 to another value.

This attack can indeed only work if the access port is in the same VLAN as the native VLAN.

I hope this has been helpful!

Laz

13

Rene and team,
I’m curious about vlan hopping outside of the security issue here. I’ve experienced an issue when I was deploying aurba APs in a customer’s environment and the management frames were hopping vlans on their return due to the customer having different native vlans configured on the trunk links in the path of the packets. Why did this happen? And if the management traffic for the AP is on vlan 70 (for example) and we’re bridging, shouldn’t the management traffic leave the AP tagged with vlan 70 instead of having a trunk link with native vlan 70? I went back and forth with an Aruba engineer on this. I would like to better understand at a low level how packets go back and forth across trunk links with different native vlans configured. Thank you so much for this site!

14

Hello Joshua

There are several issues involved here, and it all depends upon how Aruba and other vendors deal with management traffic. If a particular VLAN, such as VLAN 70, is chosen to serve management traffic, the configuration across all the infrastructure must be appropriately “harmonized.” What I mean is, it should be configured appropriately.

  1. If management traffic is served by the native VLAN on trunks, then 70 should be configured as the native VLAN on all trunks to avoid VLAN hopping.
  2. If the management traffic is served by tagged traffic on the trunk, then there should be no issues with VLAN hopping.

It may be that you are forced to use the native VLAN for management traffic. If there’s a native VLAN mismatch on some trunk that serves that traffic, you’ll see the problem. Remember, VLAN tags exist on Ethernet frames only while traversing a trunk. The tag is added on egress and removed on ingress.

To resolve such issues, I would suggest that you always put management traffic on non-native VLANs, so that they are always tagged and no VLAN hopping can happen. However, some vendors don’t allow you to configure something like this, and this is what I suspect in your case.

Can you give us some more info about where on your topology you have trunks? Is the AP connected to a switch via a trunk link? And is it possible to configure management traffic to always use a non-native VLAN? That should resolve any issues you may have, if it is possible to configure. Let us know how you get along!

In the meantime, some NetworkLessons notes that address some of these issues that may be helpful are the following:

I hope this has been helpful!

Laz

15

Thank you for this! Love this site!