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!

AVG Free antivirus for Linux

Yeah, I know there isn't a huge need for an antivirus on Linux, but I wanted to have something besides ClamAV for scanning infected USB drives, etc. So I installed AVG Free, which I have been very pleased with. If you 'd like to try it, you can download AVG Free for a few different Linux distros here:

http://free.avg.com/us-en/download.prd-alf.line-2012

On a Red Hat-based OS, you can install the RPM by running a command like this:

sudo rpm -ivh avg2012flx-r1786-a4748.i386.rpm

(The i option is for installing, v is for verbosity and h is for a status bar comprised of hash marks.)

After you have it installed, be sure to update your definitions using:

sudo avgupdate

Take a look at the man page for full details, but here is a typical command with my personal favorite set of options:

sudo avgscan -auHd /replace/this/with/your/desired/path

And here's what these options do:

a = Scan inside archives
u = Automatically move infected object to vault
H = Use heuristics for scanning
d = Verbose mode. Multiple -d options increase verbosity. Maximum of 3 options is allowed.

Don't forget, options are case-sensitive! Also, by default avgscan scans recursively through all directories in the path specified unless you specify otherwise. See the man page for details.

I have had very good success with AVG Free for Linux and use it often for scanning USB drives that were inserted into a potentially infected Windows box so have fun!

Ping multiple hostnames or IPs from an input file

So my problem was that I needed to ping a list of hostnames from an input file to see if they were alive. All the network scanning programs I usually use accept an input file but the file must contain IP addresses and not hostnames. Lame.

So I got on my Fedora 16 Linux box and tried fping which I hadn't looked at in a while and it was even more mega-cool than I thought. fping is a command-line Linux tool and will accept an input file with hostnames or IPs or a mix of both. It will do lots of other things, too, like resolve the hostnames to IPs in the output, etc. and works great for scripts. Take a look at the man page for all kinds of coolness. fping is also very fast because it pings the hosts in parallel instead of one at a time.

Go ahead and install it and give it a whirl. On a Red Hat-based OS like mine, you can do this with:

sudo yum install fping

Below is a command that you can use to send your input text file to fping and have it send all the output to a file:

sudo fping -f scaninput.txt > scanoutput.txt 2>&1

Replace scaninput.txt with your input file and replace scanoutput.txt with your desired output filename. For my input file, I just took a list of hostnames from a spreadsheet and pasted them into a text file. The -f option is used to specify the input filename. The > of course sends the output to a file. The 2>&1 catches any error output (like a failed ping) that was originally only going to be printed on the screen and makes sure it gets sent to the output file as well. That's because a 2> redirect is different than a normal redirect. It redirects STDERR (standard error) output instead of the normal STDOUT (standard out). In our case, we are additionally sending the STDERR to STDOUT because STDOUT (default) is represented as 1 and STDERR as 2. Since STDOUT is already opened by the shell, STDERR will be appended to STDOUT so only a > is needed and not >> which would normally be used for appending. If you'd like to geek out on this epically, you can head over to http://www.linuxsa.org.au/tips/io-redirection.html and make your head hurt a little.


So after I got my scanoutput.txt I opened it in Excel for some cleaning up. (Hey, Microsoft Office is a decent product and my LibreOffice crashes like crazy so get off my back already!!) I used some Text to columns magic and got things looking nicely for continuing my project. Only downside was that I did have some duplicates of this nature:

[hostname1] is unreachable
ICMP Host Unreachable from [x.x.x.x] for ICMP Echo sent to [hostname1] ([x.x.x.x])

Fooling around with my fping redirection did not solve this because fping apparently likes to print the output twice for unreachables even if you don't do the redirection I've specified. No problem, though. After verifying that these were indeed duplicate lines, I just sorted the column alphabetically and removed all the rows that began with ICMP Host Unreachable which took all of 10 seconds. If anybody has a better way to do this, feel free to comment.

In the future, when I need to ping a list of hostnames from an input file fping will be my tool of choice. Enjoy!

Check SHA-1 hash on a file from Windows

Ever wonder why there are MD5 or SHA-1 checksums listed on websites with large downloads like ISOs and stuff? In case you didn't already know, it's so you can use it to verify the integrity of your download in case there was corruption. Believe me, Chrome is the worst about corrupting downloads, but other browsers can corrupt them, too. If your wondering why that ISO you burned to a CD won't boot, you better verify the checksum. As matter of fact, if the file is over 100 MB I always check it immediately after download so I don't waste any time fiddling around with a corrupt download. You can use one of many utilities to calculate the checksum of the file you downloaded and then check it against the checksum listed on the website you downloaded it from. Some websites even have an accompanying plaintext checksum file which can be downloaded separately and queried for the checksum by some programs. If the website is lamer and doesn't list an MD5, sometimes you can get them to email it to you. Calculating checksums for files is also useful for forensics and checking the integrity of files suspected to have been compromised, etc.

There are a number of algorithms used to calculate checksums, including MD5, SHA-1, CRC32, etc. On Windows I've been using WinMD5Sum/portable for a while now to compute MD5 hashes for files, but I've been looking for a solution to verify SHA-1 hashes because a particular site I use has them. A while back I found Microsoft's fciv, but Microsoft = less cool so I recently looked at number of other tools. Below is a list of pretty good ones I found but for me portable, lightweight and simple is important so my very fave is Marxio File Checksum Verifier. I'll tell more about it in a second.

Here is a list of some other ones, though which are not my personal fave:
Corz checksum/simple checksum
SFV Ninja
Hash Generator
Hashcalc
Multihasher (My 2nd fave)
Hasher

So I like Marxio File Checksum Verifier the best because:

• It's faster than most of the ones I tested (approximate tie with Multihasher)
• It features drag and drop
• It's clean and simple and free
• It has a compare with field, where you can paste the original source's sum
• It supports a number of algorithms, including the MD5 and SHA-1 I need.
• It shows the percentage complete so you can see the status
• It allows you to abort calculation
• It's portable
• It has an Explorer right-click menu option

Here's how to get and use the basic features of Marxio FCV:

1. Download it from Marxio's website right here
2. Initially it's just a lone exe but after you open it the first time, an accompanying ini is created so you may want to find a home for these 2 files.
3. Open the program and choose your checksum type
4. Drag and drop a file you need checked
5. Paste the original checksum you got from the source website into the Compare with field
6. If you see a checkmark, your file's sum matches that of the original and all is well

If you want things even simpler, you can click the green arrow and make Marxio FCV go into minibar mode. Or if you want to play with a bajillion tweaks, click the gear button and try things like unchecking Enable stay on top or choosing Other settings>Application thread priority. Also, try some of the other buttons like the clipboard transfer and the option to create a checksum file for more fun.

If you want to have an Explorer right-click menu item for Marxio FCV, enable this via Gear Menu>Shell integration and default action>Enable/Disable or change title. Beware if you do this, however, because the program becomes less portable. Moving the executable will then break your right-click menu.

So anyway, now I can check my SHA-1's along with my MD5's so that is happiness!