CSE644 ARP Cache Poisoning Attack Megha Jakhotia

The following provides the environment for this lab:

IP Address MAC Address

Attacker – SEEDUbuntu - M 10.0.2.7 08:00:27:b7:ba:af
A – SEEDUbuntu1 10.0.2.8 08:00:27:cd:2d:fd
B – SEEDUbuntu2 10.0.2.9 08:00:27:34:16:8b

Task 1: ARP Cache Poisoning

In this task, we attack A’s ARP cache such that B’s IP is mapped to Attacker’s MAC address in A’s ARP
Cache. We achieve this using 3 different methods as following:

Task 1A (using ARP request):

The following is the code to perform ARP Cache poisoning using spoofed ARP request to A:
CSE644 ARP Cache Poisoning Attack Megha Jakhotia

In the above code, we create an ARP packet with source address as B’s IP and M’s MAC and destination
as A’s IP and MAC address. The op field’s default value is used i.e. 1 indicating it’s an ARP Request. We
run the above code and see the packet sent out as:

The op who-has field indicates that it is an ARP request. The following show the ARP for A and B:

Normally, the ARP requests are broadcasted. However, we wanted to poison only A’s ARP Cache, so we
create a unicast message and send it to A. We see that we are successful in our attack.

However, the above code also creates an entry of our machine 10.0.2.7 in A’s ARP Cache. This might be
because the Ethernet header’s fields are filled by the OS based on the packet received. We revise the
code as following, by entering the Ethernet header’s fields:
CSE644 ARP Cache Poisoning Attack Megha Jakhotia

On running the code, we observe same result as before:

On the machine A and B, we see the following:

The entries are deleted before running the code and the two ARP results shown above are before and
after running the program. We see that, the above code no more results in storing Attacker’s entry in
the ARP Cache of A.
CSE644 ARP Cache Poisoning Attack Megha Jakhotia

Task 1B (using ARP reply):

The following is the code to perform ARP Cache poisoning using spoofed ARP reply to A:

The only change here is that the OP field is set to 2 i.e. ARP reply. Rest of the code is same. On executing
the program, we see the following packet is sent out:

The is-at string in op indicates that it is an ARP reply. The following is the ARP Cache entries in A and B:
CSE644 ARP Cache Poisoning Attack Megha Jakhotia

Task 1C (using ARP gratuitous message):

We spoof an ARP gratuitous message with B’s IP address using the following program:

On running the above program, we see that the desired packet is sent out:

The following shows the ARP cache before and after running the program:
CSE644 ARP Cache Poisoning Attack Megha Jakhotia

In the above output, we see that only A’s ARP Cache changes and even though B received the packet
(due to the packet being broadcasted on the network), B’s ARP Cache remains unchanged. This is
because the sender’s IP address matches B’s IP address and hence B assumes that the packet was sent
by it. The ARP Cache only consists of those IP address that does not belong to the host.

In these 3 ways, we can spoof an ARP packet and perform ARP Cache Poisoning.

Task 2: MITM Attack on Telnet using ARP Cache Poisoning

Step 1 (Launch the ARP cache poisoning attack).

The following provides the code to perform ARP Cache Poisoning on A and B, such that in A’s ARP cache,
B’s IP address maps to M’s MAC address, and in B’s ARP cache, A’s IP address also maps to M’s MAC
address:

The above code uses the ARP request method to perform ARP Cache Poisoning. The ARP Cache before
and after running the code on A and B, respectively, is as follows:
CSE644 ARP Cache Poisoning Attack Megha Jakhotia

The Wireshark capture show that the ARP request and replies are generated as follows:

Step 2 (Testing):

After performing the ARP Cache poisoning, we ping from A to B and see the following results:

We see that 12 packets are transmitted and only 3 are received. The Wireshark capture is as follows:
CSE644 ARP Cache Poisoning Attack Megha Jakhotia

The observation is that initially the ping was unsuccessful since there was no echo reply captured. After
some unsuccessful ping requests, there was an ARP request made from A for B’s MAC address. We see
that there was no ARP response seen for some time, and A continuously broadcasted an ARP request for
B’s MAC address. At the number 18, there was an ARP response from B and after that the Ping was
successful.

This was because A had M’s MAC address as B’s MAC address. This caused all the ping requests to go to
M and on receiving these ping requests, the M’s NIC card accepted these packets since they had M’s
MAC address on it. However, as soon as the NIC forwarded the packet to the Kernel, the kernel realized
that the packet’s IP address doesn’t match the IP address of the host and hence dropped the packet.
This caused the ping requests to be dropped and there was no ping reply from M or B (because B never
received the packet). After certain unsuccessful ping requests, A sent an ARP request and then B’s
original MAC address was received, over-riding the effect of our attack of ARP Cache poisoning. After
this the ping was successful.

Step 3 (Turn on IP forwarding):

We turn on IP forwarding and perform the attack again:

We ping B from A and see that our ping is successful:

CSE644 ARP Cache Poisoning Attack Megha Jakhotia

The following show the Wireshark capture of the ping:

The above shows that the ping request from A to B causes an ICMP redirect message from M to A.
Basically, whenever A ping B’s IP address, the packet is received by M. M realizes that it’s not meant for
it and sends this packet to B, but before forwarding it, it sends an ICMP redirect message to A telling it
that it has redirected the packet because it was destined for B and not M. On receiving the packet, B
then responds with an echo reply. Since B’s cache is also corrupted by M, M receives the packet and
then M sends an ICMP redirect message to B and forwards the packet to A, just as before.

The IP forwarding option enables M to forward the packet instead of dropping the packet.

Step 4 (Launch the MITM attack).

The following provides the code to launch an MITM attack after ARP Cache Poisoning on Telnet session:
CSE644 ARP Cache Poisoning Attack Megha Jakhotia

We first perform the ARP cache poisoning using the same code as before – in Task 2.1. We first keep the
IP forwarding on, so we can successfully create a Telnet connection between A to B. Once the
connection is established, we turn off the IP forwarding so that we can manipulate the packet. In order
to change the contents of the packet, we use the sniffing and spoofing approach and the above is the
code for the same. In the code, only for the packets sent from A to B, we spoof a packet such that all the
alphabetic characters of the original packet are replaced by Z. For packets from B to A (Telnet response),
we do not make any change, so the spoofed packet is exactly the same as the original one.

The following shows the output on Machine A telnetting to Machine B:

On typing alphabetic characters on A, they are replaced by Z. The numeric characters remain the same.

The Wireshark capture while typing in the characters on Terminal A is as following (with filter TCP):
CSE644 ARP Cache Poisoning Attack Megha Jakhotia

The Attacker’s terminal with all those steps are as following:

CSE644 ARP Cache Poisoning Attack Megha Jakhotia

We see that the typed in character ls is converted to ZZ and the numbers 123 are not converted. Hence,
we are able to perform Man-in-the-middle attack by performing ARP cache poisoning.

Task 3: MITM Attack on Netcat using ARP Cache Poisoning

The sequence of commands performed in this Task are similar to that of Task 2.4 with the only
difference of communicating with netcat instead of telnet. The following screenshot consists of the code
for performing MITM Attack on Netcat communication:

The above code sniffs for TCP traffic and if the traffic is from A to B, it replaces the string Megha with
AAAAA. If the data doesn’t contain ‘Megha’, then there is no change in the TCP payload. This packet is
then forwarded to the desired destination. The TCP traffic from B to A remains unchanged.

To run the above code after performing ARP Cache Poisoning and establishing the netcat session, we
run the following commands on the Attacker’s terminal:
$ sudo python3 Task2.1.py
$ sudo sysctl net.ipv4.op_forward=1 {to establish netcat session at A and B}
$ sudo sysctl net.ipv4.op_forward=0
$ sudo python3 Task3.py

The following is the output on Terminal of Machine A and B, respectively:

CSE644 ARP Cache Poisoning Attack Megha Jakhotia

Here, we see that the ARP cache is poisoned with M’s MAC address in B’s and A’s IP, respectively. B acts
as the server and A as the client. The first line is sent with IP forwarding on, indicating that the packet is
not manipulated and sent as it is. After turning IP forwarding on and running the program, we again
send a similar string and see that the string Megha at the client is replaced by AAAAA on the server. We
then send a line containing Megha from B to A, and see that it is not changed, as desired.

This indicates that we have achieved the MITM Attack on Netcat using ARP Cache Poisoning.

The above code replaces the name with a string of equal length containing As. In the code below, we
can replace the name with a string of arbitrary length (recalculating the length of IP packet):

We run the same commands as before on the Attacker’s terminal. The following provides the output on
machine A and B, respectively:
CSE644 ARP Cache Poisoning Attack Megha Jakhotia

After we send the string from B to A, it is directly displayed on A. The delay is caused due to an ARP
request initiated by B, and this happens because the connection freezes due to change in the packet
length in the previous packet from A to B. As soon as B receives an ARP reply, the effect of our ARP
cache poisoning will be erased, and the attack will no more be successful.