Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: ICMP pokes holes in firewalls...
From: Darren Reed <avalon () caligula anu edu au>
Date: Fri, 26 Sep 2003 10:13:56 +1000 (Australia/ACT)

In some mail from bugtraq () hackerfactor com, sie said:

It seems like a fairly obvious hole, but I could find no mention of
anyone reporting it.
[...]
Here's the problem:
Because SRC does not know the route for the packet, ANY system
outside the firewall can reply via ICMP.  This means, an ICMP storm
can come inside the firewall. For a NAT router, the storm will be
directed at the specific SRC system.

I think you're missing an important ingredient in the mix here
and that is said firewall should be using the data returned in
the ICMP header to match up the correct outgoing state table
entry.  This should not allow through arbitrary packets but
restrict it to those that match the UDP source ports or ICMP
type/code/id#/seq#.

If it isn't doing at least that, then yes, there is a bigger problem.

So you can't just choose any random destination to do it from
but it might easily be possible if you know all that information
needed to send packets

An outbound UDP/IP packet can receive a response from either an ICMP,
UDP, or TCP packet.
(Note: I have not tested an inbound TCP packet.)

Then why say it can or might be possible ?

From what I can tell, the SMB Barricade treats TCP requests as
special, but everything else is considered to be the same.  So, an
outbound UDP connection can have anyone respond with an inbound UDP
or ICMP connection.

So what did you actually test and with what product exactly ?

I've never heard of the "SMB Barricade" before, but there are probably
lots of firewalls, these days, that I've never heard of, but as they
always say, "you get what you pay for".  Mind you, if you had to part
with more than ~$1000 for this, I'd say you were ripped off.

The risks?
- An ICMP storm can enter the firewall at whatever port traceroute uses.
  This is mainly a risk for hosts where traceroute can be triggered
  remotely.  For example:
   http://www.usqonline.com.au/sis/public/connection/PingTraceSelected.asp
   http://www.traceroute.org/  (Lots of hosts)
  You use their tool to kick-off a traceroute to your host.
  You receive the packet and determine the port number and IP address.
  You kick-off an ICMP storm against that IP/port.
  (Like a smurf attack, but with a specific port number.)
  As long as the firewall sees incoming traffic, it won't close the
  session handle.  Thus, you can attack any open traceroute server.

And you learn the various bits of information required to successfully
match how ?

- If you know that the host is behind a firewall but vulnerable to
  an ICMP overflow (e.g., ping-of-death), then you can target and attack.

I'm not sure "ping-of-death" is quite so simple as that but maybe I'm
forgetting something (like could it be achieved with packets other
than ICMP echo?).

Basically, a home firewall that does not manage connections at
layer-4 will be unable to stop this type of attack.

But even if it does, there are still "issues", although I'm not sure
if you've really considered them.


So, in summary, it sounds like you've found a considerably "weak"
product which I suppose is a good, general, heads up.

There's also a general problem here, that needs attention and that
is you really shouldn't allow more ICMP error packets through than
you see normal connection packets.  ie. one UDP packet out should
not allow more than one ICMP error message back in.  Having realised
this somewhat obvious flaw, I've fixed IPFilter.  It's relatively low
risk but IMHO it seems like the correct thing to do is limit packet
flow to matching packet counts.

Darren


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]