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.
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.
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.
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
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.
- VLAN Security: weaknesses and countermeasures
- BLACKHAT Presentation on VLANs and switches
- Info on the VLAN protocol
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.
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
- Making unidirectional VLAN and PVLAN jumping bidirectional
- Ettercap and Switches
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:
- 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
<return> 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 ReportDavid Taylor July 12, 2000
- 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
- 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.
- 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.