RE: ICMP attacks against TCP: Conclusions

[Fernando Gont <fernando () gont com ar>]

At 07:20 p.m. 26/07/2005, Craig Wright wrote:

No. The attacks are against TCP. You DoS the service by triggering an 
action on TCP, based on TCP's reaction to the corresponding ICMP messages.

How did you perform your tests?

Kindest regards,
Fernando Gont






> I will assume that you mean ICMP attacks against IP or the host as you
> are attacking the stack even if you are attempting to DoS the service
>
> I tested this hypothesis last night and the service was not slowed
> enough to be a successful attack
>
> CSW
>
> -----Original Message-----
> From: Fernando Gont [mailto:fernando () frh utn edu ar]
> Sent: 23 July 2005 11:53
> To: security-basics () securityfocus com
> Subject: 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.
>
> (Unless you think you'd enjoy having Darren Reed claim "I heard about
> the
> counter-measures years ago. This is old news" in a few years. :-) )
>
> Kindest regards,
>
> --
> Fernando Gont
> e-mail: fernando () gont com ar || fgont () acm org

--
Fernando Gont
e-mail: fernando () gont com ar || fgont () acm org