‘ICMP Attacks Against TCP’
‘The information has been provided by Fernando Gont.’
Recently, awareness has been raised about several threats against the TCP protocol, which include blind connection-reset attacks. These attacks are based on sending forged TCP segments to any of the TCP endpoints, requiring the attacker to be able to guess the four-tuple that identifies the connection to be attacked.
While these attacks were known by the research community, they were considered to be unfeasible. However, increases in bandwidth availability, and the use of larger TCP windows have made these attacks feasible. Several general solutions have been proposed to either eliminate or minimize the impact of these attacks. For protecting BGP sessions, specifically, a counter-measure had already been documented in, which defines a new TCP option that allows a sending TCP to include a MD5signature in each transmitted segment.
All these counter-measures address attacks that require an attacker to send forged TCP segments to the attacked host. However, there is still a possibility for performing a number of attacks against the TCP protocol, by means of ICMP. These attacks include, among others, blind connection-reset attacks.
This document aims to raise awareness of the use of ICMP to perform a number of attacks against TCP, and proposes several counter-measures that can eliminate or minimize the impact of these attacks.
A set of tools for this family of vulnerabilities was release, for more information see: ICMP Attack Tools
The attacks are blind, so the attacker does not need to be a ‘man in the middle’ to perform then. The typical number of packets required to perform any of these attacks is about 16000 (in many cases, the attacker requires fewer packets). This means that even when a 128kbps link, it will take the attacker much less than a minute to perform them.
What are the affected applications?
Well, the first one that may come to your mind is BGP, but there are others. For example:
* Proxies (either transparent, or not)
Let’s say we want to prevent users from accessing the web site 192.168.0.1. If the web proxy address is 10.0.0.1, we can attack it and run any of the tools like: icmp-xxxx -c 10.0.0.1:1024-65535 -s 192.168.0.1:80 -t server
With this attack, all the clients that are using the proxy 10.0.0.1 cannot access the webserver at 192.168.0.1
Think about two major e-mail providers. Let’s say one is 10.0.0.1, and the other one is 192.168.0.1. Let’s DoS the mail transfers from 10.0.0.1 to 192.168.0.1: icmp-xxxx -c 10.0.0.1:1024-65535 -s 192.168.0.1:25 -t client
Let’s also DoS the mail transfers from 192.168.0.1 to 10.0.0.1: icmp-xxxx -c 192.168.0.1:1024-65535 -s 10.0.0.1:25 -t client
NATs will usually make all the hosts in your network use one (or a few) IP address(es) for their TCP connections. By performing the attack against the IP address of the NAT box trying all the possible port number combinations, you would be attacking the TCP connections of all the clients behind the NAT.
And the list could continue….
Even only one attacker with broadband access can perform these attacks, as discussed above.
Not to mention what could happen if someone had the idea to include these attack tools in an Internet worm.
Wasn’t this simple? Isn’t this something that should be fixed?
Otherwise, read the draft at http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html , send it to your vendor, explain it to them, and ask them to fix their OS.
* The TCP MD5 option does not protect you from these attacks
* IPSec does not protect you from these attacks
* You cannot filter all ICMP messages
* Relying on fragmenttion has many potential problems (read Mogul’s ‘Fragmentation considered harmful’ classic, or the recent Matthis’ ‘Fragmentation considered very harmful’)
* The minimum IPv4 MTU is 68. If you ignore ICMP messages that claim MTU’s lower than X (where X>68), then there’s a high chance your TCP connections may stall
The full whitepaper can be found at: Internet-Draft – ICMP attacks against TCP(December 2004)‘