0% found this document useful (0 votes)
12 views16 pages

ICMP Redirect Lab Report

The document details an ICMP redirect attack and a subsequent MITM attack conducted by Gaurav Upadhyay, including code snippets and results from various commands like ping and traceroute. It discusses the limitations of the ICMP redirect attack when targeting remote or non-existing machines and outlines the configuration changes made to a malicious router container. The document concludes with observations on the effectiveness of using MAC addresses over IP addresses in the attack scenario.

Uploaded by

caggllayan47
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views16 pages

ICMP Redirect Lab Report

The document details an ICMP redirect attack and a subsequent MITM attack conducted by Gaurav Upadhyay, including code snippets and results from various commands like ping and traceroute. It discusses the limitations of the ICMP redirect attack when targeting remote or non-existing machines and outlines the configuration changes made to a malicious router container. The document concludes with observations on the effectiveness of using MAC addresses over IP addresses in the attack scenario.

Uploaded by

caggllayan47
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 16

Internet security

ICMP Redirect Lab

Name: Gaurav Upadhyay


Email: gsupadhy@syr.edu
Task1: Launching ICMP Redirect Attack
The code for ICMP redirect attack:

Now we ping destination from victim:


We perform traceroute at victim to see the results:

Now we run the ICMP redirect attack code from the attacker machine.
We us traceroute command again to see the result:

Also, we verify this with the ip route command:

Hence our ICMP redirect attack is successful.


Question1:
I was not able to apply ICMP redirect attack to redirect a remote machine.
The code to prove the claim above:

We run the code on attacker, while still pinging and using traceroute on victim
side to see the results:
We can confirm this by running ip route show cache command before and after
the attack to see the packet flow.
the packet flow was constant and did not change in either of the cases.

In order for attack to happen, the host needs to be on the same network.
Question2:
I was not able to apply ICMP redirect attack to redirect a non-existing machine.
The code to prove the claim above:

We run the code on attacker, while still pinging and using traceroute on victim
side to see the results:
We can confirm this by running ip route show cache command before and after
the attack to see the packet flow.
the packet flow was constant and did not change in either of the cases.

As the router is offline, there is no way to connect to it. Which is why the attack
didn’t work as it was intended to.
Question3:
Following are the entries for the malicious router container:
net.ipv4.conf.all.send_redirects=0,
net.ipv4.conf.default.send_redirects=0,
net.ipv4.conf.eth0.send_redirects=0.

1. ‘net.ipv4.conf.all.send_redirects=0’ command disables all IPv4 ICMP


redirected packets to be sent on all interfaces.
2. ‘net.ipv4.conf.eth0.send_redirects=0’ command disables all IPv4 ICMP
redirected packets to be sent on eth0 interface.
3. ‘net.ipv4.conf.default.send_redirects=0’ means that if either one of the above
two commands are set to enabled, the ICMP redirect are sent to the interface.
The changes made to docker-compose.yml file is as follows:

WE now changed the values inside the container, rebuilt the container and ran it
with the fresh new settings.
We observed that the malicious router enables all the IPv4 ICMP redirected
packets to be sent on all the interfaces along with eth0 interface. This way
whenever a new interface is added it is automatically sent the ICMP requests.
The results are shown below:
Task2: Launching the MITM Attack
First we ping the destination from the victim:
We run traceroute to see the results which are verified using ip route command:

Now we run the ICMP redirect attack code on attacker machine to see the
result:

We can see that the ICMP redirect has successfully happened.


We confirm this using the ip route command on victim side.
Now we create a netcat connection between the server (destination) and the
client (victim) on port 9090.

We turn off the IP forwarding:

MITM code:

Results:

Results can be seen while running the code on attacker router:


This shows that our attack has been successful. Due to MITM, the word
‘gaurav’ has been changed to ‘AAAAAA’ of equal length. Except that, other
words are the same.
Hence MITM through ICMP redirect has been successful.

Question 4:
WE can see that the attack is run only on one side and not both as I tried typing
in gaurav on the server side but it did not change on the victim side. But the
reverse was happening successfully.
Explanation:
Client sends messages only to the server and not viceversa, the direction of
packet flow is from, victim machine to malicious router to router to destination
machine.
Question 5:
1. First we use A’s Ip address: 10.9.0.5 in the Code:
We run the code and see the attack happening successfully. The packets are sent
continuously of length 7 regardless of the message beig sent. :
2. Now we use A’s MAC address: 02:42:0a:09:00:05
Code:

We run the code on malicious router and see the result as follows:

We observed that the malicious router sends only one packet at a time typed on
the victim side along with the length of the message typed with the attack.
To conclude, we can use the A’s MAC address instead of IP address as it does
not create unneccesary flooding where continuous TCP retransmission occurs.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy