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.