Do we really need Layer 2 Security?

I was reviewing some networking best practice documents a short while back, and when I got to the Layer 2 Security Section I started thinking…

[Begin inner monologue]
…. hmm… Layer 2 security, is it all hype?  Could an attacker really implement these attacks?…. I could really go for some cake…  I wonder how these attacks work… chocolate cake…. it might be fun to be the bad guy for a change….
[End inner monologue]

So after having a piece of cake or two, I sat down and started figuring out how to attack a network.  Obviously, there are many different types of network attacks, varying in complexity, but I decided to focus on two of the ones that we all start learning about with our first Networking 101 Primer.

CAM Table Overflow attack – or how to turn your switch into a hub

The idea behind this attack is to overload the upstream switch, and cause it to spit every bit of traffic out all ports, instead of following the normal switching behavior of only sending traffic out the port where the intended destination exists.  This attack works because every switch has a limited number of slots to store associations between MAC addresses and interfaces.  If all these slots fill up, the switch is unable to learn the location of new MAC addresses, and floods traffic destined for those addresses out all interfaces.

Man In The Middle (MITM) – or how to play Toll Keeper on the Packet Highway

There are many flavors of a MITM attack, but the idea remains the same in them all.  The attacker convinces a host to send outbound traffic to towards their computer instead of the real destination.  The attacker then has some options on what to do with this power.

1. Capture the traffic for analysis and then forward onto the destination
• eg. to steal usernames and passwords for later use
2. Drop the traffic, preventing the victim from communicating on the network
3. Make changes to the traffic before forwarding onto the destination
• eg. redirect the web requests for www.bigguns.com to www.tulips.com
4. Or nearly anything nefarious minds can envision

Being a fine upstanding networking engineer, I’d heard about attacks, and attacker tools before, but I didn’t have any first hand experience to build from.  So I did what any good nerd does, turned to the web.  Some googling later, I realized there was WAY too much information available and I was suffering from overload.  Not willing to give up the good fight, I turned to Twitter, and within moments had a couple of good suggestions for some tools to look at.

macof – You want address?  I got addresses…

After seeing the suggestion of macof, I recalled that I’d seen it referred to several times when learning about port-security (hint… port-security prevents CAM Table Overflow attacks).  The macof tool is a small and very simple utility that spits out random MAC addresses from the indicated network interface as fast as your computer can go.  I found this to be a very effective tool for this attack.

First, lets take a look at my switches CAM Table Stats prior to letting Bad-Hank run wild.

A couple of things to note from this output.  First, this is a switch in a lab network, so there aren’t too many addresses in the table yet.  A word of caution to anyone who wants to play with these tools, don’t do it on your live network.  You could easily turn into a “real” attacker, and that would make a great story at your next job.  Second, though this is a 24 port switch, it has space for over 8,000 addresses.  This means that under normal operation, the switch shouldn’t have any problem with keeping track of all the hosts on the network.

Now, lets take a look from the Attacking computer.  The goal of this attack is to be able to capture/sniff all network traffic on the local segment.  To show that the switching network is working as expected pre-attack, that is the attacker can’t see other network traffic, I’ll run a tcpdump and look for traffic from my intended victim (10.133.12.101).

I had the above running while firing up a telnet session to a switch from 10.133.12.101.  The only traffic that my attacker got to see is the ARP request sent from the victim looking for the default gateway.

Now, I’ll fire-up macof to get my switch as bloated as the Mississippi during raining season… both of which result in flooding 🙂

Above is just a small sampling of the output that starts flying by the screen as my attacking terminal is ripping out the mac addresses towards the switch upstream.  If we take a glimpse at the CAM Table Stats now, we’ll see something a little different.

Now we see that the switch reports 0 free slots in the table, and 8163 addresses inside Vlan 12 (the VLAN my attacker and victim are sitting on).

And one last piece of output for this attack, the tcpdump that remained running while I fired off the attack.

What this output shows, is that the Attacker now has visibility into the telnet traffic between the victim and the switch (as well as all other traffic on that VLAN.  Though I’m only showing details from the packet headers, I have access to the full contents of the packets, providing all sorts possibilities for information gathering.

arp poisoning with ettercap

After doing some digging, and trying a few different hacking tools out, I found the ettercap application to be fairly versatile and easy to use.  I won’t dive into all the features of ettercap here, but it offers the would-be attacker the ability to perform MITM attacks, dhcp attacks, CAM Overflows, real-time packet manipulation, and many others.  For this example, I’m using what I found to be the most straightforward MITM attack, arp poisoning.

Though applications and users typically think of sending traffic on a network to an IP address, ethernet actually relies on MAC Addresses to forward the traffic between devices.  The ARP protocol is how IP speaking hosts translate an IP address to a MAC Address.  ARP Poisoning is a method of convincing a victim that the MAC address of their intended destination is that of the Attackers computer.

Ettercap offers several interfaces for working with the application ranging from pure CLI input to a full fledged GUI.  I found that the Ncurses based command line GUI was the most useful for my work (started up with “ettercap -C”)

Starting Ettercap

Scanning For Hosts

The first steps to get going is to launch ettercap (ettercap -C) and choose Unified Sniffing (Unified means one interface, Bridged means two interfaces).  That will bring you into the main application, where you’ll begin by scanning for hosts on the network.

Host List

Select Targets

Then you can view the hosts that were discovered and select your targets.

ARP Poisoning

ARP Poison Parameters

With the targets selected, we’ll want to start the ARP Poisoning MITM attack.  We need to tell the ettercap to use the “remote” parameter.  This indicates to ettercap that we want to process packets that are not directed to/from the local machine.  This will be important later when we want to capture usernames/passwords entered on our Victim.

Start Sniffing Traffic

Statistics

We now need to tell ettercap to start sniffing the traffic seen on the network.  We can also view the statistics on traffic seen/processed.

At this point, we can move onto the “Victim” computer and open start some telnet and ssh sessions to network devices.

Telnet Passwords Exposed

Even SSH Isn't Safe

As we can see here, ettercap automatically processes the packets seen on the network and displays in the output usernames and passwords for several common protocols, including telnet.  We’ve long known that telnet was an insecure protocol for managing devices, but I know that many organizations continue to use it rather than move to SSH for management.  However, as can be seen in the image above, even SSH isn’t safe.  This is because SSHv1 has known vulnerabilities making it non-secure, and though most gear supports SSHv2 today, out of the box they will accept v1 or v2 connections.  Ettercap comes with packet filters that will automatically modify any SSH traffic passing through a MITM attack to force SSH sessions to v1, enabling exploitation of the SSHv1 vulnerability.  Of all the things I learned during this experiment, this was probably the biggest surprise and exposed a personal false sense of security I had from making sure I only use SSH to manage devices.

It is also good to mention you’ll also see SNMP community strings in the output.  In addition to automatically displaying Telnet and SSH passwords to the attacker, SNMP, IMAP, HTTP, and many other credentials will automatically show up clear as day with little extra effort by the attacker.

Is all hope lost….

What I learned from this exercise, and what I hope readers will realize, is that integrating security into a network design end to end is important.  Those Layer 2 Security Best Practices I mentioned at the start go a long way towards protecting a network from these and other types of attacks.  In fact, look for a follow-up post showing how to mitigate these attacks though using technologies that are already present in most of our networks.