Layer 2 Infrastructure Security(Attack Vectors)(Part 2)

Before I start talking about the experiments that I performed, I have to mention that Dany worked with me on this project. So without him, I wouldn't have had the drive to go this far. This is the equipment we used to work on this project.

It's kind of messy as expected, but it did the job. Our lab has 3 main components: The Cisco switches, the attacker's machine and the victim's machine. Just for your reference, we don't directly attack the victim's machine. If this point isn't clear yet, don't worry as we step through the attacks you will understand it better.

I had my stack of switches ready to go, but we didn't use all of them for each attack as it wasn't necessary. I had two Catalyst 2950s and one 3560 to provide us routing capabilities if required. At the bottom of the stack, you can notice a Nortel switch which connects to our router to provide us internet connectivity. My laptop which is on top of the switches is used to configure them and to show the effects of the attacks.

Our attacking machine is running Kali Linux. The OS is running on an old test machine that we had lying around and it was directly connected to our 3560 switch with an Ethernet cable.

The victim's machine is a Lenovo mobile workstation that is running Windows 7. It is also directly connected by cable to the 3560.

NOTE: Static IPs were assigned to the NICs of both of these computers. My personal laptop was receiving an IP via DHCP as it wasn't part of this experimental network. We had other devices and people on our LAN so we made sure that our test lab wasn't connected to the home network. Make sure to delimit your boundaries, as you do not want other people to be affected by these tests.

DISCLAIMER: Do not perform these tests on someones property without their consent. I am not responsible for the harm that you might cause to an individual's assets.

CAM Table Thrashing

The first attack is really not that complicated to perform, but it can have serious repercussions on one's network. This attack consists of flooding the switch with thousands of Ethernet frames with bogus source MAC addresses. For this experiment, I will simply be using the Kali box and the 3560 switch.

As the picture shows, the switch hasn't learned any MAC addresses yet. However, this is about to change very rapidly, Let us now start the flood! Macof is a tool used to flood the network with bogus frames. In my case, I specify on which interface macof should be flooding upon and I decided to do so on eth0. This is the interface that is directly connected to the switch.

After letting the tool run for about a minute, I stopped it and then checked on my switch. This is the result of this very simple attack.

The switch can't learn anymore MAC addresses on its interfaces because its CAM table is full. In the first article, I had mentioned that a switch would intelligently forward frames if it knew its destination MAC address. Now, the switch will flood any kind of traffic out of every single one of its interfaces because it cannot learn any new MAC addresses. This will consume bandwidth on an interface but it also poses a serious security risk. At this point, anyone could be running a packet capturing software and capture traffic.

CDP Flooding

As the name implies, this is another frame flooding attack. By now, we all know the importance of CDP as it can be a very handy tool. This is the same setup as the previous attack(3560 and Kali only). Before I ran the attack, I ran a command to show the CPU usage on my switch.

The CPU is barely taking any kind of a hit as it is running below 5% full utilization. However, this is quickly going to change. I will be using a program know as Yersinia which is capable of building bogus network traffic in order to exploit many of today's network protocols. So now let us start the attack.

This is the GUI of Yersinia and as you can see, it is producing bogus CDP frames with different source MAC addresses on interface eth0. Now let us go back to the switch and see the effects on our switch.

First of all, the switch received tons of CDP frames on interface fastethernet 0/2(Fas 0/2). Also the platform from which the frames were generated was yersinia. Now if we take a look at the processor utilization, we can see that the CPU jumped up to 83%! This could freeze the OS and cause the switch to restart. This effectively results in a denial of service (DoS) attack because a legitimate user can no longer access a resource normally accessible.

VLAN Hopping

I had already covered in my first article the purpose of VLANs. It is a way to segment your network. What if I told you that there was a way to jump from one VLAN to another? Well the goal of this attack is to effectively do so. For this test, I will be using 2 switches(1x2950,1x3560). Our Kali Linux machine will be connected to the 3560 and it will be on VLAN 10. Our victim's machine, will be connected to the 2950 and it will be on VLAN 20. Here is the mapping of the network.

The interface that connects both switches( fa 0/11) is configured as a trunk link. Recall that a trunk link can carry the traffic of multiple VLANs. The fact that the victim and the attacker are on different VLANs, means that they cannot directly communicate with each other. Cisco has developed a protocol called dynamic trunking protocol(DTP). This protocol enables switches connected to one another, to automatically negotiate a trunk port if the parameters match on both sides. By default, DTP is enabled on all ports. Let us show the trunk interfaces before the attack takes place.

As it can be seen, the only trunked interface on SwitchA(L3) is the fastethernet interface. This is normal because this the configuration that I had manually placed. So let us start the attack to see the difference!

Once again Yersinia, is being used but this time it's sending out DTP frames to our 3560. If we were to look back at the interfaces on the switch we would notice a difference. Our fastethernet 0/1 is now trunking! We have successfully negotiated and established a trunk link with the help of some spoofed DTP frames.

At this point, an attacker can directly communicate with the victim or decide to sniff the traffic generated by the Lenovo box. That is how VLAN Hopping can take place. Also from the output, we can see that the fa0/1 interface has access to the traffic of VLAN 1-4094. This means that if we had other VLANs with hosts in them, we could effectively compromise their security. This is no joke!

STP Manipulation

Alright out of all of the attacks, this was probably my favorite. In this scenario, an attacker will attempt to appear to other switches as the new root switch. It will do so by sending out bogus BPDU frames to the other switches. This will be done in order to force the switches to recalculate a spanning-tree. Remember from our first article that all switches have to make a path towards the root switch. This will mean that if our attacker does succeed in his diabolic plan he will be able to see all of the network traffic. Simple but deadly!

For this experiment, I decided to use 3 of my switches(2 x 2950,1 x 3560). This is the network map before the attack takes place. STP is functioning without any disturbance.

***NOTE:

->RP: Root Port

->DP: Designated Port

->Altn: Alternate port which is also know as the blocking state

Now let us start the attack. Yersinia will once again be used to perform the attack! By flooding out bogus BPDU frames, we will try to make the other switches think that we are better suited as the root switch.

To keep it simple, I won't show the messages that are exchanged between the switches. This could get very technical and it might be very difficult for some people to understand. Instead of doing that, I would rather show the new network map after the attack has been performed.

The main changes are on SwitchA(L3) and SwitchC(L3). None of them have all of their ports set to DP, but this is a characteristic of a root switch. However, if you look closely SwitchA(L3) has its fastethernet 0/23 interface set as a RP. Remember the RP indicates the interface to take in order to reach the root switch. In other words, our 3 switches see our Kali Linux system to be the new root switch and all traffic will have to go trough it. Voila! It is really simple but extremely effective. Now you can say goodbye to your data security while it is in transit!

Reference

-N.p., n.d. Web. <https://www.cleveridea.co.uk/img/structured_cabling_network_switch . jpg>.