Re: VLAN Security

[yves.lepage () BELLNEXXIA COM (LEPAGE, YVES)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

You're right this is definitively a problem.

However I don't think it is related to the 802.1Q specification. Any
non-trunk port should discard 802.1Q frames because non-trunk ports
are just regular ethernet ports. We have a 2924M here, I'll test that
and alarm the whole company (boy, do I love this list :-) ).

FYI, something else you might want to try. The 802.1Q spec does not
have provisions for one instance of spanning tree per vlan (as
opposed to ISL). It means anyone can inject BPDUs into your network
and generate topology changes (or even claim to the be root switch).
Since most people use the STP defaults, the perpetrator only needs to
send one BPDU every 30 seconds to make sure that the connectivity to
be disrupted remains disrupted.

The important part of this is: with 802.1Q (one spanning for all
vlans), you can adversely affect any vlan, REGARDLESS of the vlan
you're a member of.

Cisco has fixed this by extending the spanning tree spec. They now
have something called Per Vlan Spanning Tree+. Check with Cisco for
specific version numbers.

Oh! And try SA6 on the 2924M-XL, it allows you to have a management
vlan other than vlan 1. Since vlan 1 cannot be removed from trunks,
someone could easily take control of your whole network of switches
if he/she could get his/her hands on vlan 1.

Yves Lepage
Consultant - Broadband Technology
Bell Nexxia

> -----Original Message-----
> From: Bugtraq List [mailto:BUGTRAQ () SECURITYFOCUS COM]On Behalf Of
> bugtraq
> Sent: Wednesday, September 01, 1999 4:45 AM
> To: BUGTRAQ
> Subject: VLAN Security
>
>
> To Bugtraq,
>
> We have recently conducted some testing into the security of the
> implementation of VLANs on a pair of Cisco Catalyst 2900 series
> switches and we feel that the results of this testing might be of
> some value to the readers.  Testing basically involved  injecting
> 802.1q frames with forged VLAN identifiers into the switch in an
> attempt to get the frame to jump VLANs.  A brief background is
> included below for those that might not be too familiar with VLANs.
>  Others should skip to the end for the results.
>
> Background
> ==========
> Virtual LAN (VLAN) technology is used to create logically separate
> LANs on the same physical switch.  Each port of the switch is
> assigned to a VLAN.  In the case of the Cisco Catalyst, VLAN'ing is
> done at layer 2 of the OSI network model, which means that a layer
> 3 device (router) is required to get traffic between VLANs
> (possibly a filtering device).
>
> In addition to the above, VLANs may be extended beyond a single
> switch through the use of trunking between the switches.  The trunk
> allows VLANs to exist on multiple switches.  To preserve VLAN
> information across the trunk, the ethernet frame is 'wrapped' in a
> trunking protocol.  Cisco have their own proprietary trunking
> protocol, but they also support the emerging 802.1q standard - we
> used 802.1q trunking in these tests.
>
> Basically, 802.1q adds a tag to the ethernet frame that specifies
> the VLAN that the frame belongs to.  Thus, when it is transported
> between switches over the trunk, it is possible for the receiving
> switch to send the frame to the correct VLAN.  In Cisco's
> implementation of 802.1q the tag is four bytes long and has the
> format "0x 80 00 0n nn" where nnn is the VLAN identifier.  The tag
> is inserted into the ethernet frame immediately after the source
> MAC address.  So, an ethernet frame entering switch 1 on a port
> that belongs to VLAN 4 has the tag "80 00 00 04" inserted.  The
> 802.1q frame traverses the switch trunk and the tag is stripped
> from the frame before the frame leaves the destination switch port.
>
>
> For more information on 802.1q -
> http://grouper.ieee.org/groups/802/1/vlan.html
>
> During our tests we used the packet generation tool of Network
> Associates' Sniffer Pro v 2 to generate 802.1q frames with modified
> VLAN identifiers in an attempt to get frames to hops VLANs without
> the intervention of a layer 3 device.
>
> Findings
> ========
> We found that under specific conditions it was possible to inject
> frames into one VLAN and have them 'hop' to a different VLAN.  This
> is a serious concern if the VLAN mechanism is being used to
> maintain a security gradient between two network segments.  This
> has been discussed with Cisco and we believe that it is an issue
> with the 802.1q specification rather than an implementation issue.
>
> The trunk port, along with all the other ports, must be assigned to
> a VLAN.  If some non-trunk ports on the switch share the same VLAN
> as the trunk port, then it is possible to inject modified 802.1q
> frames into these non-trunk ports, and have the frames hop to other
> VLANs on another switch.
>
> eg.
> Switch 1 has ports 1-12 on VLAN 1
> Switch 1 has ports 13-23 on VLAN 2
> Switch 1 has port 24 configured as an 802.1q trunk (VLAN 1)
> Switch 2 has ports 1-12 on VLAN 1
> Switch 2 has ports 13-23 on VLAN 2
> Switch 2 has port 24 configured as an 802.1q trunk (VLAN 1)
> Machine 1 is on port 1, switch 1.
> Machine 2 is on port 13, switch 2.
>
> We can send 802.1q frames with the following details...
>       Source MAC = Machine 1
>       Destination MAC = Machine 2
>       VLAN ID = VLAN 2
> ...from machine 1 and they will arrive at machine 2.
>
> This will only occur if the trunk port belongs to the same VLAN as
> machine 1.
> * We tried this only for the trunk belonging to VLAN 1.  We expect
> that similar results would be achieve if machine 1 and the trunk
> port shared VLAN 3, 4, ...
>
> Implications
> ============
> This is a problem if the following conditions are met:
>       1. The attacker has access to a switch port on the same VLAN as
> the      trunk.       2. The target machine is on a different switch.         3.
> The attacker knows the MAC address of the target machine.
>
> In a real-life scenario, there may also be a requirement for some
> layer 3 device to provide a connection from VLAN 2 back to VLAN 1.
>
> Recommendations
> ===============
> Try not to use VLANs as a mechanism for enforcing security policy.
> They are great for segmenting networks, reducing broadcasts and
> collisions and so forth, but not as a security tool.
>
> If you MUST use them in a security context, ensure that the
> trunking ports have a unique native VLAN number.
>
> Final Notes
> ===========
> Thanks to those at Cisco who assisted in the handling of this
> issue. The two switches used for testing were WS-C2924M-XL's.  They
> were both running 11.2(8)SA5. Additional information on test
> configuration will be made available on request.
>
> Regards,
>
> Dave Taylor   (david.taylor () alphawest com au)
> Steve Schupp  (steve.schupp () alphawest com au)

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>

iQA/AwUBN9Z1xqktD0ID/HtTEQI52QCg+ArG1J8hm63aqNUXIRao85JeBkQAnifY
KuP+Gs9wT0IWF4wVhpyKR+lx
=z1sQ
-----END PGP SIGNATURE-----