Understanding Address Resolution Protocol Attacks
Copyright (c) 2006 cijfer <cijfer@netti!fi>
All rights reserved.
Table of Contents
1 About this paper
2 Introduction to ARP
2.1 What does ARP mean?
2.2 The purpose of ARP cache
2.3 How ARP works
2.4 Protocol flaws
3 ARP attack methods
3.1 Terms & definitions
3.2 Connection hijacking & interception
3.3 Connection resetting
3.4 Man in the middle
3.5 Packet sniffing
3.6 Denial of service
4 References & links
4.1 Documents
4.2 Software & programs
5 Greets
1 About this paper
In this particular paper, i will be discussing accordingly
a basic introduction to understanding Address Resolution
Protocol (ARP) as well as several methods of attack. These
methods . in no specific order . include detailed
explanations for hijacking and resetting a users connection
and/or session, man in the middle attacks, packet sniffing
on switched environments, and denial of service attacks
(DoS).
Concluding the introduction and other sections, i will give
several links to documents, software, and such to help aid
in further reference of ARP.
2 Introduction to ARP
2.1 What does ARP mean?
Address Resolution Protocol (ARP) . a stateless protocol .
was designed to map Internet Protocol addresses (IP) to
their associated Media Access Control (MAC) addresses. This
being said, by mapping a 32 bit IP address to an associated
48 bit MAC address via attached Ethernet devices, a
communication between local nodes can be made.
On a majority of operating systems . such as Linux, FreeBSD,
and other UNIX based operating systems, and even including
Windows . the "arp" program is present. This program can be
used to display and/or modify ARP cache entries. By simply
running "arp -na" in your terminal, a list of current
entries in the local ARP cache will show. This includes IP
addresses, hardware types, MAC (HWaddress) addresses, flag
masks, associated NIC interfaces, and link types (output
may vary depending on system).
An example of the "arp" utility's output would look like the
following:
Windows:
> arp -a
Interface: 192.168.1.100 .- 0x10003
Internet Address Physical Address Type
192.168.1.1 00-13-10-23-9a-53 dynamic
Linux:
$ arp -na
? (192.168.1.1) at 00:90:B1:DC:F8:C0 [ether] on eth0
FreeBSD:
$ arp -na
? (192.168.1.1) at 00:00:0c:3e:4d:49 on bge0
You will notice also that on the Windows example, the Type
for that particular entry is labeled as "dynamic". Dynamic
entries in the ARP cache are eligible to be purged from the
cache. This is avoidable if the entry is labeled as static
or permanent which is self explanatory by its name. I will
get into static ARP entries near the end of this paper.
2.2 The purpose of ARP cache
As stated in section 2.1, the Address Resolution Protocol
was designed to map IP addresses to MAC addresses. ARP uses
a cache to keep track of these addresses in a table known as
the ARP cache. The ARP cache . like any other cache . has
data stored only temporarily. The average amount of time
that data is stored in this cache, is normally between 1
minute to 10 minutes. The Time to Live (TTL) however can be
much greater than that, such as with Cisco routers, which
have an estimate TTL of 4 hours. Each system has a different
TTL period until non-permanent data is cleared - Previous
cache entries which are obsolete and not used waste space
and have no purpose being there. Therefore, entries are
either updated or purged from the cache completely.
As stated, the ARP cache has a job to maintain ARP replies
and data. To reduce the amount of ARP cache entries, the ARP
cache updates with the newly received IP addresses and
corresponding MAC address. It does this as a method of
reducing network traffic. If i were to map the hardware
address of another node on my local network, the ARP cache
holds its entry in the cache so i do not have to
continuously map it out during my communication.
2.3 How ARP works
Specifically for Internet Protocol Version 4 (IPv4), ARP
maps IP addresses between the Network layer and Data Link
layer of the Open System Interconnection (OSI) model.
The Data Link layer is split into two sublayers, The Media
Access Control layer, and the Logical Link Control layer.
The MAC layer has the power to control access to data flow
and whether or not transmission is permitted. The Logical
Link Control layer's job however is to control frame
synchronization, packet flow (like MAC), and error checking
throughout data packets. These two sublayers work together
to create the Data Link layer.
The next step for successful packet transmission is the most
important. Transmission itself. The Network layer provides
the switching and routing by transmitting data between nodes
on a network. Not only is packet transmission a part of this
layer, but also addressing, internetworking, error handling,
and packet sequencing. This layer ensures that each packet
is sent accordingly to their final destinations without
errors and possible collision.
For a more complete and thorough explanation of how address
resolution works, and protocol specifics, please consult RFC
826 (David C. Plummer, 1982). RFC 826 was written in 1982 by
C. Plummer, and is considered to be outdated and complicated
material to the neophytes. Consult the end of this paper in
section 5.1 for links to papers regarding ARP, MAC, and
further discussions on ARP based attacks.
2.4 Protocol flaws
ARP's main flaw is in its cache. Knowing that it is possible
for ARP to update existing entries as well as add to the
cache, this leads one to believe that forged replies can be
made, which result in ARP cache poisoning attacks. I will
discuss each type of attack in section 3 as well as terms
and definitions reviewed in section 3.1.
3 ARP attack methods
3.1 Terms & definitions
A. ARP Cache Poisoning
Broadcasting forged ARP replies on a local network. In a
sense, "fooling" nodes on the network. This can be done
because ARP lacks authentication features, thus blindly
accepting any request and reply that is received or sent.
B. MAC Address Flooding
An ARP cache poisoning attack that is mainly used in
switched environments. By flooding a switch with fake MAC
addresses, a switch is overloaded. Because of this, it
broadcasts all network traffic to every connected node.
This outcome is referred to as "broadcast mode" because,
all traffic passing through the switch is broadcasted out
like a Hub would do. This then can result in sniffing all
network traffic.
3.2 Connection hijacking & interception
Packet or connection hijacking and interception is the act
in which any connected client can be victimized into getting
their connection manipulated in a way that it is possible to
take complete control over.
Those whom may be vulnerable to this type of attack, usually
connect to servers and computers via unencrypted protocols
such as Telnet or Rlogin. This can result in sniffing, as
well as connection hijacking and interception.
3.3 Connection resetting
The name explains itself very well. When we are resetting
a client's connection, we are cutting their connection to
the system. This can be easily done using specially crafted
code to do so. Luckily, we have wonderful software that was
made to aid us in doing so.
One piece of code that is extremely easy to use to do this,
is within the DSniff collection. To pull this off, we're
going to use 'tcpkill'. TCPKill's usage is similar to that
of TCPDump, both using BPF (Berkeley Packet Filters).
Cause:
1. tcpkill -9 port ftp &>/dev/null
2. tcpkill -9 host 192.168.10.30 &>/dev/null
3. tcpkill -9 port 53 and port 8000 &>/dev/null
4. tcpkill -9 net 192.168.10 &>/dev/null
5. tcpkill -9 net 192.168.10 and port 22 &>/dev/null
Effect:
1. Kill connections attempting to access port 21 (ftp)
2. Kill connections matching the IP '192.168.10.30'
3. Kill connections attempting to access port 53 and 8000
4. Kill connections 192.168.10.* (192.168.10.0/24)
5. Kill connections 192.168.10.* accessing port 22
TCPKill is mainly used to continously keep the connection of
the client cut. By simply killing the 'tcpkill' process
after use, will allow the connection to become available
again. If not, then the remote client will cease to be able
to connect.
3.4 Man in the middle
One of the more prominent ways of attacking another user in
order to hijack their traffic, is by means of a Man In The
Middle (MITM) attack. Unlike the other attacks, a MITM is
more a packet manipulation attack which in the end however
does result in packet redirection to the attacker . all
traffic will get sent to the attacker doing the MITM
attack. This attack however is specific. As opposed to MAC
Address Flooding or other attacks against a router/switch,
the MITM attack is against a victim, and also can be done
outside of a switched environment. Thus meaning, an attack
can be executed against a person on the other side of the
country . to be more thorough.
Downsides of a MITM attack is the fact that the victim must
be connected via an unencrypted protocol. Utilities such as
Telnet, and Rlogin can be attacked via MITM attacks. There
also is the possibility of executing a MITM attack against
encrypted protocols . such as SSH - but I will not get into
that in this paper.
A MITM attack could be of great use on operating systems
such as SunOS/Solaris and IRIX, due to the fact that one of
the main modes of connection to these operating systems
happens to be Telnet and Rlogin. Rarely do i see the older
versions of these operating systems using SSH.
A basic MITM attack consists of an attacker, victim and
the target/destination that the victim is communicating
with. Using a visual representation of this attack would be
a lot more confusing, so I'm just going to subtly explain
what is occurring when doing this specific attack. But
before i begin explaining that, we need to do one thing:
Enable IP forwarding if not already default.
Linux:
# echo 1 > /proc/sys/net/ipv4/ip_forward
Other:
# sysctl -w net.inet.ip.forwarding=1
-OR-
edit /etc/sysctl.conf
To double check whether or not IP forwarding is enabled,
you can simply do the following commands:
Linux:
# cat /proc/sys/net/ipv4/ip_forward
Other:
# sysctl -A | grep net.inet.ip.forwarding
If the value is set to "1", then IP forwarding is enabled.
Continuing on, we're going to do this also using third party
utilities. A suggestion for easy usage would be using the
"arpspoof" utility by Dug Song within his DSniff package.
One of the good reasons about the "arpspoof" utility, is the
fact that its extremely simple to use and requires only two
arguments. Information needed in order to use it, is the
Victim's IP address, and the Target/Destination IP address
that Victim is trying to authenticate with. With these two
IP addresses, we can continue with our MITM attack. A simple
example of what "arpspoof" will do is as followed:
1. Communicate with Victim saying that you're Destination.
2. Communicate with Destination saying that you're Victim.
This can be easily done by using the following syntax via
"arpspoof" and two open terminal windows. But before i get
into that, i just want to make clear about the example IP
addresses being used:
Setup:
Attacker (IP: 2.2.2.2)
Victim (IP: 1.1.1.1) <-> Target (IP: 0.0.0.0)
Term A:
# arpspoof -t 1.1.1.1 0.0.0.0 &>/dev/null &
# arpspoof -t 0.0.0.0 1.1.1.1 &>/dev/null &
Term B:
# dsniff | less
-OR-
# ngrep host 1.1.1.1 | less
-OR-
# tcpdump host 1.1.1.1 and not arp | less
If everything went successfully, then by using one of the
three optional programs in Term B, you should be able to
sniff all traffic that is being sent between Victim and the
Target/Destination.
If at all something did not go as planned, then there could
be several reasons. One reason could be that the Victim has
static ARP tables . which deny the overwriting of entries
within the ARP cache table. Another possible reason could be
a detection system of some sort such as ARPWatch which is an
ethernet/ip monitoring system. As a reminder, this specific
MITM attack will not work on encrypted protocols . explained
in this section at paragraph 2.
3.5 Packet sniffing
Sniffing on a Local Area Network (LAN) is quite easy if the
network is segmented via a hub, rather than a switch. The
sole difference, is that a switch is organized when sending
packets, thus entitled "switch" because it switches packets
between destinations respectively. A hub on the other hand
broadcasts packets throughout the entire network blindly and
freely without any specific destination.
It is of course possible to sniff on a switched environment
by performing a MAC flood attack. This is vaguely explained
in section 3.1b on MAC Address Flooding.
As a result of the MAC flood, the switch will act as a hub,
and allow the entire network to be sniffed. This gives you a
chance to use any sort of sniffing software available to you
to use against the network, and gather packets. A few
popular sniffing software and programs include: DSniff by
Dug Song, LinSniffer (one popular version is LinSniffer
0.666 by humble of rhino9), PHoss by FX and Ettercap by
Alberto Ornaghi, and Marco Valleri.
Example output from PHoss:
[root@genii sniff]# ./PHoss
PHoss (Phenoelit's own security sniffer)
(c) 1999 by Phenoelit (http://www.phenoelit.de)
$Revision: 1.13 $
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Source: 192.168.1.100:40895
Destination: 72.14.0.99:80
Protocol: HTTP
Data: asrtrin:manheim
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Source: 192.168.1.105:46537
Destination: 72.14.0.99:21
Protocol: FTP
Data: buddy:holly
[...]
Example output from TCPDump 3.9.4 (output is not identical):
[root@genii sniff]# tcpdump -vvX port 21
tcpdump: listening on eth0, link-type EN10MB (Ethernet),
capture size 96 bytes
[...]
00:45:40.370082 IP (tos 0x0, ttl 111, id 43980, offset 0,
flags [DF], proto: TCP (6), length: 57) localhost.pirhana >
localhost.ftp: P, cksum 0x434b (correct), 1:18(17) ack 38
win 17483
4500 0039 abcc 4000 6f06 79e6 44ad 954f E..9..@.o.y.D..O
5056 bbb9 11f9 0015 6595 ed3d 6f7f 82e1 PV......e..=o...
5018 444b 434b 0000 5553 4552 206d 7975 P.DKCK..USER.myu
7365 726e 616d 650d 0a sername..
[...]
Note that we now have a username, which is 'myusername'.
[...]
00:45:42.467487 IP (tos 0x0, ttl 111, id 43985, offset 0,
flags [DF], proto: TCP (6), length: 57) localhost.pirhana >
localhost.ftp: P, cksum 0x3e34 (correct), 18:35(17) ack 72
win 17449
4500 0039 abd1 4000 6f06 79e1 44ad 954f E..9..@.o.y.D..O
5056 bbb9 11f9 0015 6595 ed4e 6f7f 8303 PV......e..No...
5018 4429 3e34 0000 5041 5353 206d 7970 P.D)>4..PASS.myp
6173 7377 6f72 640d 0a assword..
[...]
And now a password, which is 'mypassword'. But is this login
a valid one?
[...]
00:45:42.473412 IP (tos 0x0, ttl 64, id 53228, offset 0,
flags [DF], proto: TCP (6), length: 62) localhost.ftp
> localhost.pirhana: P, cksum 0xae1b (correct), 72:94(22)
ack 35 win 5840
4500 003e cfec 4000 4006 84c1 5056 bbb9 E..>..@.@...PV..
44ad 954f 0015 11f9 6f7f 8303 6595 ed5f D..O....o...e.._
5018 16d0 ae1b 0000 3533 3020 4c6f 6769 P.......530.Logi
6e20 696e 636f 7272 6563 742e 0d0a n.incorrect...
[...]
It was not :(. But we'll know when we get a valid one :)).
3.6 Denial of service
Denial of service is just lame. Try not to do it unless you
absolutely must unless for penetration testing. Denial of
service is self explanatory. Denial of service attacks can
occur when large amounts of unsolicited packets are targeted
against a specific host and/or optionally on specific ports.
This may result in the remote node to panic and close the
port (denying its service), or even shutting down the entire
system - possibly a reboot.
As explained in section 3.1b, MAC Address Flooding can be
considered a Denial of service attack. The main idea of the
MAC flood, is to generate enough packet data to send toward
a switch, attempting to make it panic. This of course will
cause the switch to drop into broadcast mode and broadcast
all packet data. This however did not result in a crash, or
the service to be dropped, but to be overloaded.
For further information on MAC Address Flooding, please read
back to section 3.1B on its definition.
4 References & links
4.1 Documents
1. http://ietf.org/rfc/rfc826.txt
2. http://networksorcery.com/enp/protocol/arp.htm
3. http://man.he.net/?topic=arp§ion=all
4.2 Software & programs
1. ARP0c2 - http://phenoelit.de/arpoc/
2. Dsniff - http://monkey.org/~dugsong/dsniff/
3. Ettercap - http://ettercap.sourceforge.net/
4. Hunt - http://packetstormsecurity.org/sniffers/hunt/
5. Ngrep - http://ngrep.sourceforge.net/
6. PHoss - http://phenoelit.de/phoss/docu.html
7. Shijack - http://securiteam.com/tools/5QP0P0K40M.html
8. Tcpdump - http://tcpdump.org/
5 Greets
x80, thank you for proof reading.
_EOF_
# milw0rm.com [2006-04-08]
