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
