Re: Remote exploitation of network scanners?

[Ryan Sweat <h3xm3 () SWBELL NET>]

     I believe the application you are mentioning was NO-BO, which acts like a
back orifice server, but logs the intruders ip and sends them a warning that you
have been logged.  This application can be crashed by sending mass junk to the
NOBO listening port, usually 31337.  I would assume many applications that serve
this kind of purpose which were coded quickly with no security in mind, other
than to close another hole, are vulnerable to something totally different.

bats.


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.
>
> I used to do this whenever a port became a popular scan. Turn on chargen
> on that port, an action inspired by a Tsutomo Shimomura story. By
> looking at the tcpdump data, I could see most of the connections ended
> in resets, which could have been intentional, but I thought it likely to
> be people killing their scanners.  Elaine Guan, a fellow student here,
> helped gather some statistics.  The average connection time was
> extended, but I don't remember off hand exactly how long.
>
> 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
> implementing something I was happy with.  First of all, I really had to
> increase the open files limit, or else I would run out of file
> descriptors when scanned and the machine would reboot!  Secondly I would
> need to keep a log of connections and allow only a certain amount of
> 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
> going to use crypto authentication to identify themselves :) You must
> rely on inherently insecure ip addresses.
>
> This all falls into the realm of intrusion response and depending on your
> security policy a scan may not be a security breach.  The scheme also
> rings of Fred Cohen's deception toolkit because you are making it seam
> that you are running some vulnerable daemon, but instead its just a fake.
>
> I think there is a program called fakebo that pretend to be back
> orifice, but I don't have details, since I never used it.  I can't think
> of others.
>
> -Ricardo Anguiano
>
> Lincoln Yeoh <lyeoh () POP JARING MY> writes:
>
> > Hi people!
> >
> > I wonder if the many popular scanners out there are written securely - so
> > that they themselves cannot be exploited.
> >
> > It seems to me that many of these programs are written as a "proof of
> > concept" or as instructive samples, and good for that purpose alone but may
> > not be robust enough for use in a hostile environment.
> >
> > Hypothetical scenario:
> > A scanner requiring remote input scans a targeted host, looking for replies.
> > The targeted host replies with exceptional input causing the scanner to run
> > arbitrary code (buffer overflow etc etc), probably with the privileges of
> > the user running that scanner.
> >
> > Denial of service programs are probably less vulnerable since they usually
> > don't require remote input (except maybe dns?). They usually accept input
> > from the command-line which shouldn't become a problem in typical usage :).
> >
> > Note that I am not saying that the authors of such programs are writing
> > poor quality code, far from it, but there is a danger that some users may
> > be using them under inappropriate conditions for purposes they were not
> > designed for. After all much of the code released is "for educational
> > purposes only" ;).
> >
> > Have a nice weekend!
> >
> > Link.