 |
| 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--
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!
