ICMP pokes holes in firewalls...

Date: 09/25/03

  • Next message: Andreas Steinmetz: "minor apache htpasswd problem"
    Date: 25 Sep 2003 19:21:50 -0000
    To: bugtraq@securityfocus.com
    ('binary' encoding is not supported, stored as-is)

    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
      Host 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 did not see it.
      Why? Because traceroute chose port 23456/UDP.
      Host was running snort (total dumb luck) and it caught
      the inbound ICMP packets that should have gone to

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

  • Next message: Andreas Steinmetz: "minor apache htpasswd problem"

    Relevant Pages

    • Re: tracert from A to B dies just before reaching B -- and vice versa?
      ... traceroute died just before reaching ... the default is to use UDP packets. ... come as a surprise to you, but neither ICMP or UDP is used for SSH ... Dozens of explanations - most probably is the fact that firewall rules ...
    • Re: port block question along path
      ... verify a routing path to a specific IP-ADDRESS, not a port on that host. ... The original LBL version of traceroute written by Van Jacobson in 1987 uses ... UDP and defaults to ports 33434 + hop-count. ... this used the ICMP echo instead of UDP. ...
    • Re: AD what tcp/ip port or registry settings?
      ... Assuming that you applied the TCP/IP port value to all DC/GCs and rebooted ... I'm still swaying toward a hang-up on the member clients not being ... ICMP did not work over our Frame over ATM links. ... > on the both DC which are also behind the firewall. ...
    • Re: Recommandations..
      ... Chris Uppal wrote: ... FWIW I can reach port 8080 at weconsultants.servebeer.com with no obvious ... I can not traceroute from a remote location with the windoze firewall up. ...
    • Re: Catching very specific exceptions
      ... management package (including ICMP ping) to windows; ... It could be that some firewall between you and the target is ... The traditional way to tell if a node is up is to send it an ICMP echo ... rather than trying to connect to a TCP port. ...