exploit

Date: Mon, 30 Nov 1998 17:20:04 -0600 From: Michael Gerdts 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: exploit

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