Originally Posted: 3/30/2004

I wanted to post this for those rare hackers and network admins out there trying to find vlan info. Even though vlans are rarer these days..There isn't much vlan info on the net in terms of specifics and I had to learn all about it because I needed to log in to a switch that was on a different vlan. Impossible? No it is really easy after the research.. It was beautiful when I finally got to that terminal login.

Update: There is a great resource for vlan information now available at Capturing VLAN Packets from the incomparable, uncommonly great open-source gem WireShark

Discussion I had with the developers of ettercap.

The original post is still up on the Ettercap Development Form

VLAN Virtual Lan. VLAN spoof. Layer-2 switch. wvlan. Hello there, first post here. First I want to thank all of the developers for an outstanding product. Also I notice that you freely give your time to peruse through the forums and help people. Outstanding.. My problem is this. I am connected to an Allied Telesyn 8024 layer 2 switch (http://alliedtelesyn.com/products/details.aspx?9) with port security enabled to the Secure mode. By misconfiguration, only the switch itself is on a vlan. The router is not, the other switches in the network are also not. No ports are included in this vlan on the switch. The management vlan is 1. The switch checks its CAM table for the correct mac from the correct port before it forwards the frame. This means that a remote management session is highly improbable from the current setup (static mapping). The only response I can get from the switch is with an arp request. For this I use the arping utility for linux. The switch is on vlan 1. Here is an ethereal capture of an arp reply from the switch.

No. Time Source Destination Protocol Info
3 1.500954 AlliedTe_XX:XX:XX LinksysG_XX:XX:XX 0x0806 ARP

Frame 3 (60 bytes on wire, 60 bytes captured)
Arrival Time: May 29, 2004 15:21:41.982501000
Time delta from previous packet: 0.001966000 seconds
Time since reference or first frame: 1.500954000 seconds
Frame Number: 3
Packet Length: 60 bytes
Capture Length: 60 bytes
Ethernet II, Src: 00:30:84:XX:XX:XX, Dst: 00:04:5a:XX:XX:XX
Destination: 00:04:5a:XX:XX:XX (LinksysG_XX:XX:XX)
Source: 00:30:84:XX:XX:XX (AlliedTe_XX:XX:XX)
Type: 802.1Q Virtual LAN (0x8100)
802.1q Virtual LAN
000. .... .... .... = Priority: 0
...0 .... .... .... = CFI: 0
.... 0000 0000 0001 = ID: 1
Type: ARP (0x0806)
Data (42 bytes)

0000 00 04 5a XX XX XX 00 30 84 XX XX XX 81 00 00 01 ..Zj...0.M. ....
0010 08 06 00 01 08 00 06 04 00 02 00 30 84 XX XX XX ...........0.M.
0020 ac 10 00 05 00 04 5a XX XX XX ac 10 00 80 00 00 ......Zj........
0030 00 00 00 00 00 00 00 00 00 00 00 00 ............

The switch connects to the router through port 24. Enhanced Stacking is enabled and this switch is set up as a master. It can only see 1 other switch. The second switch is between the first switch and the router. I am unable to connect to the second switch or get any type of response. This is important because if I could connect to the second switch via telnet or web management, I could set it up as a master and reconfigure switch one. So keep that in mind.

I am able to use ettercap to arp poison all of the other hosts connected to the switch. I am not able to see the rest of the net. I know the rest of the net is there from broadcast arps from the router. I also have the macs and IPS of most of them.

Would it be possible to DoS the switch? Any recommendations? What about some type of vlan packet DoSer.

Could I use ifconfig to spoof my mac and ip address to look like an allied telesyn switch, and then generate packets with the correct vlan header to access the switch management ports?

How can I generate vlan packets (libnids, libnet, libdnet) and use them with ettercap?

What, as developers, are you thinking about vlans? As they are becoming increasingly used. Don't tell me this is the beginning of the end for ettercap!

Trunking is not enabled. Spanning tree is not enabled.

... with port security enabled to the Secure mode.

Looking at the docs, there are three modes of Port Security on your switch. In "Limited mode" the port is only going to allow a preset number of mac address to be learned from each port. Anything else is dropped. If that's the case, see if you can get into another port that may be misconfigured. This port could be used by a second NIC to send out the spoofed ARPs. This isn't built into ettercap but nemesis would do the trick. Just write a shell script to repeat the ARP every 10 seconds or so.

Another thing you may want to look into is becoming a trunk port. Chances are your admins have removed this function as well but be careful, apparently the switch can only handle one trunk at a time (what a cheap switch!).

When all else fails find the console, hook up a serial cable, reset it and hit enter while it's booting. type "boot" at the prompt and then put the password of "admin" in.

(WARNING - all advise here can get you into deep doodoo. If you're not authorized to do any of these things and you get caught, you're SOL)

I really think your best option is a second NIC with nemesis. If port security is enabled then you're really kinda stuck. Can't overflow, can't mitm.

Solution

Whoah...

I was going to try the various types of attacks in those articles, and had the libnet codes all ready, but then I decided to look here http://www.candelatech.com/~greear/vlan.html

I recompiled my kernel with 8021q as a loadable module. (included with my kernel)

I edited my rc.d/rc.local file with the lines

/sbin/i forget it loads the module dependencies.

/sbin/modprobe -a 8021q

and then rebooted, I installed the vconfig utility (rpmfind.net) and then did

$ vconfig add eth0 1 (1 is the vlan id I needed) This created device eth0.1

$ ifconfig eth0.1 netmask 255.255.255.0 broadcast 255.255.255.255 hw ether (mac from eth0 becasue port security is on and drops all other macs) (IP but different from eth0)

$ ifconfig eth0.1 up

Now, I tried to ping the switch and examined packets in ethereal on the "any" device.

$ ping switch  //didn't work.

$ ping -I eth0.1 switch //Bingo! It responded!

$ telnet -b eth0.1 switch

Bingo! I then configured the switch to operate correctly, saved changes, and quit. I rmmod 8120q and edited rc.d file. Fixed.

Standard Port security has nothing to do with arp poisoning, because "spoofed" arp packets have the right source mac address of the ettercap machine.

Well the switch had a predefined static mac address that was allowed on each individual port. IOW, I couldn't connect to anything with a mac other than the one predefined. Not even by spoofing other legal macs located on different ports.

Maybe you guys should look into a plugin that spoofs a vlan header so you could arp poison different vlans?

NaGA wrote: Standard Port security has nothing to do with arp poisoning, because "spoofed" arp packets have the right source mac address of the ettercap machine. D'oh, you're right. My brain wasn't engaged while replying. I was thinking about something entirely different.

ALoR wrote:
Maybe you guys should look into a plugin that spoofs a vlan header so you could arp poison different vlans?

you can use the in-kernel support for 802.1q and setup a virtual NIC on that vlan, then use the -i to select it as the default interface

Downloads and Documents

Ive googled the sauce out of vlan info and these are the best docs I've come across. It includes actual code used with libnet to attempt the various types of attacks with vlans. A must read.

Making unidirectional VLAN and PVLAN jumping bidirectional

Advisory: Making unidirectional VLAN and PVLAN jumping bidirectional Class: design bug Vulnerable protocols: 802.1q, various PVLAN implementations Model Specific: This is a protocol, and not vendor-specific attack DETAILS: Wepwedgie, a tool by Anton Rager for traffic injection on 802.11 networks protected by WEP, solves the problem of unidirectional communication by bouncing packets from the target host to a third external host under the attackers control. We employ exactly the same principle to bypass both VLAN and PVLAN network segmentation. 1. Modification of the double-tagging VLAN jumping attack. The attacker tags his malicious data with two 802.1q tags and sends the packet with a spoofed source IP of a host under his or her control. This can be any host to which a valid route from the target VLAN is present, including an external host on the Internet. The first tag gets stripped by the switch the attacker is plugged into and the packet is forwarded to the next switch. The remaining tag contains a different VLAN number, to which the packet is sent. So, data is forced to pass between the VLANs. The receiving host will check the source IP of the arriving packet and send the reply to this IP, which is a host that belongs to the attacker. This attack can be launched using Yersinia (http://sourceforge.net/projects/yersinia/). 2. Modification of the MAC spoofing PVLAN jumping attack. The attacker sends a packet with a valid source MAC but a spoofed source IP of a host under his or her control. This can be any host to which a valid route from the target PVLAN is present, including an external host on the Internet. The target MAC address is replaced with the one of a gateway router. A switch would forward such packet to the router, which will then look at the IP and direct the packet to the target. Of course, the source MAC of the packet will be replaced by the one of the router, which would then direct the reply packet from the target to the host that belongs to the attacker. This attack can be launched using pvlan.c from the Steve A. Rouiller's "Virtual LAN Security: weaknesses and countermeasures" GIAC Security Essentials Practical Assignment. Note: Such attacks can be used for different purposes from portscanning to communicating with a backdoor on a different VLAN or PVLAN. Risk Factor: Medium Workarounds: There are no direct workarounds. Implement strict egress filtering against the spoofed packets described.

Interview of ALoR and NaGA

Here is a quick interview with Alberto Ornaghi (a.k.a. ALoR) and Marco Valleri (a.k.a. NaGA). Each is 26 years old, and they work as security consultants for two different company in Milan. http://www.newsforge.com/article.pl?sid=04/11/04/2114203

VLAN Setup and Configuration for virtual VLAN device

802.1Q VLAN implementation for Linux

To get started, you will want to download the latest vlan.X.X.tar.gz file (to your $HOME directory.) Unpack it with your favorite commands, for example: tar -xvzf vlan.1.6.tar.gz Alternatively, you can get it from the CVS Repository using something like this:

Install and configure on your machine.
Specify the vlan repository: export CVSROOT=:pserver:anonymous@cvs.candelatech.com:/web/cvs_user/vlan
Log in to the repository: cvs login (PASSWORD: anonymous)
Check out the source: mkdir vlan; cd vlan; cvs -z3 checkout vlan

Now, you should have a vlan directory in your home directory. You only have to patch the kernel if you are using Linux 2.4.14 or earlier. Now, read the README or other docs to figure out what kernel it patches against. A list of mirrors are kept at www.kernel.org. Unzip and un-tar this in your home directory as well, which should create a linux directory in your $HOME directory. Example: tar -xvzf linux-2.2.14.tar.gz Now add the VLAN kernel changes to the kernel if your kernel requires it. I finally figured out how to do patches that diff can handle (I think I did it right at least!). You will find the patch in the vlan directory. It will be called: vlan.patch, or something equally straight-foward. Apply the patch to your kernel:

cd $HOME/linux
patch -p 1 < $HOME/vlan/[vlan.patch]

Your new, patched, kernel should be in your INCLUDE path before trying to compile the vconfig program. One way to get things working is to link $HOME/linux to the 'linux' directory that you just un-zipped and patched. A command might be something like: cd $HOME; ln -s /web/greear/kernel/2.4/linux.dev linux Build the vconfig program in the $HOME/vlan directory:

cd $HOME/vlan
make

Now, time to compile your new kernel! Use the make xconfig command in your $HOME/linux directory to select your kernel options. The option related to 802.1Q VLANs is found under the Networking options. If the option is not highlighted, make sure you select "Experimental Drivers" in one of the first xconfig menus. Assuming your kernel compiled cleanly (yell if it didn't and you think my code broke it!!), you are now ready to try it out!! Install your kernel in the normal manner (fix up your /etc/lilo.conf file appropriately and run lilo as root.) Reboot your computer and choose your new kernel. As your computer comes back to life, there will be little sign that you are now 802.1Q capable, other than a line spit out during the boot process. There should be a config programs in your $HOME/vlan directory: vconfig. vconfig is used to create and destroy VLAN devices. So, lets create a VLAN device on your first ethernet NIC. vconfig will list a short spiel on how to use it. The vconfig command I usually use is:

vconfig add eth0 5

This attempts to create a VLAN device with VLAN-ID of 5 on the eth0 device. If you want to delete a VLAN, use something like:

vconfig rem eth0.5

You will also need to give it an ip, eg: ifconfig -i eth0.5 192.168.2.1 and configure it UP: ifconfig -i eth0.5 up NOTE: You can get lots of VLAN related configuration information from the /proc/net/vlan/* files by using 'cat' or 'more' to look at them.

Intrusion Detection FAQ: Are there Vulnerabilites in VLAN Implementations? VLAN Security Test Report

David Taylor July 12, 2000

Introduction

This document details the testing methodology and results of security testing conducted against Cisco's VLAN implementation. The results presented were gathered entirely from this testing. The applicability of the results to other Cisco switch models, or other vendors' products is limited.

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.

Equipment

The following equipment and software was used during testing.

2 x Cisco 2924 Ethernet switches. Each with 24 x 10/100 UTP
2 x Generic PCs. Each with one 10 Mbit ethernet NIC.
1 x UTP crossover cable for trunking
2 x UTP cables for PC connectivity
Switch console cable and PC adaptors
Windows NT operating system on both PCs
Network Associates' Sniffer Pro v.2.0.01

Preparation

The switches were both prepared with a similar configuration. Ports 1-8 were assigned to VLAN 1. Ports 9-16 were assigned to VLAN 2. Ports 17-23 were assigned to VLAN 3. Port 24 was designated as an 802.1q trunk port. A sample switch configuration can be found in Appendix A. The two PCs were configured with IP addresses on the same C class subnet. This is largely irrelevant, due to the VLAN'ing being implemented at OSI layer 2, but it did remove the ICMP net unreachables and other errors that would otherwise have been experienced during the testing.

Methodology

Sample frame capture The two PCs were attached to the same VLAN of one of the switches. An ICMP echo (ping) packet was sent from PC 1 to PC 2. This was captured with Sniffer Pro on PC 2 and the packet was viewed in raw hex. This packet was recorded for further use in testing. The packet generation component of Sniffer Pro was started on PC 1 and the packet data captured above was entered into the tool. It is important to note that the packet generation tool in Sniffer Pro takes care of the ethernet preamble and frame check sequence. When the data was fully entered, the constructed packet was sent from PC 1 to PC 2, and was captured on PC 2 to ensure that it was correctly identified. Insertion of 802.1q tag Next, PC 2 was shifted to port 24 on switch 1 (the trunk port) and the sniffer software was started on this machine. PC 1 was left on a VLAN 1 port of the same switch. From the command prompt on PC 1, a non-existent IP address was pinged. As this non-existent IP address did not have an entry in PC 1 ARP table, the machine broadcast an ARP lookup and this lookup was captured on PC 2. As PC 2 was listening on a trunk port, it received the ARP lookup in 802.1q format, containing the 4 byte 802.1q tag. This process was repeated, with PC 1 moved to a VLAN 2 port and from these two captures, the format of the 802.1q tag was found to be "81 00 0n nn", where nnn is the VLAN number. For example, frames on VLAN 1 would have a tag of "81 00 00 01", frames on VLAN 2 would have a tag of "81 00 00 02". The 802.1q tag is positioned directly after the source MAC address of the frame and before any of the IP header information. Taking into account this frame format and placement information, an 802.1q tag was inserted into the ethernet frame that was generated in the previous section. 802.1q Frames into non-trunk ports For the next test, PC 2 was moved to a VLAN 1 port on the second switch. PC 1 was moved to a VLAN 1 port on the first switch. The trunk cable between the two switches was reconnected. The 802.1q frame generated in Sniffer Pro was sent from PC 1 and was received by PC 2 as a plain ICMP echo ethernet frame, without the 802.1q tag. This test was repeated with both PCs on VLANs 2 and 3 also. In each case, the handcrafted frame was delivered to the destination machine. Hopping VLANs For the next test, the PCs were connected to different VLANs on each of the switches and an attempt was made to get the generated frame to ˜hop' from one VLAN to the other. Various VLAN ID's were used in an effort to cover as many combinations as possible. Additionally, attempts were made to get frames to hop VLAN boundaries within the same physical switch. The following results were collected. Different Switches The two combinations of note are in the first table (different switches) where traffic was sent from VLAN 1 to VLAN 2, and from VLAN 1 to VLAN 3. Native VLAN of trunk port Following the previous test, prolonged discussions took place with the switch vendor to discuss the implications of the results above. After consultation with their developers it was concluded that the traffic from VLAN 1 was allowed to hop to other VLANs because the trunk port was also set (implicitly) to native VLAN 1. They suggested that by changing the native VLAN of the trunk port the VLAN hopping could be eliminated. This was tested and was found to be true. The results are shown below. In each case, the tag VLAN ID was set to the destination VLAN (This was found to be the most likely to succeed in preceding tests).

Implications

In a default configuration it is possible to inject 802.1q frames into non-trunk ports on a switch and have these frames delivered to the destination.
It is possible to get 802.1q frames to hop from one VLAN to another if the frames are injected into a switch port belonging to the native VLAN of the trunk port. It is also necessary for the source and destination ethernet devices to be on different switches.

This vulnerability could be exploited if the following conditions were met:

The attacker has access to a switch port on the same VLAN as the native VLAN of the trunk port.
The target machine is on a different switch in the same trunk group.
The attacker knows the MAC address of the target machine.
Some layer 3 device exists to provide a connection from the target VLAN back to the source VLAN.

Unconfirmed Findings

In our discussions with Cisco they stated that this issue was present in all of their VLAN switches and all of the competitors switches that they tried. This is assumed to include Nortel and 3Com devices.

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.

Hacking VLAN switched networks - AskApache

Charles Torvalds

2 Aug 2024

Exit mobile version