This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mimeat_private for more info. ------ =_NextPart_000_01BD8A36.31596090 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-ID: <Pine.SUN.3.96.980530113017.4808iat_private> Forwarded From: "Prosser, Mike" <Mike_Prosserat_private> [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_watchat_private ------ =_NextPart_000_01BD8A36.31596090-- -o- Subscribe: mail majordomoat_private with "subscribe isn". Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:54:38 PDT