Re: CGI insecurities

[BlueBoar () THIEVCO COM (Blue Boar)]

"hypoclear - lUSt - (Linux Users Strike Today)" wrote:
> I have a question about CGI insecurities.  Let's suppose this...  Your
> looking at a site with some CGI forms that do a couple of neato things,
> and most likely there is a vulnerability in these scripts.

Yup.  This list is dedicated to the concept that just about everything
has a hole in it.

> How would one go about exploiting these scripts?  (I'm not talking about
> pumping 1000 A's into it, till it crashes. ;-)

For CGI scripts on someone else's server, that wouldn't help you much
even it was effective.  You might have a slight clue that you'd caused
a crash if you got no data back.

> Do you need the source code for the script?

It's not absolutely essential, but it makes things much, much easier. If
not source, then an identical binary (if it's compiled.)  I can't imagine
how you'd calculate a buffer overflow, for example, without being
able to get feedback from the bin.

> Is there anyway to retrieve the code of the working script on the site?

On NT/IIS at least, there are a couple.  One is to append a ::$DATA,
another is to add a trailing .  Both of these have been published and
patches are available, so they only work on sites that aren't paying
attention.  I'm sure there are probably others.  You can always check
the obvious things, like is the FTP root related to the WWW root, and
can you grab the file that way.

Note that this is usually only a problem for custom CGI code (though
there is a fair amount of that out there.)  If it's a published package
of some sort, you can get your own copy.  You want to start with
a copy if at all possible, if for no other reason that your poking
around will be somewhat noisy in the logs.

if you're stuck doing true black box testing, try really long fields, try
the entire character set, try leaving fields off, try changing hidden
fields, etc..

                                        BB