ShortestPathFirst Network Architecture and Design, and Information Security Best Practices

18Nov/104

Man in the Middle (MITM) Attacks Explained: ARP Poisoining

It's been over 3 weeks since Firesheep was released, and yet still there seem to be so many misconceptions about this particular vulnerability.  The most prevalent of these misconceptions is that HTTP Session Hijacking, also known as "sidejacking" is something which is limited to only wireless networks.  And this belief is not limited to just session hijacking attacks.  Somewhere along the way a myth was propagated that wired switched networks are somehow impervious to attacks like these and other similar types of attacks because of the use of collision domains and the inability of an attacker to have unfettered access to the Layer 2 medium.  As I mentioned in my previous article on the Misconceptions About Sidejacking with Firesheep, attacks like these and others are not relegated to strictly wireless networks, and in fact there are many so-called Man-in-the-Middle (MITM) attacks which can be performed on a switched wired network to compromise the imaginary security of a Layer 2 collision domain.

Today we will kick off a series of articles in which we will discuss the different forms of MITM attacks.  MITM attacks come in many forms and essentially allow an attacker to act as a proxy between the victim and any host the victim has established connections with.  It is a form of active eavesdropping in which the attacker is controlling the conversation unbeknownst to the victim.

In this first part, we will discuss and outline a method whereby the Layer 2 network can be compromised, giving an attacker the ability to circumvent the limited protections of a collision domain and thereby observe traffic for which they would normally not have access to.  This is accomplished through an attack known as an ARP Poisoning attack, which is also commonly referred to as an ARP Spoofing attack.

Recall that in switched networks, unique collisions domain are created between each host and the switch.  This is unlike a hub which utilizes a single collision domain for all connected ports.  The primary reason for this behavior in switched networks is to reduce unintended collisions on the medium, however it has an added benefit in that it makes the network more secure from prying eyes.  In a switched network, traffic from one host to another is normally inspected by the switch, and the traffic is only forwarded to the host on the port whose destination MAC address matches that specified in the Ethernet header.  An obvious exception to this behavior is broadcast traffic, which is normally flooded to all ports in the broadcast domain (this normally means all ports on the switch, or if VLANs are being used, all ports in the same VLAN).  In unicast conversations however, sniffing traffic is much more difficult because the traffic is directed towards the appropriate destination and is not seen by hosts which are not part of the conversation.

Now let's take a look at how the Layer 2 network can be subjugated via an ARP Poisoning attack.  An ARP Poisoning attack can be used to subjugate traffic staying local to the LAN as well as traffic that is going to a remote network.  In this scenario, we will describe traffic that is going off-net, towards some destination off the local network such as an Internet destination.  Under normal circumstances, a host comes online and attempts to associate a Layer 2 MAC address with the Layer 3 address of the default gateway.  The ARP Request is flooded to all ports on the network so that all devices have an opportunity to inspect the ARP Request to determine if their Layer 3 address is the one which is being requested.  In a normal scenario, the device which owns the Layer 3 address will respond with an ARP Reply and indicate the Layer 2 MAC address to associate with that Layer 3 address.

In the example below, we see the host 192.168.1.106 coming online and issuing an ARP Request for the MAC Address of the default gateway 192.168.1.1.  This ARP Request is broadcasted to all hosts on the network.  In this example, the network has not been compromised yet, so the proper ARP Response is issued by the router and sent towards the requesting host.  Through this mechanism, the requesting host now associates the Layer 2 MAC Address 00:11:45:02:0A:68 with the Layer 3 IP Address 192.168.1.1.

ARP_Spoofing1

Now that we've seen how ARP works in a normal scenario, let's take a quick look at how a Layer 2 switched network could be compromised, and force all off-net traffic to go through an intermediary device, in this case, the attackers machine.  By using a tool such as Ettercap, we can easily spoof these ARP messages across the local network, and fool unsuspecting devices into routing traffic towards the attacker's machine.

First, we'll spoof our own MAC address before launching the attack, because this is really the only fingerprint which might otherwise indicate the source of this attack.  A savvy attacker would therefore likely spoof his own MAC address to evade detection.  With the following command, we spoof our MAC address to 00:de:ad:be:ef:01:

BackTrackVM:~ sfouant$ sudo ifconfig en1 ether 00:de:ad:be:ef:01

Now that we've spoofed our MAC address, we can move on to the second phase of this attack using the ARP Poisoning tool Ettercap.  The following command will launch an ARP poisoning attack on the en1 interface and essentially poison all hosts on the local network by informing them that the gateway address 192.168.1.1 should now be associated with the MAC address of the attacking host (00:de:ad:be:ef:01).  Please note, a detailed analysis of Ettercap is beyond the scope of this article and interested readers are encouraged to read Irongeek's excellent tutorial on sniffing.

BackTrackVM:~ sfouant$ sudo ettercap -i en1 -T -q -M ARP /192.168.1.1/ // Password:

ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA

Listening on en1... (Ethernet)

   en1 -> 00:DE:AD:BE:EF:01      192.168.1.32       255.255.255.0

SSL dissection needs a valid 'redir_command_on' script in the etter.conf file Privileges dropped to UID 65534 GID 65534...

   0 plugins (disabled by configure...)   39 protocol dissectors   53 ports monitored 7587 mac vendor fingerprint 1698 tcp OS fingerprint 2183 known services

Randomizing 255 hosts for scanning... Scanning the whole netmask for 255 hosts... * |==================================================>| 100.00 %

37 hosts added to the hosts list...

ARP poisoning victims:

 GROUP 1 : 192.168.1.1 00:11:45:02:0A:68
 GROUP 2 : ANY (all the hosts in the list)
Starting Unified sniffing...

Text only Interface activated... Hit 'h' for inline help

Essentially, what we've done here is to use Ettercap to send out gratuitous ARPs to all hosts on the network.  Notice that in order for us to observe the full conversation, we must poison not only the victim, but also the router as well.  In the diagram below, you can see that the attacker has sent an ARP Reply to both the router as well as to the victim.  In the case of the ARP Reply to the router, we are telling the router that traffic destined towards the victim should now be sent to the attacker.  Similarly, in the case of the ARP Reply to the victim, we are telling the victim that traffic destined towards the router should likewise be sent to the attacker as well.

ARP_Spoofing2

Here are the packet captures from the wire so we can see exactly what is taking place.  We see the attacker's machine sending an ARP Reply to poison the ARP cache of both the victim's machine as well as the router.

00:40:23.486347 00:de:ad:be:ef:01 > 00:21:6a:6c:9f:ee, ethertype ARP (0x0806), IPv4 (len 4), Reply 192.168.1.1 is-at 00:de:ad:be:ef:01

00:40:23.496628 00:de:ad:be:ef:01 > 00:11:45:02:0a:68, ethertype ARP (0x0806), IPv4 (len 4), Reply 192.168.1.106 is-at 00:de:ad:be:ef:01

And that's pretty much all there is to it... once the ARP cache of the unsuspecting victims have been poisoned, the attacker has full reign to sniff any non-encrypted traffic to or from those victim machines, in a manner no different than putting a physical tap on the wire.  Attackers may use ARP Poisoning as part of a larger attack, for example, Firesheep could now be run to perform HTTP Session Hijacking when victims visit unsecured websites such as Facebook or Twitter.

The interesting thing to note is that the attacker's machine has to keep track of a few details in order to make sure it can reach devices on the local network via their actual MAC address.  This is required because the attacker needs to proxy the communication between both the victim as well as the router.   If the attacker's machine were itself to be poisoned, the attack would not be successful.  Therefore it is imperative that the ARP cache remains intact on the attacker's machine.  Here we see the actual ARP entries stored on the attacker's machine.

BackTrackVM:~ sfouant$ netstat -rn | grep default
default 192.168.1.1 UGSc 32 139815 en1

BackTrackVM:~ sfouant$ arp 192.168.1.1
? (192.168.1.1) at 0:11:45:2:a:68 on en1 ifscope [ethernet]

BackTrackVM:~ sfouant$ arp 192.168.1.106
? (192.168.1.106) at 0:21:6a:6c:9f:ee on en1 ifscope [ethernet]

Now that we've illustrated how ARP Poisoning works and illustrated it's usage, you are probably interested to know how we can prevent this type of behavior on a local area network. While there are no foolproof mechanisms which can completely eliminate this threat in existence today, there are several things which can be done to monitor the network and limit what an attacker can do.

The first of these is to use some type of passive monitoring on the network, for example, something along the lines of arpwatch.  Arpwatch is a tool that monitors ARP traffic on a network and generates a log of observed IP to MAC address pairings.  This could be used after the fact to do forensic analysis, or it could be coupled with real-time triggered alerts in the event that something important like the supposed default gateway is observed sending out a new MAC address pairing.

Static ARP entries are another option but in practice this typically proves much too cumbersome to be effective, especially on large network segments with mobile users.

Different switch vendors have also incorporated different countermeasures and methods to protect this type of behavior on their products.  For example, Juniper Networks EX Series Ethernet Switches have a mechanism called Dynamic ARP Inspection, or DAI for short.  DAI tries to prevent ARP spoofing by intercepting ARP packets on untrusted ports and validates them against a DHCP snooping database.  This means that in order to be effective, you must employ DHCP for address assignment in your network.  That being said, often the locations where you want to prevent ARP Poisoning are going to be precisely those locations that employ the use of DHCP, so in practice this is not much of a negating factor. 

DAI will check to see if the source MAC address of an ARP packet matches a valid entry in the DHCP snooping database, and if no entry exists, the packet is dropped.  What this means is that a host must get an address assigned via DHCP before it has any opportunity to send any type of ARP packet onto the network.  It's not foolproof but it is definitely a better option than simply monitoring the network.

[edit ethernet-switching-options]
sfouant@switch# show
secure-access-port {
    interface interface-name {
        dhcp-trusted;
    }
    vlan vlan-name {
        arp-inspection;
        examine-dhcp;
    }
}

Juniper also has a mechanism known as MAC limiting which prevents MAC spoofing by limiting the number of MAC addresses learned on a given access port.  It can also be configured with an explicitly defined allowed MAC addresses for a given access port.  As we can see in the configuration below, we can define a specific MAC address to be allowed on a given interface using the 'allowed-mac' statement, or we can limit the number of learned addresses on a particular port through the use of the 'mac-limit' statement.  We can also choose to generate an error log, drop the offending packets, or shut the port down when there is a violation of our MAC limiting policy.

[edit ethernet-switching-options]
sfouant@switch# show
secure-access-port {
    interface ge-0/0/2.0 {
        allowed-mac [ 00:1b:c0:5e:53:a0 00:1b:c0:5e:53:a4 ];
    }
    interface ge-0/0/3.0 {
        mac-limit 1 action log;
    }
    interface ge-0/0/4.0 {
        mac-limit 2 action drop;
    }
    interface ge-0/0/5.0 {
        mac-limit 3 action shutdown;
    }
}

None of the above methods are completely foolproof but can certainly raise the bar for an attacker wanting to cause havoc on the local network.  One development which shows promise is a relatively new standard known as IEEE 802.1AE (also known as MACsec) which provides source authentication, data integrity, and encryption of devices on a Layer 2 network.  Not only would this encrypt sensitive data on the so-called "last-mile", it will also prevent various man-in-the-middle attacks as well as passive wiretapping attempts.  Although MACsec does show promise, adoption by the vendor community has been slow and there aren't any practical implementations of the technology that are immediately available for widespread deployment.

All in all, Layer 2 switched networks are not nearly as secure as many seem to think, and subjugating the network can be accomplished relatively easy by anyone with even the most basic of computer skills.  Ettercap is one such tool that easily allows a Layer 2 switched network to be compromised by poisoning the ARP cache of unsuspecting victims.  My hope is that this article might help raise awareness of the issues inherent in Layer 2 switched networks, and illustrate just how susceptible they are to compromise.  Please note that I do not condone attacks of this nature and have only written this article to raise awareness.

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to Google Buzz Send Gmail Post to LinkedIn Post to Slashdot Post to Technorati

29Oct/103

The Misconceptions of Sidejacking with Firesheep

Unless you've been hiding under a rock for the past few days, you are probably well aware of the recent activity around a new Firefox extension developed by a pair of researchers that brings the issue of session hijacking front and center.  The duo behind this extension, Eric Butler and Ian “craSH” Gallagher, developed the software in order to demonstrate the vulnerabilities inherent in many web sites that don't fully implement encryption.  The browser extension, dubbed "Firesheep", essentially enables an attacker to grab other people's credentials and use them to gain access to various web sites.

As Butler explains on his blog, "When logging into a Website you usually start by submitting your username and password.  The server then checks to see if an account matching this information exists and if so, replies back to you with a "cookie" which is used by your browser for all subsequent requests".

While it is very common for many websites to encrypt your initial logon and protect your password, that is typically where the protection stops.  In other words, they'll encrypt the initial login, but then leave the rest of the traffic unencrypted.  Since the rest of the communication is unencrypted, the user's cookie is left vulnerable.  Through a technique known as HTTP session hijacking (also known as "sidejacking"), an attacker gains access to the user's cookie and can then access the resources of that website while masquerading as that user.

What Firesheep does is essentially snoop the traffic on the network for these important cookies and allows an attacker to log into sites such as Twitter and Facebook with the simple click of a mouse.  Once they have the cookie, they basically have full reign over the account and are pretty much free to do whatever they want.

Now there seems to be a great deal of misinformation spreading pretty virulently about this particular issue, so I'd like to take a moment to set the record straight so that everyone will understand the true nature of this vulnerability.

First off, this is not an issue in which only wireless networks are vulnerable.  Surprisingly enough, there are some pretty respectable names in the industry propagating this misinformation - everybody from the infamous Bruce Schneier to Brian Krebs, and even Eric Butler himself.  Perhaps the reasons for these misconceptions are because it is just so much easier to exploit this vulnerability on wireless networks or perhaps it's because many people are simply not aware that switched networks can be compromised as well.

Whatever the reason may be, the fact of the matter is that this vulnerability can be exploited on both wired AND wireless networks.  On wired networks it does take quite a bit of extra work, which might explain the widespread belief that this is something only prevalent on wireless networks.  Wired networks can be subjugated through a technique known as 'ARP Spoofing' which can be done with a wide variety of tools such as Dsniff or Ettercap.

Second, this particular vulnerability doesn't just affect OPEN wireless networks.  In fact, any wireless network in which the wireless encryption key has been compromised can fall victim to this attack.  If you think that WEP encryption offers any protection against this you would be wrong.  Once an attacker has subjugated the WEP key, your HTTP sessions could still be compromised.

Finally, there seems to be an impression by a majority of people that this is some type of new exploit.  In fact HTTP Session Hijacking is not a new attack vector and has been known to exist since 2004.  The author's have merely streamlined the process by incorporating it into a simple browser plug-in which makes it simple for anyone with even the most basic networking knowledge to accomplish.  Without tools like this, an attacker would need to sniff the traffic, parse through it to grab the HTTP session keys, and understand how to bring those session keys into the web browser to complete the exploit.

So now that we've managed to clear the air and hopefully eliminate some of the false information that is circulating, what can you do to secure your traffic?  The only truly effective fix for these problems are for web sites to implement full end-to-end encryption using HTTPS, but that doesn't seem to be happening anytime soon.  In the mean time, if you are a Firefox user, a fantastic plug-in called HTTPS Everywhere will rewrite all your requests to HTTPS, thereby encrypting your communications (Ahem... you are using Firefox aren't you?).  If for some reason you just can't seem to get away from using Internet Explorer, you can still encrypt your communications using an application like TOR which encrypts the data between your computer and any one of a number of TOR exit nodes.

By the way, in case you are interested, Firesheep is named after the famous Wall of Sheep at Defcon, which displays selected details of unencrypted logins and other sessions over the event's Wi-Fi network from people who, by attending Defcon, should know better than to ever send anything unencrypted over a public Wi-Fi network.

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to Google Buzz Send Gmail Post to LinkedIn Post to Slashdot Post to Technorati