Re: Remote exploitation of network scanners?

[Lincoln Yeoh <lyeoh () POP JARING MY>]

At 12:30 PM 8/25/00 -0700, Ricardo Anguiano wrote:
> Hello,
>
> I investigated this very thing.  Netbus freezes if you send it a stream
> of ascii characters such as chargen would.  You have to give it a three
> finger solute and kill the process/thread.  nmap, was ok if I remember
> correctly. I did not test other scanners.

That sounds interesting. There are a few popular trojan scans endemic in
the networks of one of my ISPs. And that ISP doesn't seem to be taking much
or any action - just an automated response to email. Getting rather
tempting to zap them kiddies :).

> I thought writing a little daemon to connect to unused ports and flood
> the port whenever connected to by "strangers" outside your regular
> domain (don't flood your officemates scanning your machine, or your mail
> server connecting on the ident port) but I didn't get around to

I'd just stick to a few popular ports. Maybe activate them on demand. This
just for those trojan scans. Nmap-style full scans should be treated
differently I think.

> flooding data to each ip address.  I would hate to get tricked into
> flooding some innocent.  How do you keep this scanner killer from
> becoming a DoS tool?  I didn't have an answer.  The scanners are not

If it's TCP it's not such a big problem, since exposed O/S should be hard
to TCP spoof.

For UDP, that could be an issue - could end up being a target of a
sophisticated fraggle if one is not careful and allows flooding gain -
output greater than input.

However what I'm thinking of is not so much a raw long stream of data.
Rather something that looks like input which the scanner will take and then
choke on. So if the attacker scans a whole range of IP addresses I am
listening on, I could just send a few kilo bytes back and then run sleep
for maybe a minute. If I am being spoofed, the few packets won't do
anything to the 3rd party machine because they won't be listening on that
port. And there won't be any gain for bandwidth flooding - the attacker
might as well do things directly.

For udp one could probably settle for a single perl script to send data
when various criteria are met- I don't need to fork/thread - since I'm
intending to deal with only one "client" at a time ;).

Cheerio,
Link.