COMMAND                                            SOURCE: 


  Win NT, Internet Explorer 3.01
  (possibly  earlier versions)


    MSIE never  gets it's  peace.   Here comes  another vulnerability.
    This time together with Netscape. It can be found at:

    So  far,  this  has  only  been  confirmed  on  the following test

        * 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
        * 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:

    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.




    MS is working on it.