[Full-disclosure] ICMP attacks against TCP: Conclusions

Folks,

My posts to this list have tried to show how easy it is to perform ICMP
attacks against TCP.

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 I don't want my users to access the web site at 192.168.0.1. If
  the proxy address is 10.0.0.1, I can run any of the tools as:

icmp-xxxx -c 10.0.0.1:1024-65535 -s 192.168.0.1:80 -t server

With this attack, I would be messing with all the clients that are using
the proxy 10.0.0.1 to access the webserver at 192.168.0.1

• Mail
  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
  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.

Some readers have argued why I try to "sell" my internet-draft again and
again. The answer is simple: 8 people out of 10 of every discussion I have
had on these issues have misunderstood the problem, and how it should be fixed.

Let's name a few:

• 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 recen 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

Big vendors' employees making misleading claims to the press have certainly
not helped to make people patch their systems, or push their vendors to
produce patches.

Those guys that have started nonsensical discussions about whether this is
new or not have not helped, either. And have not realized that the
discussion should be whether "this is current", rather than whether "this
is new".

I have received almost no feedback from "vendors". Unfortunately, they
don't realize that ICMP is a core protocol, and that discussion on the
counter-measures is needed for the benefit of us all.

Last, but not least, the IETF specifications need to address these issues.
If vendors patch their systems, but the IETF specifications are not
updated, there's a high chance that there will be brand-new vulnerable
implementations in the near term.

Get involved. Discuss the counter-measures. Get your vendor fix the
problems. And ask how they are fixing them (what if they just didn't
understand, and are not really protecting you, or causing more harm than
good?).

And have the specs address these issues. That's the real and final fix for
these issues.

Kindest regards,

–
Fernando Gont
e-mail: [email protected] || [email protected]

---

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/