MAC flood buffer overflow attack

Sniffing from behind a switch

Using a packet sniffer to snoop on LAN traffic isn't as easy as it used to be when legacy hubs were in most networks instead of modern day switches. This is because on a hub, all Ethernet ports are on one collision domain but on a switch, each port has its own collision domain...Er, at least until the switch gets hacked, which we'll do here in a minute. A collision domain means that each host has to wait until the other hosts are done talking before they can have a turn sharing the wire. Sort of like a party telephone line back in the day. (No, I'm not that old.) The cumbersome CSMA/CD (Carrier Sense Multiple Access / Collision Detection) protocol is used to make the hosts take their turn without interfering with each other. A switch is far more efficient because each port is on its own collision domain and therefore there are no collisions. If switchport 1 wants to talk to switchport 2, the switch efficiently sends the traffic between 1 and 2 without sending this data inefficiently out all ports like the party line style hub does. Very inconvenient for a hacker.

One of the most common vulnerabilities in any computer technology is the buffer overflow. If you can fill up the victim with more data than it can handle, it often starts to behave erratically. Hackers like this. Thus is the vulnerability of a switch without proper security measures in place. A switch's CAM (Content addressable memory) table -- also known as MAC address table -- can be buffer overflowed with the right tools. The MAC table is used by the switch to determine where everybody is. Host A has such-and-so MAC address and Host B has yatta-yatta MAC address. It learns the MACs from the hosts and stores them in the MAC table. Kind of almost reminds one of resolving DNS names to IP addresses, I suppose. Instead, we're resolving IP addresses to MAC addresses. If Hosts A asks where Host B is (by IP address) and the switch doesn't know about Host B yet, it will send a layer 2 broadcast (to ff:ff:ff:ff:ff:ff) asking who has the IP address associated with Host B. When Host B answers, it provides it's MAC address to the switch who stores it in the MAC table. Now the next time somebody asks for Host B (by IP address), the switch already knows Host B's MAC address and what port is associated with that MAC address.

Cisco Catalyst 2950 switch

So what if this MAC table got too full? (Muahaha.) Wonder what would happen then? Well, if the switch doesn't have proper security measures in place (and many do not), a buffer overflow DoS can 'cause the switch to fail-open and start behaving like a hub for any new hosts who connect! Hacker's dream come true for sniffing. Now when Host A requests to talk with newly introduced Host B, the switch can't find it's MAC in the MAC table and it can't add it to the MAC table because it is full so it just freaks out and sends the traffic out all ports.

So what if a blackhat either got physical access to one of your switches, or compromised one of your boxes remotely so that s/he could sniff any unencrypted passwords in plaintext? That's what we're going to simulate below. The attack consists of barraging the switch with malformed ARP traffic which fills up the switch's CAM table. Keep in mind, this was done in my test lab on a segregated LAN and should not be performed on a production network. Bad things can happen like going to jail for wiretapping or worse yet, crashing your switch. Do I need to repeat this?: DO NOT PERFORM THIS ON A PRODUCTION NETWORK.

My test lab consisted of the following:

--Victim server--

Operating system: Puppy Linux (live CD)

IP address: 192.168.200.2

Switchport: 1

--Victim client--

Operating system: DSL (live CD)

IP address: 192.168.200.3

Switchport: 2

--Victim switch--

Hardware: Cisco Catalyst 2950 switch

Operating system: Cisco IOS Release 12.1(22)EA8a
Connection for management: Cisco DB9 to RJ45 Console Cable
(Both victims and the attacker were plugged into this switch)

--Attacker--

Operating system: Fedora 16

IP address: 192.168.200.4

Switchport: 3

My objective was for the attacker to be able to sniff an FTP password as it went across the LAN from the victim client to the victim server.

There are many ways you could setup this test network but I'm going show you how I setup mine. I'm weird about using live CDs so I started with booting my victim server box into Puppy Linux. After it finished booting, I went to the menu and chose Setup>Internet Connection Wizard>Internet by wired or wireless LAN>Network Wizard. Then I clicked on the appropriate interface name and setup a static IP of 192.168.200.2 and 255.255.255.0 as the mask. The rest I left as 0.0.0.0 because they won't be needed in my test lab. I then started the FTP server via the menu item Network>PureFTPd FTP Server. I made sure that "Prevent user root connections" was unchecked and that "Prevent anonymous connections" was checked. I set a root password by going to menu item Utility>ROXTerm and typing passwd. Okay, now our litte insta-FTP server has been setup...

Victim FTP server running Puppy Linux with PureFTPd

Next, I booted my victim client into DSL (Linux). Yeah, like I say, I'm kind of a live CD addict. For my DSL box, I went to the menu and chose Setup>Net Setup>netcardconf. I set my interface up on an IP of 192.168.200.3 and the mask as 255.255.255.0. I took the defaults on the rest of the options cause it doesn't really matter in my test lab. I then made sure the client could ping and FTP the server after opening a terminal from the menu: XShells>Root Access>Dark.

Victim FTP client running DSL

Okay, now to setup the attacker. I booted my attacking box into its native OS (I know...boring) of Fedora 16. My first attempts involved using Ettercap to perform the MAC flood which gave me problems. Ettercap is a great tool, but I couldn't get it to behave on my box. It would crash a lot. Also, even with a zillion customizations to /etc/etter.conf, it would still only trickle out my MAC flood like spit from a baby's mouth and that wasn't cutting it. I don't know why it was so slow. The firewall was off. So after a bunch of crazy fooling around with Ettercap to no avail, I reverted to the very straightforward macof tool for my MAC flood. It worked awesomely. I'll tell the exact steps in a second, but first I should mention another huge hiccup I experienced: One caveat to this whole thing as stated above, is that a buffer overflow DoS can only cause the switch to start behaving like a hub for any NEW hosts who connect. Hosts who were already in the MAC table are not going to be sniffable without maybe some other hack. After banging my head against the wall for far too long, I found it was necessary to clear the MAC address table on the Cisco switch because my victims were in the table from when I performed initial ping and FTP connectivity tests. This was causing me not to be able to sniff the traffic and was resolved once I cleared the MAC table.

My attacking box already had sniffing tool Wireshark installed, but I did have to install macof (which is part of dsniff) for the MAC flood:

sudo yum install dsniff

So I opened a terminal and ran "sudo wireshark" in order to get Wireshark going. If you don't open it this way, it won't have the root access it needs. I then went to Capture>Interfaces and clicked start on my interface. Next, I typed the following into the Filter field and clicked Apply:

ip.addr == 192.168.200.3

This filters things so that I will only see traffic to and from my victim client. If you want, you can wait to do this so that you can watch the malformed packets fly by when we do the MAC flood in a minute. It's kind of a pain to apply filters while sniffing though or with large results because it takes so much time for the application to process it. I prefer to set the filter right away before there is too much data.

Now my sniffer is ready. One more thing. I need to clear the MAC table on my switch because in my test environment the victims had already talked to each other which ruins the hack. (See above.)

I installed Putty on my attacking box, even though it isn't realistic that the hacker would have access to my switch in my scenario. That's okay, though. The command to install Putty was:

sudo yum install putty

I then opened Putty from a terminal, once again using sudo for root access:

sudo putty

I logged into my switch over a console cable and ran the following command, to clear the MAC address table:

clear mac address-table dynamic

And then this just to see how my MAC table was doing:

show mac address-table count

Switch in a normal state before the attack

According to the output, I had 8,189 spaces for MAC addresses left in the table. Sounds like a lot. But once I flood it with half-a-million MACs it won't sound like a lot anymore.

Okay. Drumroll. This is it. Here's the attack. I went to a terminal on my attacking box and ran:

sudo macof -i eth0

(The i option is for interface, of course.)

Macof did a great job at DoSing my switch. In less than a minute, Wireshark had already reported over 400,000 packets being spewed out. (The status bar at the bottom of the Wireshark GUI is the place to look for this.) My switch also showed there to be no more space left in the MAC table.

Macof utility generating the DoS by spewing random MACs

Switch in a state of fail-open due to lack of space in the CAM table

At this point, I went to my victim client and typed:

ftp 192.168.200.2

The FTP server prompted for a username and password. I of course used root as the username and used the password I setup earlier. Meanwhile, I watched the username and password appear in plaintext in Wireshark on my attacking box. Yay!

The password "supersecret" being sniffed by the attacker

Below is a video of me performing the hack. It's pretty horrible quality, so sorry about that. Turns out, it's a lot harder than I thought to hold an iPhone with one hand and hack with the other. Not to mention, poor lighting, etc. Hopefully, I'll get better at the video side of blogging with time, heh....

So how can we protect ourselves from an attack like this? The most common method is to use port security. This locks the switchport down to 1 or more MAC address which are allowed to communicate. Though more commonly used to block users from placing unapproved devices on the network, port security also would prevent a MAC flood attack because the switchport could potentially shutdown the port when too many MACs try to associate themselves with the port. DHCP snooping is another method of preventing a MAC flood, but I won't go into that here.


Also, it's important to remind ourselves that FTP is not a secure protocol as the password is sent in cleartext.

Well, that's about it. There a lot of people who have documented this type of attack on various blogs and websites but this my version. I drew information from multiple sites and blogs and came up with some stuff on my own to create this proof-of-concept attack in my lab so this is the result research and network experience combined with some banging my head against a wall. Hope it was helpful to you!