Tips for an Information Security Analyst/Pentester career - Ep. 37: ARP Spoofing

Computer networks work thanks to several protocols.

One of the most important network protocols is ARP (Address Resolution Protocol), converting IP addresses into MAC addresses.

The way it works is the following: a client needs to communicate with another client on the same network but it doesn't know its MAC address, it only knows its IP address.

The client sends a broadcast request with that specific information and the client that IP address was assigned to replies with its MAC address.

Both clients keep track of this learned information in their respective ARP tables.

 

Scenario

We have a local network with two clients (two virtual machines built based off Georgia Weidman's book), which are both assigned a static IP address in a bridged network configuration.

TARGET MACHINES

• Windows XP SP3:  192.168.1.61
• Linux Ubuntu 8.10: 192.168.1.85

These two clients communicate with each other.

ATTACKING MACHINE 

The attacker runs a Kali Linux machine sitting on the same network and sniffing the traffic on the 192.168.1.92 IP address.

The attacker would like to intercept all the traffic between these two machines but this is impossible in a normal switched network.

Of course, the graphs below are simplified, because our two target machines communicate with the router as well, but bear with me for the purposes of this demonstration.

This old but important protocol is totally based on trust. There is no security or non-repudiation implementations preventing either clients from lying.

Therefore, we're going to use an attack called ARP spoofing, in order to trick these machines to redirect all their traffic through Kali, realizing the below scenario.

Demonstration 

Connecting from Ubuntu to the FTP server installed on Windows XP,  we notice it uses a weak password.

However, none of these packets can be seen from the attacking machine, unless using promiscuous mode, because, in a switched network, each client receives only the traffic specifically intended for it.

In a real world environment, we couldn't have this option, and so we need to come up with a way to intercept this traffic.

ARP Spoofing attack

Kali holds a tool called arpspoof that we're going to use for this attack.

This tool will redirect the communication between our two clients to the attacking machine. We'll need to open two terminals: in the first one, we're going to use XP as a target and we're gonna make it believe we are the Ubuntu machine. 

In the second one, we're gonna do the opposite

But, before proceeding, we need to make sure the extraneous traffic we'll receive from one client will be redirected to the other one, otherwise we would cause a denial of service.

For this purpose, we need to edit the /proc/sys/net/ipv4/ip_forward  file by changing its value from 0 (false) to 1 (true).

With that being done, we're good to go with our attack.

The syntax for arpspoof is arpspoof - i <network interface to use> -t <target IP address>  <IP address we want to impersonate>

After performing our attack, if we run the arp command on our Ubuntu machine, we'll notice that the Windows XP machine results to have the same MAC address as the attacking Kali machine.

So, the attack was successful and, if we connect from Ubuntu to our FTP server on Windows XP, the attacker is able to view the whole traffic through Wireshark and also to retrieve username (georgia) and password (password).

At this point, we might be able to connect to the FTP server from Kali and grab any interesting files we might find.

In fact, we notice a file called financial_information.txt, we might be interested in having a look at.

As a matter of fact, I inserted a joke in there, because I would never store or send this type of information in clear text, but this scenario can be much more common than you might think. 

That's how breaches can happen.

This same attack can be performed between one machine and the router (or gateway). I chose not to do it because, especially in larger networks, it might take the gateway down and I needed a working internet connection for my demo.

Episode 38

Episode 36