Vlan Hopping Vulnerability

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hello, i have read many doc about this exploit but there are any
contradictions.

I hnow that this exploit exist in 3 ways :

1) Basic=> The attacker spoof a switch and gains the trunked states of
the switch's port. Rely on auto-negotiate feature turned ON. This ways
is simple to understand and to block


2) Complex 1 => This attack is described on
http://www.sans.org/resources/idfaq/vlan.php and to work need that the
attacker and the trunk share same native vlan ( ex. VLAN 10 ). In this
doc. the attacker send on the access port ( VLAN 10 ) a tagged frame
with a VLAN-ID of target VLAN ( ex. VLAN 20 ) . The switch takes frame
and forward it on trunk port without native tag (10). The other switch
(connected via-trunk) read VLAN-ID(20) and forward frame on the access
vlan 20.

In this scenario my doubts is :

- Why the first SW accepts tagged frame ?
Is this behavior an anomaly of work ?

- Why the last switch that receives native frame on trunk port reads
the VLAN-ID ? Is this normal or anomaly ? I think that sw does'nt read
VLAN-ID because the frame on trunk is native .

2)Complex 2 => In other docs per ex:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_...
there is an attack called " Double-Encapsulated 802.1Q ". In this
exploit the conditions are similar to the
precedent but the attacker need to insert two VLAN-ID ( outer,inner ).
If this case work then the first switch read VLAN-ID on access port and
forward frame on trunk ( strip off first VLAN-ID ) . This behavior is
different that
precedent case . Why the switch forward this frame according to VLAN-ID

on the access-port ? Is this behavior another anomalies ?

Sorry about lenght of post but i want to understand if this
vulnerability were resolved or not .

Thanks

Giuseppe Citerna
ccie#10503

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Jos_Cit wrote:

> 2) Complex 1 => This attack is described on
> http://www.sans.org/resources/idfaq/vlan.php and to work need that the
> attacker and the trunk share same native vlan ( ex. VLAN 10 ). In this
> doc. the attacker send on the access port ( VLAN 10 ) a tagged frame
> with a VLAN-ID of target VLAN ( ex. VLAN 20 ) . The switch takes frame
> and forward it on trunk port without native tag (10). The other switch
> (connected via-trunk) read VLAN-ID(20) and forward frame on the access
> vlan 20.

I looked up Cisco's website, and native VLAN appears to be a way of
configuring only one of the VLANs to be untagged on a trunk since
normally trunks need to have all traffic tagged.

> In this scenario my doubts is :
>
> - Why the first SW accepts tagged frame ?
> Is this behavior an anomaly of work ?

There is no way in the standard to have a port accept only
untagged frames. There is a control variable called
"Acceptable Frame Types" and that can be set to be:
- Accept all frames
- Accept only tagged frames.

So normally an "access" port will accept tagged frames
as well. However, if the switch has ingress filtering
enabled (and this is optional in the standard and not default
behavior), then the switch would have dropped the incoming
frame since it would have had a VLAN tag for a VLAN of which
it was not a member.

It looks like this switch is processing the frame as
being on VLAN 20 all the way.

> - Why the last switch that receives native frame on trunk port reads
> the VLAN-ID ? Is this normal or anomaly ? I think that sw does'nt read
> VLAN-ID because the frame on trunk is native .

This is normal. The VLAN ID (20) is the non-native VLAN
of the trunk and so the switch will read it and classify
the frame as being on VLAN 20 and forward it accordingly.

>
> 2)Complex 2 => In other docs per ex:
> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_...
> there is an attack called " Double-Encapsulated 802.1Q ". In this
> exploit the conditions are similar to the
> precedent but the attacker need to insert two VLAN-ID ( outer,inner ).
> If this case work then the first switch read VLAN-ID on access port and
> forward frame on trunk ( strip off first VLAN-ID ) . This behavior is
> different that
> precedent case . Why the switch forward this frame according to VLAN-ID
>
> on the access-port ? Is this behavior another anomalies ?

The behavior is normal for the given configuration.

This again looks like an anomaly due to the notion of a native
VLAN which allows you to send the native VLAN untagged on
a trunk. The first switch receives a QinQ frame on a port
that expects to see only a single tag. Because it is
forwarding it on a trunk, and outer tag based on which it
is doing its forwarding, is equal to the native VLAN it
untags the frame. In the normal "good case" the receiving
switch would have picked up this frame and tagged it using
the native VLAN. However, in this case, the frame already
has a tag (the inner one) and so the receiving switch
classifies and forwards the frame based on that.

Per the white paper this can be avoided by not using the
native VLAN.

Anoop