![]()
How do hackers get into your system? A brand new point of entry has just been reported (but not confirmed) on Bugtraq. This one involves info2www.cgi, and reputedly allows an attacker to pull any file he or she desires off a vulnerable Web server. If correct, this will be just one among many instances where a hacker was allowed to run the following command -- or one like it -- on a local system as a privileged user:
GET ./info2www '(../../../../../../../bin/mail jami </etc/passwd|)' Other recently-discovered CGI weak points include the leak found in the Excite Web search engine in January and the nph-test-cgi found last September (see Resources section below), campus.cgi, wrap.cgi, view-source.cgi, and many more. Even today, many Web servers are still vulnerable to the phf.cgi attack found in February 1996. The script is distributed with NCSA's httpd and Apache's Web Server. This attack allows a user to input a newline character, "\n", to run local commands. Phf is typical in that once in, the attacker is allowed to pass commands to the scripts that will remotely execute on the Web server itself. For example, using phf, the attacker can output the password file to the screen:
GET /cgi-bin/phf?%0a/bin/cat%20/etc/passwd
A very different CGI attack was found in 1997 that involved the
count.cgi script -- a very popular means to count the number of users
visiting a Web site. This script allows for a buffer overflow
condition which can be used to run commands as root. This CGI
script is vulnerable to attack when the
Fixing any potential holes The next obvious step is to clean out any sample scripts from your cgi-bin directory. These sample scripts, like phf.cgi, nph-test.cgi, and files.pl are easy to come by for hackers and are often the first source of an attack. Use the test and sample scripts to make sure CGI is working, then remove them as soon as possible. After that, be sure to keep all your CGI scripts under one main directory and allow only the Web administrator to place scripts there. This limits the possibility of rogue scripts on the server, which could be "discovered" by a hacker. The more dramatic approach to securing your CGI scripts is to use only compiled scripts, although for some, this is too troublesome. For a hacker to exploit a CGI script they must get their hands on it, study it, then poke and prod it to discover an unknown hole. With a compiled script such as one written in C, it's much more difficult to break down the source code. With a an interpreted language like Perl, Javascript, or VBScript, there's a much better chance that a hacker will be able to study your source and discover a vulnerability.
The most important step you can take is to thoroughly examine your code.
Examine your scripts for file access, set UID usage, check each
program's input, use explicit pathing, and above all, control your
metacharacters. Certain metacharacters in scripting languages such as
Perl, like The metacharacter problem is common to most CGI leaks found to date, including the Excite Web search engine (EWS), webdist.cgi, files.pl, nph-test-cgi, campas.cgi, and many more. Begin solving this problem, by writing code that restricts user input to only legal characters (such as A to Z and 0 to 9). As CERT and many Perl experts have pointed out, explicitly allowing characters that you deem legal goes a long way toward controlling hacker attacks on your system. This is your best line of defense -- sanitize your code!
Long term CGI security solutions
|
About the author
Stuart McClure is responsible for security testing at InfoWorld's test
center. He specializes in network security, including vulnerability assessment and intrusion detection.
Reach Stuart at stuart.mcclure@ne-dev.com.
If you have problems with this magazine, contact
webmaster@ne-dev.com
URL: http://www.ne-dev.com/ned-03-1998/ned-03-security.html
Last modified: Tuesday, November 03, 1998