If the frame enters the switch on a trunk port and exits on a trunk port with native VLAN 5 then the VLAN 5 tag is removed. So then I agree that in theory you should have a frame with a VLAN 99 tag. What we need to figure out is how this is handled in the switch and on the outgoing interface.

The next that happens if the frame leaves the port is that you have the VLAN 99 tagged frame on the trunk. And what happens next is depending on if there are any trunk ports that will accept VLAN 99. And I guess the ‘hacker’ selected VLAN 99 for a reason.

/André

Yes,

this is exactly described in the CiscoPress book LAN Switch Security: What Hackers Know About Your Switches

(http://www.ciscopress.com/bookstore/product.asp?isbn=1587052563), page  72.

IMHO, your example would also work.

Generally, you could create a very sophisticated example with 4 nested 802.1Q tags, e.g.

But the security documents don't show this case because "if an attacker has a physical access to a trunk, it's easy to compromise any VLAN."

The mystery of VLAN-hopping is forwarding a frame from an access port to another access port belonging to a different VLAN.

BR,

Milan

Thanks.. Thats the same book I am reading !

Its a minor point, but in this case, the attacker has access to a trunk,

               BUT

              1. vlan 99 is NOT allowed on the trunk from attacker to Switch.

               2. However from Switch1 tro Switch2, vlan 99 is allowed.

I guess what the main thing to understand is the ingress / egress rules for 802.1q.

    Where is the tag removed, and where is it set.

    From what I have come across so far :-

       Its removed on EGRESS (if its going out a trunk with tag = native )

       Its set on ingress, IF there is no tag.

My  doubt was, what happens when an 802.1q tagged frame comes in on a trunk that allows multiple vlans.

           I guess the answer is :-

                       The tag remains there on ingress 

                       On  EGRESS,  rules are applied, and if the tag == native on egress trunk, strip it.

Thanks

Thanks to all those who commented !!

I have used yersinia to test vlan tagging over a trunk link and it works.

     Attacker <====TRUNK (7, 1=native OR 1,7=native)====> [SW1]  <----- Trunk (many vlans, native =7)-------->   [SW2]--------Target on vlan 1

   In fact this tool (yersinia) only seems to work (for double tagging) over a trunk link.

I tested with both, sending

             A. The outer tag with vlan 7 == trunk native vlan of the trunk attached to the attackers PC port

             B.The outer tag with vlan 7 on the trunk with native vlan == 1

In both cases, the outer tag was vlan 7, which was == trunk native vlan connecting the two switches.

In both cases, the OUTER tag (vlan 7) was retained, just before the the EGRESS out the port onwards to SW2

      On exiting, the outer tag was stripped because it was == native valn on trunk connecting SW1 & SW2

Now, I am looking at scappy to see if I can launch this attck over an access port.

Thanks

VLAN hopping depends on how the next switch handles the VLAN 99 tagged frame. If it is configured as DTP auto and receives a fake DTP frame then the port will become a trunk and the VLAN 99 frame can pass. If you disable DTP auto then this will be impossible.

This is described on the following page: Implementation of Security

On that page it is not described what happens if there is a trunk configured between the switches with native VLAN 5 where the VLAN 5 tag will be removed and you have a VLAN 99 tagged frame that will hit the next switch. If that trunk port is not configured to accept VLAN 99 then the frame is discarded and if VLAN 99 is allowed then it will pass.

/André

In my situation, the trunk between the two switches does allow vlan 99 across. And the target is in  access mode on vlan 99.

So, what you are saying is that the outer tag will be stripped off on the first switch, even if the packet came in on a trunk.

  Thats exactly what I think.. but wanted to confirm

Thanks