ICMP pokes holes in firewalls...

[<bugtraq@xxxxxxxxxxxxxxxx>]

It seems like a fairly obvious hole, but I could find no mention of
anyone reporting it.

Traceroute uses two protocols: UDP and ICMP
The outgoing packet is either UDP or ICMP with variable TTL (time to
live). If the packet times out before reaching it's target, then the
last router returns an ICMP "time-to-live exceeded".

So, here's the situation:
A system inside a firewall (SRC) performs a traceroute to a system
outside the firewall (DST).

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.

Making matters worse...
(1) Most home firewall solutions (e.g., SMC Barricade 7004 series,
Linksys Etherfast, NetGear home routers) do not distinguish the
protocol.  They are layer-3 (IP), not layer-4 (TCP/UDP) animals, they
do not distinguish between protocols.

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.)
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.


(2) Traceroute chooses the next available UDP port.
(Big IF, low risk)  IF the router supports reverse-NAT (aka port
forwarding) and IF the outbound UDP port matches the port forwarding,
and IF SRC is not the same as the reverse-NAT port destination, then
the traceroute will fail.

This is what I was originally tracing:
  My firewall (SMC Barricade 7004BR) has a reverse-NAT for
  port 23456 to host 10.10.10.2.
  Host 10.10.10.1 was doing a few traceroutes.
  One of the traceroutes failed completely.
  But, my ethereal captured both the outbound and inbound packets.
  There was a reply, but 10.10.10.1 did not see it.
  Why?  Because traceroute chose port 23456/UDP.
  Host 10.10.10.2 was running snort (total dumb luck) and it caught
  the inbound ICMP packets that should have gone to 10.10.10.1.


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.

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

- Depending on the router, this may also work with TCP.
  (I don't see why it wouldn't work...)

- Then again, why wait for a traceroute?
  Use any known service, such as ICQ, NetMeeting, or iVisit.
  These are UDP services that open the firewall for inbound traffic.
  Find anyone already connected.
  They are vulnerable to the same ICMP attacks.


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

Again, this is low risk, fairly minor, and a trivial attack method.
But, I've not seen anyone mention this.

     -Neal Krawetz
     Hacker Factor Consulting