Penetration Testing mailing list archives
Re: VLAN Issue (fwd)
From: Patrick Mueller <pmueller () neohapsis com>
Date: Sun, 17 Jun 2001 19:32:04 -0500 (CDT)
-----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 <mscher () neohapsis com> To: hellnbak () nmrc 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 mscher () neohapsis 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-----
Current thread:
- Re: VLAN Issue (fwd) Patrick Mueller (Jun 18)