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

[I'm forwarding this message from my colleague, Mike, who's offline
response provides lots of good info, some of which I didn't see in the
follow-ups. So, here it is. (Remember, Mike's not on the list, so you'll
have to email him offline, if needed).]

- ---------- Forwarded message ----------
Date: Mon, 11 Jun 2001 12:50:23 -0500 (CDT)
From: Mike Scher <mscherneohapsis.com>
To: hellnbaknmrc.org
Subject: Re: VLAN Issue (fwd)

Feel free to send this on to the list (I'm not on it, but your post was
forwarded to me by a colleague).

> I am looking for an actual exploit to verify the VLAN hopping issue that
> was reported back in 1999. I have found a bunch of docs and a few email
> threads on it but it seems that no one has generated a working exploit.
>
> I am in the unfortunate situation where I have a client who is refusing to
> believe the documentation and actually wants a live demo. Why isn't
> reading an RFC and pointing out flaws enough for people anymore??

Live demos of VLAN hopping on isolated switches are going to be
time-consuming to set up and then to do. If the client is willing to pay
for a test setup and lots of work -- hey, charge.

There's three relatively easier scenarios that come to mind, however:

1) On a network where the switches are trunking (very important), you can
set an entry in your host's ARP table with the MAC and IP of the target
'victim' machine, set a route to that machine directly, and just send
packets. Cisco switches don't fall for this when the switches are not
trunked. Newish docs from them suggest that if the VLANs involved are not
trunked, though other VLANs are, you can't fool 'em either. I have not
tested that, but Cisco still recommends against relying exclusively on it
(see URL at end).

2) On a machine with a NIC capable of VLAN trunking (802.1q), "break root"
and set the NIC to trunk all VLANs. Most enterprise switches by default
auto-negotiate trunking on all ports and will happily trunk back at you.
Now sniff. Solaris 8 can do this with the better NICs (qfe and I THINK
hme), and Linux should be able to do it with some of the Intel NICs.
Other NICs probably, too.

3) Break into the switch (or multi-vlan L3 device like the sup card in a
high-end Cisco); put an IP on every VLAN interface; have fun.

Dug Song released a couple of tools to mess with switchport isolation, but
not VLAN isolation per se -- Creative use of those tools can help #1 above
to work. #2 is just plain cake unless the switch is set to NOT trunk any
client port.

See:
http://naughty.monkey.org/~dugsong/dsniff/
(The Dsniff toolset)
http://free.prohosting.com/~subsolar/articles/2000/switched_network_datacapture.shtml
(Discussion of same)

Some URLs that give much better info than having to test for every client:

Actual test results of VLAN isolation breaking:
http://www.sans.org/newlook/resources/IDFAQ/vlan.htm

Cisco's own words (very recent document):
http://www.cisco.com/warp/public/cc/so/cuso/epso/sqfr/safe_wp.htm
"VLANs and VLAN tagging protocols were not designed with security in mind"

The older Cisco document that led to me, Mike Franzen, and Kevin Kadow
looking at VLAN isolation with a jaundiced eye a couple of years ago:
http://www.cisco.com/univercd/cc/td/doc/product/lan/28201900/1928v9x/ee_scg/a_v$

Remember: Every switching VLAN improvement designed to isolate VLANs is
an ADD-ON to the default protocols.

      -M

- --
      Michael Brian Scher mscherneohapsis.com
                         Sr. Research Consultant
                  Attorney, Anthropologist, Part-Time Guru
                   Mailaise: n, ('mail-aze). See Outlook.

-----BEGIN PGP SIGNATURE-----
Comment: Key available at http://pgp.mit.edu

iD8DBQE7LUwFW5zvMHNPjVMRAt5rAJ9oWzTHOZPDFh4qeOjoMeGVUhhpygCaAkNI
lxZaczvi0m8v5VIp+78n+BI=
=+SuI
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]