Date: Sat Jul 23 14:25:21 2005
From: phased at mail.ru (phased)
Subject: ICMP attacks against TCP: Conclusions

You have made your point, everyone gets it, shut the fuck up now please, if you are that concerned contact every vendor yourself instead of spamming this list every two seconds.

-----Original Message-----
From: Fernando Gont <fernando@....utn.edu.ar>
To: bugtraq@...urityfocus.com,full-disclosure@...ts.grok.org.uk
Date: Fri, 22 Jul 2005 22:50:45 -0300
Subject: [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: fernando@...t.com.ar || fgont@....org
> 
> 
> 
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 

Powered by blists - more mailing lists