Security Incidents mailing list archives
Re: ICMP time exceed in-transit packets
From: dittrich () CAC WASHINGTON EDU (Dave Dittrich)
Date: Sat, 1 Jan 2000 20:35:49 -0800
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 () cac washington edu Computing & Communications University of Washington <a href="http://www.washington.edu/People/dad/"> Dave Dittrich / dittrich () 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
Current thread:
- port 1150 and 4833 ?, (continued)
- port 1150 and 4833 ? Kim R. Rasmussen (Jan 04)
- Re: port 1150 and 4833 ? Frameloss, Frameloss (Jan 10)
- Re: port 119 R a v e N (Jan 05)
- Re: port 119 Scott Laws (Jan 04)
- Writeup: it. TLD going astray Arrigo Triulzi (Jan 03)
- Computer Forsenics System Administrator (Jan 03)
- Re: Computer Forsenics-> www.fish.com/forensics mike (Jan 03)
- traceroute ICMP packets Laszlo Fabian (Jan 04)
- Re: traceroute ICMP packets M J (Jan 04)
- Re: traceroute ICMP packets Larry Canup (Jan 18)
- Re: ICMP time exceed in-transit packets Paul Cardon (Jan 02)
- Re: Port Scan on 371... Etaoin Shrdlu (Jan 02)
- Re: Port Scan on 371... Christopher Wilson (Jan 02)
- correlation between porscans and local activity Thomas Molina (Jan 02)
- Re: correlation between porscans and local activity Sean Sosik-Hamor (Jan 03)
- ADMROCKS McNab, Chris (Jan 03)
- R: correlation between porscans and local activity Raistlin (Jan 04)
- Re: R: correlation between porscans and local activity Michael Babcock (Jan 12)