OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Idiotic question
From: Simple Nomad (thegnomeNMRC.ORG)
Date: Fri Mar 03 2000 - 15:07:41 CST

> ICMP_TSTAMP and its reply should be of no harm (unless they are part of
> a DoS, so they should be rate filtered).
>
> Some people will argue that ICMP_MASKREQ and more specifically its reply
> would reveal sensitive information, but I would argue this information
> is potentially public anyway. Similar for ICMP_IREQ and its reply where
> implemented. I'm fairly certain I've seen the former generated
> automatically (though I don't know by what or for what purpose) but
> never the latter.

I wrote a tool called icmpenum that uses Echo, Timestamp, and Information
Request for host enumeration. The tool was mainly meant as a proof of
concept tool for distributed attack techniques, and illustrates possible
ways attackers could send forged packets in and sniff the replies. Host
enumeration was a simple enough thing to use as an example.

You can get it from http://razor.bindview.com in the tools section.
Besides the proof of concept, it's good for checking to ensure you're
blocking the obvious packets you'll get a reply from. And you should block
Timestamp and Info Request -- as well as Echo.

There were several other issues I looked at but didn't explore. I could
have added Address Mask Requests to help with enumeration, but didn't. I
can't think of a reason to keep this puppy open, so it should at least be
restricted to devices that should reply to it, such as border routers. I
usually block it.

Source Quench tells the target host to stop sending packets so fast to the
receiver. The only nefarious purpose I could come up with would be to
possibly create network race conditions during certain spoofing manuevers,
however this requires better than average knowledge about the network to
really exploit.

Since most devices on a network do not route traffic, one would assume
Redirects could be limited. I typically block them.

Time Exceeded packets are generated by a host only if the fragment
reassembly time is exceeded. In theory you could forge fragmented ICMP
packets that are missing some of the fragments and force a host to reply
with one of these packets with a Code 1 (fragment reassembly time
exceeded). Otherwise routers use this information, typically generating a
Time Exceeded when the TTL is zero. There is no reason that a host should
receive a Time Exceeded other than a Code 1, but I am paranoid so I
usually block it except for key routers that need it on the border.

Parameter Problem packets are generated if there is a problem with one of
the parameters in another ICMP packet which causes the packet to be
dropped. Therefore by forging a packet with illegal parameters should
cause a host to reply with a Param Prob packet, assuming it has been
properly implemented on the host. Typically it isn't, or at least
consistently, but the truly paranoid may wish to at least trap these guys.
It indicates some funky ICMP things going on, which could be signs of an
attack.

Destination Unreach should be allowed, as a lot of stuff depends on it.
However I block Echo Replies, Info Req Replies, and Timestamp Replies.
Why? Well Echo Replies are what tools like Loki use, and are certainly
used in current ddos tools, for now. Anything ICMP that could be used for
covert communications I try and block. It is only a matter of time before
other ICMP types are used for covert communications.

Refer to Route's articles on Loki and Loki2 at the Phrack website, and RFC
792 and 1812 for more interesting reading.

- Simple Nomad - No rest for the Wicca'd -
- thegnomenmrc.org - www.nmrc.org -
- thegnomerazor.bindview.com - razor.bindview.com -