
Understanding Man-In-The-Middle Attacks - Part 4: SSL Hijacking
Introduction
One of the most prevalent network attacks used against individuals and large organizations alike
are man-in-the-middle (MITM) attacks. Considered an active eavesdropping attack, MITM works
by establishing connections to victim machines and relaying messages between them. In cases
like these, one victim believes it is communicating directly with another victim, when in reality
the communication flows through the host performing the attack. The end result is that the
attacking host can not only intercept sensitive data, but can also inject and manipulate a data
stream to gain further control of its victims.
In this series of articles we will examine some of the most widely used forms of MITM attacks
including ARP cache poisoning, DNS spoofing, HTTP session hijacking, passing the hash, and
more. As you will mostly find in the real world, most victim machines are Windows-based hosts.
That being the case, this series of articles will focus entirely on MITM exploitation of hosts
running versions of Windows. When possible, attacks will also be performed from Windows
based hosts. In cases when there are no tools available for the attack being presented we will be
utilizing Backtrack Linux 4, downloadable as a live-CD or a virtual machine from here.
ARP Cache Poisoning
In the first article of this series we will take a look at ARP cache poisoning. One of the oldest
forms of modern MITM attack, ARP cache poisoning (sometimes also known as ARP Poison
Routing) allows an attacker on the same subnet as its victims to eavesdrop on all network traffic
between the victims. I’ve deliberately chosen this as the first attack to examine because it is one
of the simplest to execute but is considered one of the most effective once implemented by
attackers.
Normal ARP Communication
The ARP protocol was designed out of necessity to facilitate the translation of addresses
between the second and third layers of the OSI model. The second layer, or data-link layer, uses
MAC addresses so that hardware devices can communicate to each other directly on a small
scale. The third layer, or network layer, uses IP addresses (most commonly) to create large
scalable networks that can communicate across the globe. The data link layer deals directly with
devices connected together where as the network layer deals with devices that are directly
connected AND indirectly connected. Each layer has its own addressing scheme, and they must
work together in order to make network communication happen. For this very reason, ARP was
created with RFC 826, “An Ethernet Address Resolution Protocol”.
Figure 1: The ARP Communication Process
The nitty gritty of ARP operation is centered around two packets, an ARP request and an ARP
reply. The purpose of the request and reply are to locate the hardware MAC address associated
with a given IP address so that traffic can reach its destination on a network. The request packet
is sent to every device on the network segment and says “Hey, my IP address is XX.XX.XX.XX, and
my MAC address is XX:XX:XX:XX:XX:XX. I need to send something to whoever has the IP address
XX.XX.XX.XX, but I don’t know what their hardware address is. Will whoever has this IP address
please respond back with their MAC address?” The response would come in the ARP reply
packet and effectively provide this answer, “Hey transmitting device. I am who you are looking
for with the IP address of XX.XX.XX.XX. My MAC address is XX:XX:XX:XX:XX:XX.” Once this is
completed the transmitting device will update its ARP cache table and the devices are able to
communicate with one another.
Poisoning the Cache
ARP cache poisoning takes advantage of the insecure nature of the ARP protocol. Unlike
protocols such as DNS that can be configured to only accept secured dynamic updates, devices
using ARP will accept updates at any time. This means that any device can send an ARP reply
packet to another host and force that host to update its ARP cache with the new value. Sending
an ARP reply when no request has been generated is called sending a gratuitous ARP. When
malicious intent is present the result of a few well placed gratuitous ARP packets used in this
manner can result in hosts who think they are communicating with one host, but in reality are
communicating with a listening attacker.
Figure 2: Intercepting Communication with ARP Cache Poisoning
Using Cain & Abel
Let us take the given scenario and take it from theory to reality. There are a few different tools
that will perform the necessary steps to poison the ARP cache of victim machines. We will use
the popular security tool Cain & Abel from Oxid.it. Cain & Abel does quite a few things beyond
ARP cache poisoning and is a very useful tool to have in your arsenal. The installation of the tool
is pretty clear cut so I won’t go through that here.
Before beginning you need to collect some additional information. This includes the network
interface you wish you to use for the attack, and the two IP addresses of your communicating
victims.
When you first open Cain & Abel, you will notice a series of tabs near the top of the window. For
our purposes, we’ll be working in the Sniffer tab. When you click this tab, you will see an empty
table. In order to fill this table you will need to activate the program’s built-in sniffer and scan
your network for hosts.
Figure 3: Cain and Abel’s Sniffer Tab
Click the second icon on the toolbar, which resembles a network card. The first time you do this
you will be asked to select the interface you wish to sniff. This interface should be the one that is
connected to the network you will be performing your ARP cache poisoning on. Once you’ve
selected this interface, click OK to activate Cain & Abel’s built-in sniffer. At this point the toolbar
icon resembling a network card should be depressed. If it isn’t, do so now. To build a list of
available hosts on your network, click the icon that resembles a plus (+) symbol on the main
toolbar, and click OK.
Figure 4: Scanning for Hosts
The once-empty grid should now be filled with a list of all the hosts on your attached network,
along with their MAC addresses, IP addresses, and vendor identifying information. This is the list
you will work from when setting up your ARP cache poisoning.
At the bottom of the program window, you will see a set of tabs that will take you to other
windows under the Sniffer heading. Now that you have built your host list, you will be working
from the APR tab. Switch to the APR window by clicking the tab.
Once in the APR window, you are presented with two empty tables: an upper and a lower one.
Once you set them up, the upper table will show the devices involved in your ARP cache
poisoning, and the lower table will show all communication between your poisoned machines.
Continue setting up your ARP poisoning by clicking the icon resembling the plus (+) symbol on
the program’s standard toolbar. The window that appears has two selection columns side by
side. On the left side, you will see a list of all available hosts on your network. Click the IP
address of one of your victims. This will result in the right window showing a list of all hosts in
the network, omitting the IP address you just selected. In the right window, click the IP address
of the other victim, and click OK.
Figure 5: Selecting Victim Hosts for Poisoning
The IP addresses of both devices should now be listed in the upper table in the main application
window. To complete the process, click the yellow-and-black radiation symbol on the standard
toolbar. This will activate Cain & Abel’s ARP cache poisoning features and allow your analyzing
system to be the middleman for all communications between the two victims. If you are curious
to see what is happening behind the scenes try installing Wireshark and listen to the interface
when you enable poisoning. You will see a flurry of ARP traffic to both hosts and immediately
begin seeing the communication between them.
Figure 6: ARP Traffic Injection
When you are finished, simply click the yellow-and-black radiation symbol again to stop ARP
cache poisoning.
Defending Against ARP Cache Poisoning
Looking at ARP cache poisoning from the defenders standpoint we are at a bit of a disadvantage.
The ARP process happens in the background with very little ability to be controlled directly by
us. There is no catch all solution, but proactive and reactive stances can be taken if you are
concerned about ARP cache poisoning on your network.
Securing the LAN
ARP Cache Poisoning is only a viable attack technique when attempting to intercept traffic
between two hosts on the same local area network. The only reason you would have to fear this
is if a local device on your network has been compromised, a trusted user has malicious intent,
or someone has managed to plug an un-trusted device into the network. Although we too often
focus the entirety of our security efforts on the network perimeter, defending against internal
threats and having a good internal security posture can help eliminate the fear of the attack
mentioned here.
Hard Coding the ARP Cache
One way to protect against the unsecured dynamic nature of ARP requests and replies is to
make the process a little less…dynamic. This is an option because Windows-based hosts allow
for the addition of static entries into the ARP cache. You can view the ARP cache of a Windows
host by opening a command prompt and type the command arp –a.
Figure 7: Viewing the ARP Cache
You can add entries to this list by using the command, arp –s <IP ADDRESS> <MAC ADDRESS>.
In cases where your network configuration does not change often, it is entirely feasible to make
a listing of static ARP entries and deploy them to clients via an automated script. This will ensure
that devices will always rely on their local ARP cache rather than relying on ARP requests and
replies.
Monitoring ARP Traffic with a Third Party Program
The last option for defending against ARP cache poisoning is a reactive approach that involves
monitoring the network traffic of hosts. This can be done with a few different intrusion
detection systems (such as Snort) or through downloadable utilities designed specifically for this
purpose (such as xARP). This may be feasible when you are only concerned about a single host,
but can be a bit cumbersome to deal with when concerned with entire network segments.
Wrap Up
advertisement