Académique Documents
Professionnel Documents
Culture Documents
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
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.
The switch is on vlan 1. Here is an ethereal capture of an arp reply from the switch.
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!
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
/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 up
Now, I tried to ping the switch and examined packets in ethereal on the “any” device.
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
DETAILS:
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.
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.
Other Links
• 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:
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 /home/greear/kernel/2.4/linux.dev linux
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:
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:
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.
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
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.
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
1. The attacker has access to a switch port on the same VLAN as the native VLAN of
the trunk port.
2. The target machine is on a different switch in the same trunk group.
3. The attacker knows the MAC address of the target machine.
4. 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.