Message-ID: <200309260013.h8Q0Durp002847@caligula.anu.edu.au>
Date: Fri, 26 Sep 2003 10:13:56 +1000 (Australia/ACT)
From: Darren Reed <avalon@...igula.anu.edu.au>
To: bugtraq@...kerfactor.com
Cc: bugtraq@...urityfocus.com
Subject: Re: ICMP pokes holes in firewalls...


In some mail from bugtraq@...kerfactor.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

Powered by blists - more mailing lists