Re: CGI insecurities

[o'neil.brooke () LMCO COM (Brooke, O'Neil)]

What about the defense side of things. If you were to allow only
alphanumberic and selected punctuation characters. i.e. ! . and ?
(exclamation, period and question mark) have you removed the possibility
of creating commands that could be executed?

> If the form
> sends an e-mail, try to get a "~!/usr/bin/id" (or another command) into
> the body of the message.  If the script calls /bin/mail (or similar,
> depending on the system) to send the message, the command may be executed
> with the output in the body of the message.

Mainly I am looking for a rule that would disable any kind of execution
by striping any unacceptable characters from strings sent to the cgi
prior to passing these values on. Is this feasible? What character set
could be considered safe? If this preprocessing step also looked at
string length, is there any room left for exploitation?

Any binary or platform may be referenced in responses. I'm looking for a
generalized rule.

> ----------
> From:  Dino Dai Zovi[SMTP:dadaizo () UNM EDU]
> Reply To:      Dino Dai Zovi
> Sent:  Monday, January 24, 2000 2:06 AM
> To:    VULN-DEV () SECURITYFOCUS COM
> Subject:       Re: CGI insecurities
>
> The first and best thing to do is to get the source for the CGI in
> question.  A lot of the time, the script is just downloaded from another
> site on the net.  If that's the case, a search for the script's filename
> may turn up its source.
>
> Grabbing the source from the server it's running on is a bit trickier in
> most cases.  For Active Server Pages (.asp files, Microsoft IIS), it may
> be possible to view the source by appending a "." or "::DATA" to the end
> of the script filename.  You can also replace the period in the filename
> with the escaped hex value (%2e).  There are also methods of using scripts
> from the IIS installed sample sites to view the source of any file on the
> system (but the question is regarding CGI, so that's left as a reader
> research exercise).
>
> Often script authors will put too descriptive or vital FORM parameters in
> HIDDEN tags.  View the HTML source of the page in question and search for
> things like:
> <INPUT TYPE="HIDDEN" NAME="DIRECTORY" VALUE="/usr/local/www/cgi-bin/form">
>
> (that example was very contrived, but demonstrates leaked implementation
> details)
>
> Exploring parameters passed on the GET line may also give valuable
> clues.  For each of these form values, try giving them unexpected values
> and see what they return.  They may reveal path information or failed
> system commands (!).
>
> Try to determine which (if any) parameter values may be used in the
> construction of commands that are passed to the shell.  E-mail addresses
> (if sendmail isn't called with '-t') and values that mimic site structure
> are common things that get put into file paths and commands.  If the form
> sends an e-mail, try to get a "~!/usr/bin/id" (or another command) into
> the body of the message.  If the script calls /bin/mail (or similar,
> depending on the system) to send the message, the command may be executed
> with the output in the body of the message.
>
> Attempt to escape shell commands in parameter values.  Try backticks (``),
> ;, newlines, &, |, etc.  Sometimes you can get creative and create
> testcases that will inform you whether a command works or not without
> generating too much noise.
>
> In summary, if you're performing the audit with permission (as you should
> be), convice them that it'd be more effective if you had the code.  It's a
> whole lot easier than attacking the "blackish-grey box".  The techniques I
> described are basically ways of determing how the script performs its
> function when you don't have the source.  And, there's a whole lot of
> other tricks that have much better explanations by others, so I won't put
> them here (Look up rain.forest.puppy's article on the Perl/CGI
> insecurities in Phrack or on his website, http://www.wiretrip.net/rfp).
> If all else fails, use Perl with the LWP module and pump 1000 A's into it
> :).  Hope this gets you in the right direction and wasn't too obvious.
>
> ------------------------------------------------------------
> Dino A. Dai Zovi               "Bein' Crazy is the least of
> dadaizo () unm edu                 my worries." -- Jack Kerouac
> ------------------------------------------------------------
>
> On Mon, 24 Jan 2000, 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.  How would
> > one go about exploiting these scripts?  (I'm not talking about pumping
> > 1000 A's into it, till it crashes. ;-)  Do you need the source code for
> > the script?  Is there anyway to retrieve the code of the working script
> > on the site?  I'm posting to vuln-dev because I believe that it will
> > help aid in the exploiting of CGI scripts...  of course I could be wrong
> > :-)