Re: ICMP time exceed in-transit packets

Chris,

Since this discussion is public, I might as well throw in what I
assume the folks who are doing this are also thinking...

> So the attacker transmits the above packet. While in transit, the TTL
> drops to zero. The router receiving the TTL 0 packet realizes it can not
> forward it and issues a time exceeded (ICMP type 11) packet back to the
> spoofed source address. So what you are seeing in your logs is the error
> code generated by the spoofed packets when the TTL expires.
>
> A couple of odd things about this traffic pattern:
> The type 11 packets are small, requiring *many* to be an effective DoS

It might make a crappy DoS, but that isn't the only reason to do it.
Think stegonography for a moment.

> I think the whole idea of this attack is its suppose to be "stealthy"
> and cause confusion. The source of the type 11's are multiple backbone
> routers from around the Internet. This makes it appear as multiple hosts
> are launching a coordinated attack.
> ...
> Now, if you can decode the type 11 packets you are seeing, they will
> include the first 64 bits of the original packet transmitted by the
> attacker. This means you now know the IP address of the destination
> within the echo-request packet as well as the IP address of the router
> issuing the type 11.

Stealth is only part of it. Obfuscation is probably another part
(who cares what system was supposed to get the original packet, its
the one that eventually receives it that is probably the key).
Playing on assumptions about what can safely be ignored is probably
yet another part of it.

OK. So you have a bunch of packets, which are hard to trace, look like
they are coming from all over the Internet, get successfully delivered
to the target you intend, and has embedded in it at most 64 bytes of the
original, purposely messed up packet.

Here is what it takes to tell a Tribe Flood Network agent to open up a
remote shell on port 12345:

ICMP message id: 10.0.0.1 > 192.168.0.1
  ICMP type: Echo reply
 .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
 .. . .. . .. . .. . 00 . 00 . 64 d D1 . 01 . C8 . 00 . 00 . 31 1 32 2 33 3 34 4
 35 5 00 .

(See http://staff.washington.edu/dittrich/misc/tfn.analysis for more
examples.)

That is less than 64 bytes. Adjust your parsing routines per what you
just said and...

If I were you, I would start taking a VERY close look at the contents of
those packets, and what's on the system that is receiving them.

Now you want to get into the RFC 2267 thing? ;)

--
Dave Dittrich                 Client Services
dittrich_at_cac.washington.edu   Computing & Communications
                              University of Washington
<a href="http://www.washington.edu/People/dad/">
Dave Dittrich / dittrich_at_cac.washington.edu [PGP Key]</a>
PGP 6.5.1 key fingerprint:
FE 97 0C 57 08 43 F3 EB  49 A1 0C D0 8E 0C D0 BE  C8 38 CC B5