Making a unidirectional double tagging VLAN hopping attack bidirectional

A network engineer recently asked me why VLAN hopping via a double tagging attack is considered dangerous – after all, the attacker would be able to send traffic into another VLAN, but no response would be coming back. In other words, the traffic would be unidirectional, so the practical exploitability should be pretty limited.

I explained to him how this unidirectional attack can indeed be converted into a bidirectional one and he agreed that this indeed makes it practically exploitable. Since the person who asked me was a seasoned networking engineer, I thought it might be worthwhile to share the explanation also here.

First, let’s see why VLAN double tagging is considered a unidirectional attack in first place.

How VLAN Double Tagging works

A Virtual LAN (VLAN) is used to logically separate network devices on layer 2 via software. This means that even if the laptop for the HR department is connected with the same switch like the laptop for the finance department, they will not be able to communicate with each other, if they are assigned different VLANs. On the other hand, another workstation also belonging to the HR department but somewhere far away in another building can directly communicate with that HR laptop, because the VLAN will logically put them into the same network. Simply put: A VLAN allows to organize systems on a network independent of their physical location.

This logical organization is achieved via an additional VLAN tag that can be interpreted by most switches:

Ethernet HeaderVLAN Tag (ID=10)Data
Tagged frame with ID of native VLAN

Now, I said “most switches”. Some network devices do not understand VLAN tags and for them there is backward compatibility in the form of a untagged “native VLAN”. If the VLAN tag (in our example ID=10) equals the native VLAN of the trunk port, the first switch to which the attacker sends that frame will remove the tag: By definition, a native VLAN is the one without tag, so the tag is removed, no retagging happens and the switch forwards the frame to all switches that belong to the native VLAN (here ID=10).

The problem is that the switch will not examine at all the remaining fields in the packet. So if an attacker manipulates a packet in such a way that a second VLAN tag is inserted right behind the first one…

Ethernet HeaderVLAN Tag (ID=10)VLAN Tag (ID=20)Data
Double-tagged frame

… the first receiving switch will only see that the (first) VLAN tag equals ID=10 and therefore – in this example – equals the native VLAN. So it removes the first VLAN tag and sends it to the VLAN ID=10 switches:

Ethernet HeaderVLAN Tag (ID=20)Data

The receiving switch(es) switch will perceive this frame as one that is tagged for VLAN 20 and forward it accordingly. This means, the attacker was able to send a packet into a VLAN which might not have been allowed by the initial switch and despite any layer 3 firewall rules.

The reason why this attack is considered unidirectional is that if a receiving system would respond, all return traffic would be tagged with VLAN ID=20 and never reach the attacker’s machine.

Bidirectional Attack

Being unidirectional in nature, with a VLAN double tagging technique the attacker has limited options on what to do – denial of service or smoke screen might still be possible, but laterally moving forward or exfiltrating data will not work.

However, there are options how this attack can be transformed in such a way that bidirectional traffic is possible.

If the target system has some kind of vulnerability that makes it susceptible to remote code execution, the attacker can send a specifically crafted packet via the unidirectional double tagging attack and exploit the target system’s vulnerability. If the victim machine is for example allowed to establish outbound traffic to the internet, the attacker could craft a malicious packet that establishes a reverse shell on the victim machine which connects to a listening C&C server on the internet. The guys from NotSoSecure demonstrate in a blog post how Yersinia, vconfig and ysoserial can be used to exploit a vulnerability in Apache Log4j and to establish a reverse shell.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.