Wednesday, May 26, 2010

Spoofing ICMP redirect host messages with hping

An icmp redirect host message can be sent from any router on the same broadcast segment as the end host that "needs redirection".     Modern network infrastructures will typically have a single router gateway address per subnet however it is possible to have more than one router in a segment making the operational case for ICMP redirect messages.

An ICMP redirect host message has ICMP type 5, code 1.    The ICMP redirect network code is 0.  There also exists redirect with Type of Service (ToS) for both network and host (codes 2 and 3).

With the advent of classless Internet domain routing (CIDR, RFC 1518/1519 in 1993), an end host cannot readily determine the network class and thus ICMP type 5, code 0 is basically useless.  RFC 1812 additionally states that a router should not generate type 5, code 0.   While working on this post, I observed that a Windows host will accept code 0 and treat it the same as code 1 adding a /32 route to the table. 

Because IP source address spoofing is trivial, ICMP redirect message abuse potential exists.   The only specific limitation is that the "new" destination gateway address of the redirect message must exist within the same subnet as the end host itself.

The ICMP redirect use case would most likely be employed in a network penetration testing scenario whereby extensive layer 2 security features are enabled limiting the effectiveness of layer 2 attacks such as ARP cache poisoning and rogue DHCP server use.    The primary goal being to intercept traffic for a specific destination address.

The end host must be configured to accept ICMP redirect messages and update its routing table accordingly.   Within Microsoft Windows, there is a registry key that enables the acceptance of ICMP redirect messages.  This DWORD registry key has a default setting of 0x0001, that being the "enabled" state.

HKLM\System\CurrentControlSet\Services\Parameters\Tcpip\EnableICMPRedirect

Based on my reading, I believe some implementations of the Microsoft TCP/IP stack also read the plural form of this key "EnableICMPRedirects" rather than the singular form, so it is possible that both keys exist.

With regard to the Windows XP firewall, it will block all ICMP requests in its default configuration state.  Of course, there may be site wide group policy that changes this situation for legitimate operational reasons such as multiple router gateways existing in a single segment.    If you wish to experiment, and enable 'icmp redirect' from the command line, there are two useful 'netsh' commands as follows:

C:\> netsh firewall show icmpsetting

shows the current state of ICMP acceptance if any.  A blank output indicates that no ICMP policies are in effect.

C:\> netsh firewall set icmpsetting type=5 mode=enable

will enable the acceptance of ICMP redirects through the firewall.


The Linux kernel has two settings that control ICMP redirect acceptance behavior.   For the 'eth0' interface, these settings are as follows:

/proc/sys/net/ipv4/conf/eth0/accept_redirects
/proc/sys/net/ipv4/conf/eth0/secure_redirects

If "secure_redirects" is enabled, the Linux system will only accept ICMP redirects that are redirected to a default gateway that is already listed in the routing table.   This is the default in most modern linux distributions and is an effective defense against spoofing attempts.

'accept_redirects' is enabled as the default also.   If the 'secure_redirects' kernel parameter is set to 0, then the linux kernel is susceptible to an ICMP host redirect attack in the same way that a Windows system is susceptible.    The one thing to note is that the linux kernel will not show the accepted route in the routing table that is listed through 'route show' or 'netstat -nr' commands, even though the route is in effect.


Our scenario below is laid out as follows:

Attacker IP Address: 172.16.235.99
Legitimate Router Gateway: 172.16.235.1
Victim IP Address: 172.16.235.100

The legitimate DNS server address is 10.1.1.1.

We can use ICMP redirect host to insert a new route table entry for the 10.1.1.1 address as follows:

hping -I eth-dest -C 5 -K 1 -a 172.16.235.1 --icmp-ipdst 10.1.1.1 --icmp-gw 172.16.235.99 --icmp-ipsrc 172.16.235.100 172.16.235.100

whereby:
-I eth-dest is the destination ethernet interface on the attacker to send the packets out of/from.
-a is the spoofed source address of the legit. router gateway
--icmp-ipdst is the new route table entry address you want to create
--icmp-gw is the new route destination address/gateway you want to create and must live within the same subnet as the victim.
--icmp-ipsrc must match the source address of the victim to pass sanity checking

If you check the route table on the victim using "netstat -nr" or "route print" after executing this command from the attacker, you should see a new route table entry.   Since MS-Windows will readily accept these new route table entries, many ICMP redirects can be generated with random IPv4 prefixes to perform a denial of service against the target.   A /32 host route learned via an ICMP redirect message will remain in the routing table for 10 minutes.

In this example, we assumed that the attacker was on the same subnet in order to receive / intercept the traffic.   In other words, the attacker would also be a DNS server ready to serve some bogus response to the victim.    The attacking host could well be a different machine on another network, but the "man in the middle" host or "router gateway" if you like needs to remain on the same subnet in order to receive the traffic.

1 comment:

Faithless Destiny said...

My thesis project is about a penetration testing platform,and I didn't pay the necessary attention to that functionality for ICMP redirect messages...

I was doing the MITM with a double ARP spoofing (1 for the target, 1 for the gateway) then I set up a sniffer with filter capabilities, but with this I can skip the ARP spoofing threads.

Thanks