Netscape Network ad
Security Solutions by Stuart McClure

Securing your CGI scripts against hacker invasion

CGI scripts have been known to leak -- don't let hackers exploit this well-known window of opportunity

Summary
Because the source code to many CGI scripts is publicly available, CGI can be a weak point on your Web server, opening you up to possible attack by malicious hackers. We give you recommendations on securing your CGI scripts and eliminating potentially disastrous security holes. (1,000 words)
Netscape Enterprise Developer

March  1998

Table of Contents
Subscribe, it's free!
Search Netscape Enterprise Developer

Never underestimate the amount of time and resources that a hacker will throw at cracking your Web server. For most hackers, breaking into your system is a game, a power trip. They're out to prove to you and themselves that they're smarter than you are. What most attackers are after is truly the brass ring of hacking: supervisor or root privilege. Lazy Web administrators and poorly-programmed CGI scripts can give a hacker exactly what he or she needs to obtain root on your system. We show you how to patch those weak points and keep your system safe.

How do hackers get into your system?
Nearly a dozen CGI-script vulnerabilities have cropped up over the past few years -- mainly because the source code of these scripts has been made publicly available. Many CGI scripts, like php.cgi and files.pl, are particularly easy to exploit because their source code comes free with the Web server product or scripting module that you purchase.

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 QUERY_STRING environment variable is copied to a fixed-size dynamic buffer. Both the exploit code and fix are freely available on the Internet. (See Resources.)

Fixing any potential holes
As basic as my first CGI security suggestion may sound, I cannot say it more emphatically -- don't run httpd as a privileged user! Create a non-privileged user and run the HTTP daemon as that user. You may have to deal with the headache of permissions, but doing so will remove your vulnerability to some of the most popular attacks discussed above.

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 |, >, <, and ` can be interpreted by the engine in a way that executes the commands locally on the system (and usually as the user running httpd -- probably root).

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
Short of sending your scripts out to hacker teams to see if they can break into them, my suggestion is educate yourself by staying current with any CGI leaks found. Here are two good ways to do this:

  • Subscribe to BUGTRAQ by sending mail to listserv@netspace.org and placing "subscribe bugtraq" in the body of hte message.

  • Keep current with CERT's advisories by either browsing its archive at http://www.cert.org/pub/advisories/index.html, or subscribing to its mailing list by sending an e-mail to cert-advisory-request@cert.org with "SUBSCRIBE me@here.com" in the subject of your message.

Resources

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.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough
    

Table of Contents Subscribe, it's free! Search Netscape Enterprise Developer

[(c) Copyright 1998 Web Publishing Inc., an IDG Communications company]

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