Forwarded From: "Prosser, Mike" <Mike_Prosser@tds.com>
[FYI- interesting article from a new security column in Infoworld. Well
known info, but still valid and vulnerable. - Mike]
http://www.infoworld.com/cgi-bin/displayNew.pl?/security/980525sw.htm
May 25, 1998
CGI vulnerabilities that leave back doors open still plague Web sites
HACKERPORT
CGI vulnerabilities
SUMMARY: Web servers using CGI scripts to perform dynamic file retrieval
and Web server actions are vulnerable to illegal parameters being passed
by crackers to gain access.
TARGET: Any Web server running CGI
TYPE: Information Gathering and Denial of Service
DATE: 1997
CODE: Any illegal parameters of a CGI script
ATTACKER: Any Web browser, Telnet user
FIX:
* Run httpd as nonprivileged user
* Remove unused CGI scripts
* Store scripts in nonstandard directories
* Use compiled CGI scripts such as C/C++
* Sanitize your code
Ever wonder how unethical hackers or "crackers" deface Web pages so
easily? What most are doing is exploiting existing CGI vulnerabilities.
Unfortunately, overworked Web administrators and poorly programmed CGI
scripts have given crackers everything they need to gain access to your
corporate Web servers and more.
The CGI problem has been around for years and is one of the most popular
ways crackers gain access to your Web servers. As we discovered, even an
InfoWorld Web server was not immune to these CGI holes. With a simple
parameter passed to one of our Perl scripts, we were able to download
the entire /etc/passwd file and crack two user passwords -- gaining
access to the server.
After this discovery, we decided to investigate further. Not only did we
find multiple CGI vulnerabilities, but we also found many Web servers on
the Internet today with these same CGI vulnerabilities.
However, the hole we discovered on our Web server was small compared
with the dozen other CGI vulnerabilities that have cropped up during the
past two years -- many giving remote command execution to anyone. Older
holes in scripts such as phf.cgi and files.pl are particularly dangerous
because they can execute any command remotely as the user of the running
HTTP daemon (httpd) process. For example, with the omnipresent PHF
attack, a cracker can run rm -R * -- removing files from your hard
drive. Like the PHF vulnerability, the info2www script allows someone to
run commands on the local system.
Be aware and take action
The problem is that most people aren't aware of the severity of these
holes, and those who are simply haven't made fixing them a priority.
Even today, many Web servers are still vulnerable to the PHF attack
found back in February 1996. Web administrators and programmers have to
take these problems seriously and take immediate steps to prevent damage
to their Web servers. We suggest a few preventative measures.
*Don't run httpd as a privileged user. Many Web servers will not take
the time to create a nonprivileged user to run the HTTP daemon. The
headache of permissions is a small price to pay to avoid such
destructive attacks.
*Clean out any sample scripts from your cgi-bin directory. Scripts such
as phf.cgi, nph-test.cgi, and files.pl are easily abused.
*Be sure to keep all of your CGI scripts under one main directory (named
something other than cgi-bin) and let only the Web administrator place
those scripts.
*Move to only compiled scripts. Although this is somewhat dramatic, any
cracker who can get their hands on your source code can find a
vulnerability.
*Thoroughly "sanitize" your code. Examine your scripts for file access
and set UID usage, use explicit pathing, and limit your scripts input of
metacharacters such as "|", "()", "..", "/", and the single quote
character. Many CGI scripts don't sanitize their input, so crackers can
keep trying weird characters until something works.
What steps are you taking to protect your Web servers?
<Picture>
Test Center Support Manager Stuart McClure and Technology Analyst Joel
Scambray have managed information security in academic, corporate, and
government environments for the past nine years. They currently test
dozens of security products, from firewalls to security auditing
solutions, in search of new ways to improve enterprise network security.
Send e-mail to security_watch@infoworld.com.
-o-
Subscribe: mail majordomo@sekurity.org with "subscribe isn".
Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]
Received on Sun May 31 10:49:49 1998