[ISN] CGI vulnerabilities that leave back doors open still plague Web s ites (fwd)

From: mea culpa (jerichoat_private)
Date: Sat May 30 1998 - 10:32:00 PDT

  • Next message: mea culpa: "[ISN] White House Critical Infrastructure Protection Paper (long)"

      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]
    May 25, 1998 
    CGI vulnerabilities that leave back doors open still plague Web sites
    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
    * 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
    *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?
    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--
    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