Re: An ICMP Type 3 Signature

[George Bakos <alpinista () BIGFOOT COM>]

On 10 Oct 00, at 21:07, Jay Random wrote:

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

That's all well and good, except no packets have come back from
the target host, merely from backbone routers.

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

Depending on the firewall, "DENY" may or may not return an
unreachable message.  Where they do return a nastygram, it is,
AFAIK, a port unreachable (type 3, code 3) rather than a host
unreachable (type 3, code 1).

 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.

I have seen a fair bit of the same traffic and drilled a little deeper.  It
seems that the target network is certainly reachable right now.  I
agree that the target host is firewalled and drops the packets on
the floor with no response whatsoever. This is obviously a low &
slow randomized tcp scan with one little problem:  the lone satcom
link to the States that this network is advertising (see www.rnc.ro)
has a little reliability problem.  When it goes down and this
situation converges, the Uunet, Concentric, etc. backbone boxes
closest to the attacker generate these type 3 messages.
One thing that concerns me is the TTL relationships discussed
earlier.

4500 0038 0000 0000 f901 dbcb 983f 1549
xxxx 66aa 0301 6633 0000 0000 4500 0028
6d1c 0000 1306 ab07 xxxx 66aa c266 94d5
0532 0129 2837 6839

4500 0038 0000 0000 f601 cc98 cf58 f069
xxxx 66a3 0301 671b 0000 0000 4500 0028
120e 0000 1806 011d xxxx 66a3 c266 94d5
0561 0012 2837 6839

Let's assume that the hostile packets' initial TTL values were not
spoofed.  Due to their general lack of randomness, I believe that is
the case.
In the first trace, the encapsulated header's TTL=19 (0x13), where
the packet's TTL=249 (0xf9), so the attacker is 32-19=13 hops from
the bouncing router.  That router, however, is 256-249=7 hops from
my sniffer.  In this case, he is further than I.
In the second trace, however, the reverse is true.  The attacker is 8
hops from the router, whereas the same sniffer is 9 hops.
Also, every packet sent to the target was to a random, unique TCP
port.  In order for this slow port sweep to be of any use, the
attacker needs to be listening from fairly close to the target, while
the packets are being lauched (and spoofed) from various hosts.
This smacks of a distributed scanning tool.  rnmap will do what we
are looking at, with the added twist of a compromised box sniffing
just upstream of the target.
Next theory?
George Bakos - Security Engineer
Electronic Warfare Associates
Information & Infrastructure Technologies
http://www.ewa.com
802-338-3213

 To request PGP public key,
 mailto:alpinista () bigfoot com?subject=sendpubkey
 or http://pgpkeys.mit.edu:11371/