VLAN Hopping

VLAN Hopping is an attack where the attacker is able to send traffic from one VLAN into another. There are two different methods to accomplish this:

• Double tags: the idea behind the attack is that the attacker  is connected to an interface in access mode with the same VLAN as the native untagged VLAN on the trunk. The attacker sends a frame with two 802.1Q tags, the “inner” VLAN tag is the VLAN that we want to reach and the “outer” VLAN tag is the native VLAN. When the switch receives the frame, it will remove the first (native VLAN) 802.1Q tag and forwards the frame with the second 802.1Q tag on its trunk interface(s). The attacker has now “jumped” from the native VLAN to the victim’s VLAN.It’s a one way trip but it could be used perhaps for a DOS attack.
• Switch spoofing: the attacker will send DTP packets and tries to negotiate a trunk with the switch, this is possible when you use the default “dynamic auto” or “dynamic desirable” switchport mode. Once you have a trunk to your computer, you will have access to all VLANs. This is basically a misconfiguration since you should never configure your interfaces to use the dynamic switchport modes.

Here’s an illustration for the double tag method:

In the picture above we have two switches, SW1 and SW2. The attacker is in VLAN 1 and our victim is in VLAN 20. Here are the configurations of the switches:

SW1#
interface FastEthernet0/11
 switchport mode access

interface FastEthernet0/24
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate

SW2#
interface FastEthernet0/2
 switchport access vlan 20
 switchport mode access

interface FastEthernet0/24
 switchport trunk encapsulation dot1q
 switchport mode trunk

As you can see above the interfaces that connect to the computers are in access mode, the attacker is in VLAN 1 while our victim is in VLAN 20. The interface between the two switches is a 802.1Q trunk.

Does the double tagging method actually work? The idea is that the switch will just accept any frames even if it’s in access mode. I tried this on a Cisco Catalyst Switch 3560 running the IP services 12.2(55)SE10 image.

To test this, I used scapy on a computer running Kali:

# scapy 
INFO: Can't import python gnuplot wrapper . Won't be able to plot.
WARNING: No route found for IPv6 destination :: (no default route?)
Welcome to Scapy (2.2.0)
>>>

Let’s craft a nice frame:

>>> sendp(Ether(dst='ff:ff:ff:ff:ff:ff', src='00:17:5a:ed:7a:f0')/Dot1Q(vlan=1)/Dot1Q(vlan=20)/ IP(dst='255.255.255.255', src='192.168.1.1')/ICMP(), iface='eth2')

Here’s what you see above:

• Source MAC address: 00:17:5a:ed:7a:f0
• Destination MAC address: broadcast
• Inner VLAN tag 20
• Outer VLAN tag 1
• Destination IP address: broadcast
• Source IP address: 192.168.1.1
• Outgoing interface: eth2

Here’s a capture of this packet in wireshark:

If everything works then my switch should accept the frame, forward it on the trunk and broadcast it in VLAN 20. My 3560 switch doesn’t like it at all though: