COMMAND
The exploit works for both Netscape Navigator 3.01 and Microsoft
Internet Explorer 3.01 (even with Security Patches.), but you
MUST be using Windows NT 4.0 or Windows 97.
SYSTEMS AFFECTED
Win '97, NT
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 Workstation (no Service Pack)
* Windows NT 4.0 Workstation (Service Pack 1)
* Windows NT 4.0 Workstation (Service Pack 2)
* Windows NT 4.0 Workstation (Service Pack 3)
* Windows NT 4.0 Server (no Service Pack)
* Windows NT 4.0 Server (Service Pack 1)
* Windows NT 4.0 Server (Service Pack 2)
* Windows NT 4.0 Server (Service Pack 3)
* Windows 97 Beta (all memphis builds)
* Windows 95 when configured just right in certain novel
environments
With any of:
* Netscape Navigator 2.x or 3.x (all versions)
* Netscape Communicator 4.X (all versions)
* Internet Explorer 2.0 3.0 3.01 3.02 4.X (all versions)
* NCSA Mosaic Version 3.0
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.
SOLUTION
MS is working on it. Latest Service Pack 3 didn't fix this.