Hack 31 Detect ARP Spoofing
Find out if there's a
"man in the middle" impersonating
your server.
One of
the biggest threats to a computer
network is a rogue system pretending to be a trusted host. Once
someone has successfully impersonated another host, they can do a
number of nefarious things. For example, they can intercept and log
traffic destined for the real host, or lay in wait for clients to
connect and begin sending the rogue host confidential information.
Spoofing a host has especially severe consequences in IP networks, as
this opens many other avenues of attack. One technique for
spoofing a host on an IP
network is Address Resolution Protocol (ARP) spoofing. ARP
spoofing is limited only to local segments and works by
exploiting the way IP addresses are translated to
hardware Ethernet addresses.
When an IP datagram is sent from one host to another on the same
physical segment, the IP address of the destination host must be
translated into a MAC address. This is the hardware
address of the Ethernet card that is physically connected to the
network. To accomplish this, the Address Resolution Protocol is used.
When a host needs to know another host's Ethernet
address, it sends out a broadcast frame that looks like this:
01:20:14.833350 arp who-has 192.168.0.66 tell 192.168.0.62
This is called an ARP request. Since this is
sent to the broadcast address, all Ethernet devices on the local
segment should see the request. The machine that matches the requests
responds by sending an ARP reply:
01:20:14.833421 arp reply 192.168.0.66 is-at 0:0:d1:1f:3f:f1
Since the ARP request already contained the MAC address of the sender
in the Ethernet frame, the receiver can send this response without
making yet another ARP request. Unfortunately, ARP's
biggest weakness is that it is a stateless
protocol
.
This means that it does not track responses to the requests that are
sent out, and therefore will accept responses without having sent a
request. If someone wanted to receive traffic destined for another
host, they could send forged ARP responses matching any chosen IP
address to their MAC address. The
machines that receive these spoofed ARP responses
can't distinguish them from legitimate ARP
responses, and will begin sending packets to the
attacker's MAC address.
Another side effect of ARP being stateless is that a
system's ARP tables usually only use the results of
the last response. In order for someone to continue to spoof an IP
address, it is necessary to flood the host with ARP responses that
overwrite legitimate ARP responses from the original host. This
particular kind of attack is commonly known as ARP cache
poisoning .
Several tools�such as
Ettercap
(http://ettercap.sourceforge.net),
Dsniff (http://www.monkey.org/~dugsong/dsniff/), and
Hunt (http://lin.fsid.cvut.cz/~kra/)�employ
techniques like this to both sniff on switched networks and perform
man-in-the-middle attacks. This technique can of course be used
between any two hosts on a switched segment, including the local
default gateway. To intercept traffic bidirectionally between hosts A
and B, the attacking host C will poison host A's ARP
cache, making it think that host B's IP address
matches host C's MAC address. C will then poison
B's cache, to make it think A's IP
address corresponds to C's MAC address.
Luckily, there are methods to detect just this kind of behavior,
whether you're using a shared or switched Ethernet
segment. One program that can help accomplish this is
Arpwatch
(ftp://ftp.ee.lbl.gov/arpwatch.tar.gz). It
works by monitoring an interface in promiscuous mode and recording
MAC/IP address pairings over a
period of time. When it sees anomalous behavior, such as a change to
one of the MAC/IP pairs that it has learned, it will send an alert to
the syslog. This can be very effective in a shared network using a
hub, since a single machine can monitor all ARP traffic. However, due
to the unicast nature of ARP responses, this program will not work as
well on a switched network.
To achieve the same level of detection coverage in a switched
environment, Arpwatch should be installed on as many machines as
possible. After all, you can't know with 100%
certainty what hosts an attacker will decide to target. If
you're lucky enough to own one, many high-end
switches allow you to designate a
monitor port that
can see the traffic of all other ports. If you have such a switch,
you can install a server on that port for network monitoring, and
simply run Arpwatch on it.
After downloading Arpwatch, you can compile and install it in the
usual manner by running:
# ./configure && make && make install
When running Arpwatch on a machine with multiple interfaces,
you'll probably want to specify the interface on the
command line. This can be done by using the -i
command-line option:
arpwatch -i iface
As Arpwatch begins to learn the MAC/IP pairings on your network,
you'll see log entries similar to this:
Nov 1 00:39:08 zul arpwatch: new station 192.168.0.65 0:50:ba:85:85:ca
When a MAC/IP address pair changes, you should see something like
this:
Nov 1 01:03:23 zul arpwatch: changed ethernet address 192.168.0.65 0:e0:81:3:d8:8e
(0:50:ba:85:85:ca)
Nov 1 01:03:23 zul arpwatch: flip flop 192.168.0.65 0:50:ba:85:85:ca (0:e0:81:3:d8:8e)
Nov 1 01:03:25 zul arpwatch: flip flop 192.168.0.65 0:e0:81:3:d8:8e (0:50:ba:85:85:ca)
In this case, the initial entry is from the first fraudulent ARP
response that was received, and the subsequent two are from a race
condition between the fraudulent and authentic responses.
To make it easier to deal with multiple Arpwatch installs on a
switched environment, you can send the log messages to a central
syslogd [Hack #54], aggregating all the output
into one place. However, due to the fact that your machines can be
manipulated by the same attacks that Arpwatch is looking for, it
would be wise to use static ARP table entries [Hack #32]
on your syslog server, as well as all the hosts running Arpwatch.
| 
No comments:
Post a Comment