DATE: COMMAND SOURCE: AUTHOR: IE SYSTEMS AFFECTED Win NT, Internet Explorer 3.01 (possibly earlier versions) PROBLEM MSIE never gets it's peace. Here comes another vulnerability. This time together with Netscape. It can be found at: http://www.ee.washington.edu/computing/iebug/ So far, this has only been confirmed on the following test benches: * Windows NT 4.0 Server Service Patch 2 - Internet Explorer 3.01B (with the 3 patches in one) * Windows NT 4.0 Server Service Patch 2 - Netscape Navigator 3.01p * Windows NT 4.0 Workstation Service Patch 2 - Internet Explorer 3.01B (with the 3 patches in one) * Windows NT 4.0 Workstation Service Patch 2 - Netscape Navigator 3.01 On page above, you can find web page that points to a Rogue SMB Server. This web pages contains an embedded image (actually two). The embedded images do not reside in this same directory as this web page. In fact, they reside on a SMB Lanman server (as opposed to an HTTP server). (View the source for this html to get a better idea what I am talking about). Author borrowed this idea from the Last MS Internet Explorer Security Exploit: http://dec.dorm.umd.edu In order for the client to download the images, the client needs to 'logon' to the Lanman server. Windows NT seems to do this without even asking the user for confirmation. Windows NT simply forwards the username and encrypted version of the user's password to the Lanman server. The Lanman server code has been modified slightly to record Usernames and "Hashed Passwords" of the victims. Also the code has been modified to supply the client with a fixed "Challenge seed value" for password encryption. (Thus making it even easier to decode the client passwords in the future.) Let us clarify *exactly* what is being sent here: the modified SMB server sends a null challenge to the client in a NEG_PROT_RESPONSE message, the client encrypts (DES by the CIFS spec) the null challenge using a hash of the user's password (MD4 and/or DES encrypts a known string using a derivation of the password string as the key to obtain an OWF effect)and sends it in a SMB_SESSION_SETUP_AND_X. The dictionary attack is quite possible, but here are the steps that need to be taken: each entry in the dictionary needs to be hashed using one of the two algorithms mentioned, the null challenge encrypted with the hash as the key, and then compare the result against the challenge response the client sent in the SMB_SESSION_SETUP_AND_X. First of all, no remote web site should be able to record your username. If they do, then can compile junk email lists and sell your name. Secondly, if they have information on what your password might be, and they know what site you came from, they can gain access to your computer or local account. (Thus compromising your security with you never knowing about it.) It is fairly easy to unencrypt a MS password if the challenge has set to zero via dictionary attacks. Sequential search brute force attacks work as well if you can guess what types of characters are most common in the password. Yes, it is time consuming, but if your account gets hacked, is it really worth it? It *is* interesting to note that if the server claimed to not support encrypted passwords (SMB dialect sub LanMan 2.x), the client application will prompt the user for a user name and password. If the user is stupid enough to enter the info, the NT or Win95 machine will happily send it plaintext to the server! Credit for this goes to Aaron Spangler. Text use here was also part of Dominique Brezinski's replay to text above. EXPLOIT SOLUTION MS is working on it.