Re: An ICMP Type 3 Signature

[Jay Random <scarbaci () YAHOO COM>]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Here's another one of those overwritten network 
traffic analysis
> pattern matches that I like to post 
periodically.
> This one consists of a bunch of ICMP type 3 
(host unreachable)
> packets.  The source addresses of thse packets 
tend to be
> border or edge routers at ISPs and suchlike.  
Before I get

most likely firewalls

> into what's interesting (and distinguishing) 
about this particular
> pattern, here's an example:
>
> 18:16:36.779894 207.88.240.101 > a.b.c.d: icmp: 
host 194.102.148.213 unreachable
>    4500 0038 0000 0000 f601 704b cf58 f065
>    .... .... 0301 681d 0000 0000 4500 0028
>    6a37 0000 1806 4ca2 .... .... c266 94d5
>    0449 0028 2837 6839
> 18:22:42.611841 207.88.240.101 > i.j.k.l: icmp: 
host 194.102.148.213 unreachable
>    4500 0038 0000 0000 f801 a39e cf58 f065
>    .... .... 0301 62d2 0000 0000 4500 0028
>    50e4 0000 1806 9b48 .... .... c266 94d5
>    089b 0121 2837
>
> I've included the source address and the 
`unreachable' address, although
> they vary from incident to incident.
>
> Interesting features about this traffic:
>
>       -ICMP unreachable messages are supposed to 
contain the IP
>        header and (at least) the first 8 bytes 
of the original datagram
>        which caused the ICMP unreachable message 
to be sent.
>        The addresses in the included portions of 
the datagrams
>        match the destination addresses of the 
ICMP unreachable
>        messages.  Translation:  these look like 
valid, unmunged
>        ICMP unreachable messages

that would look about right

>       -The length of the data portion of the IP 
datagram which
>        generated the ICMP error is not 
constant[0]
>       -Neither of the destination addresses 
(a.b.c.d and i.j.k.l in
>        the above example) had sent any traffic 
to 194.102.148.213 in
>        the two hours prior to receiving the ICMP 
datagrams (two hours
>        is as far back as I looked---they've 
probably -never- sent
>        anything to 194.102.148.213).  In fact 
i.j.k.l was an
>        unused address that wasn't sending or 
receiving -anything-

i believe this to be true as well

>       -The two destination addresses in the 
example above are in
>        fact in different 8-bit networks 
(different class As, if
>        you prefer)
>       -The value of the portion of the TCP 
sequence number in the
>        included datagram is always the same.  
When the entire SN is
>        included, the whole thing matches
>       -The TCP source and destination ports in 
the included datagram
>        are not constant
>       -The source address of the ICMP messages 
is generally a
>        border or edge router, but not one 
between the destination
>        address of the ICMP message and the 
`unreachable' host
>       -The destination addresses of the ICMP 
messages seem to be
>        fairly random but nothing approaching 
truly random.  I.e.,
>        in the example above two hosts on 
different (and not sequential)
>        8-bit networks got hit.  Sometimes a half 
dozen or so hosts
>        on a single 24-bit network will see this 
sort of traffic,
>        but not sequentially or in any other 
order I can make out.
>        Perhaps a scanner which takes a list of 
address/mask pairs
>        as input and picks decoy addresses 
randomly from the
>        networks in that list?
>
>
> My hunch is that what I'm seeing is the result 
of someone scanning
> multiple target hosts (in the example above 
194.102.148.213) using
> the destination addresses of multiple unrelated 
machines (a.b.c.d
> and i.j.k.l in this example) as decoy addresses.
>
> What I'd be interested in, then, is:
>
>       -The opinions of anyone who thinks that 
-isn't- what I'm
>        seeing
>       -Any suggestions on what the tool being 
used is

most likly nmap

>       -Any wild-ass guesses about the decoy 
address selection mechanism.

well this depends really.  A script kiddie dosnt 
know how to correctly use decoy ip's, and will 
most likely pick at random.  A better attacker 
will actually read the manual on decoy hosts, and 
choose one's which are down, thus unable to 
packets.  My personal favorite is to use 
firewalled hosts that "drop" all unacceptible 
packets.  Which is virtually dead.

what you are seeing is someone picked you (prolly 
out of a hat) to be a decoy, they portscanned a 
box which was firewalled with rules "deny". which 
sends a lovely icmp type 3 error back to the host 
(and decoys).  I would grab all the logs of these 
errors for 2 reasons.  A to alert the host that 
sent the icmp errors, as to notify him of the port 
scan.  Second, to make certain he cant use his 
logs (which includes you as a decoy) as someone 
port scanning them.  The proof of portscan wouldnt 
be a big deal if it just stoped at portscanning, 
most likely he found something interesting and is 
already defacing their site.  So if they use the 
port scan as foresics, you need to protect 
yourself from suspect and aid in catching the true 
intruder.
>        It really doesn't look like it's targeted 
traffic, but I
>        always like to have a specific mechanism 
to explain the behaviour of
>        anomalous traffic (that doesn't involve 
the whims of a
>        bad guy with a grudge)
>
> The best way I've been able to correlate these 
incidents has been
> to match/sort the first 16 bits of the TCP seq 
number in the
> included datagram of ICMP host unreachable 
messages.
> Good hunting.
>
>
>
>
>
> - -Steve
>
> - -----
> 0     I doubt that this has anything to do with 
the posited scanner;
>       it's probably strictly due to the 
behaviour of the routers
>       generating the ICMP datagrams.  But I 
don't know that for a fact,
>       so I'm including the variability of the 
length as an interesting
>       feature anyway.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.1 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
iD8DBQE525JYG3kIaxeRZl8RAsULAJ9jq6Sgpb8yqCxRSTvL9A
2jToAnKACfac38
> voRz9D5fRSMJ4TeHxvCvSAg=
> =Cs7O
> -----END PGP SIGNATURE-----