ARP spoofing and insecure protocols

We have heard of ARP spoofing for a long time in various forms. For instance, I learned about this during my bachelor’s in computer engineer when I was staying at the college dorm. Some students used to trouble us by using a tool netcut that performs ARP poisoning and disrupts one’s internet connection. This is also an example of ARP spoofing. Likewise, we hear that we should be aware of our security and privacy while working in public wifi in places such as cafes, parks, etc. This is because one can perform man-in-the-middle attacks and can violate your security and privacy. In this post, I will relate ARP spoofing and insecure protocols.

Furthermore, we should avoid using insecure protocols like HTTP, FTP, Telnet, etc. unless one is in a situation of “do or die”. Thus, at the end of the post, I will also mention some of the methods that we as network owners can do to avoid such attacks.

[Disclaimer]: This post is just for educational purposes and doesn’t encourage performing MITM attacks. Performing MITM attacks is illegal and doing so can lead to litigation. Only use this post as a resource to avoid being a victim.

Brief introduction to ARP

ARP stands for Address Resolution Protocol. Before understanding ARP, we need to understand how a network works. Let’s see the OSI model of a networking system.

OSI Model

We are interested in the data link layer and network layer. For example, when we request data from Google, the following happens:

  1. The gateway (i.e. switch or your home router) broadcasts an ARP packet to find who is sending the request.
  2. The device that has the IP address responds with its MAC address.
  3. The device sends the data encapsulating its MAC address in the source and the gateway’s MAC address in the destination.
  4. The router then encapulates the information of the IP address and sends the packet.
  5. The reverse happens in the receiving end as well.

Let’s see this in a TCP packet from Wireshark.

A TCP segment in Wireshark

We can see from the screenshot above that, at the data link layer, the communication happens between MAC addresses and in the Internet layer, it happens via IP addresses. Now, as I said earlier, a host this sending or receiving the information will broadcast an ARP message in the network. And, everyone can do the same. In the best case, the correct device that has the IP address will respond. However, if the device is malicious, it will respond with the MAC address of the victim as its own. Furthermore, each device on the network has an ARP cache to reduce the broadcast. I will explain this with a real example setup.

Demonstration of ARP spoofing

To demonstrate the ARP spoofing, I have set up three VMs in a NAT Network of my Virtual Box as follows.

VMMAC AddressIP AddressRole
Kali08:00:27:a6:1f:8610.0.0.4Server (SSH, telnet)
Fedora08:00:27:c5:70:ab10.0.0.24Victim
Parrot08:00:27:9d:ed:f010.0.0.23Attacker
Gateway52:54:00:12:35:0010.0.0.1Gateway
VMs on the NAT

Normal workflow

So, I will be using bettercap to perform ARP spoofing and listening on the Wireshark on the Attacker (i.e. Parrot). Hence, I will clean the arp entry for the gateway and without the ARP spoofing, I will hit my website. At this moment, I have promiscuous mode enabled that allows intercepting another host’s traffic as well. This is enabled just to show you the TCP request. I will disable this while performing the attack.

sudo arp -d 10.0.0.1; curl https://nepcodex.com
Wireshark snip

The communication of Fedora with my website must happen through a gateway. All of the hosts know the IP address of the gateway. Hence, they request the gateway first. But in my case, I just deleted the arp entry of it. Hence, it must send a broadcast message. You can see that the broadcast message said “Who has 10.0.0.1? Tell 10.0.0.24”. As we know, 10.0.0.1 is the gateway and 10.0.0.24 is the requesting host, Fedora. Then, on line 268, the gateway replied with its mac address. Hence, Fedora now knows the MAC address of the gateway, and hence, encapsulates it to the frame as follows.

TCP stream up

Now, the data is received the same way as evident from the screenshot below.

TCP stream down

So, this is the normal flow. Now, let’s spoof using Parrot as follows.

Use bettercap to sniff

Start spoofing

Reference: https://www.bettercap.org/usage/interactive/

Now that I have disabled the promiscuous mode from VMs’ Network settings, let’s see the ARP packets on Wireshark.

ARP packets after spoofing

Here, we can see that the attacker is sending its reply every few milliseconds so that it has the IP address of the gateway. Hence, other devices will send their data to Parrot’s MAC (08:00:27:9d:ed:f0) instead of the real gateway’s MAC ( 52:54:00:12:35:00). So, if Fedora requests an insecure website, I will still see the TCP packets.

Victim requests an insecure website

Here, the fedora user hits an insecure website. Since ARP spoofing is enabled, we will see the content in the attacker machine Parrot.

Request captured in Wireshark of the attacker’s machine.

So, if you send a username and password to an HTTP site, it can easily be captured. Not only this, but we can also recreate the response.

Follow TCP stream
Response of the request

However, if it were HTTPS, this would be encrypted and of no use to an attacker.

HTTPS stream

SSH vs Telnet

The similar is true for other insecure protocol like Telnet.

Telnet data comes in 1 byte

If we check other segments, we will see the remaining data ‘a’, ‘l’, ‘i’, that is my username. And the same goes for password.

TCP stream shows the username and password.

For example, if I do sudo apt update, this will also be captured along with the password.

TCP stream

This is why we don’t use telnet in real application. Let’s see what happens if it were SSH.

TCP stream of SSH

Like I said earlier, the text is encrypted (. is a blank space). This in fact is the data when the user logged in. Now, even the attacker has control over this, he cannot make anything from it.

Prevention from ARP Spoofing

Up to now, we learned about ARP spoofing. However, we must be able to prevent ourselves from being victims of the same. We can do the following to prevent the attack.

  1. Never log into websites in untrusted networks. This has other reasons too. I will try explaining other spoofing mechanisms in future.
  2. Avoid using insecure protocols like HTTP, Telnet, FTP, etc. Use SFTP instead of FTP , SSH instead of Telnet and HTTPS instead of HTTP.
  3. If you are a network owner, add a static ARP entry to your switch or home router so that the attacker cannot impersonate the gateway preventing from fullduplex mode. However, the attacker still can spoof the other hosts. In public wifi, it is impossible to add static ARP entries for all devices.
  4. Better switches prevent ARP poising using techniques like Dynamic ARP Inspection (DAI). This can help for a large scale network.
  5. Try smaller subnets. For example, if there are three blocks in a building, try a single subnet for each block. Since ARP only applies to a subnet, this will help identifying the culprit.

Learn more about subnetting from here.

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x