COMMAND

    Internet Explorer

SYSTEMS AFFECTED

    Win NT

PROBLEM

    If you browse yourself to:

        http://www.efsl.com/security/ntie

    you will have for  a demonstration of one  of the MSIE holes  yet.
    Internet explorer  on Microsoft  NT will  attempt to transparently
    authenticate, using  a function  of your  NT password,  to any web
    server on the internet that wishes  to ask.  If the web  server so
    chooses, you will never even be aware that this has happenned.

    This vulnerability is  a web browser  problem embedded in  the web
    server -  browser NTLM  challenge response  authentication scheme.
    Although similar to Internet Explorer  on this page #5, this  does
    not depend  on any  interaction with  an SMB  file server.  Credit
    goes to Paul Ashton.  Here comes detail info (text used from  page
    above).

    Without  your  knowledge,  MS  Internet  explorer  on  Windows  NT
    transparently attempts  to authenticate  with a  remote Web server
    that  requests  NTLM  authentication.   During  the authentication
    negotiation, IE send your  username, domain name or  workgroup and
    hostname in the clear to anyone  who asks. This is a serious  flaw
    in itself.

    The remote server  than chooses and  sends an 8  byte challenge to
    the client. Your IE client on  NT will then encrypt a function  of
    your  password  with  this  challenge,  and  send  it  back to the
    server.  The server should  compare its version of your  encrypted
    password  with  the  one  sent  by  the  client  to  complete  the
    authentication.

    In fact two  versions of your  encryped password are  sent, one of
    which  is  based  on  the  full  length  and character set of your
    password  up  to  128  characters,  the  other one is the first 14
    characters of your password in upper case.

    The problems are following:

        * The  server  is  free  to  send the same challenge to  every
          client that connects to it.
        * The  server  is  free  to  request a challenge from  another
          server and send that for you to be encrypted.
        * The  client  cannot  detect  whether  this    authentication
          process has occurred.
        * The  client  cannot  verify  whether  it  is  talking to  an
          authentic server.
        * The  client  cannot  prevent  the  server using the  clients
          authentication  token  to  attach  to  any  file  server/web
          server/MS Exchange server/etc. that it wishes to.

    By setting the challenge to a constant the server can  pre-compute
    a  massive  database  of  possible  passwords and instantly detect
    whether the client is  using any one of  these.  Even if  the user
    uses a strong password,  the server can spend  as much time as  it
    wishes in  the future  to attempt  to guess  the password  without
    ever having to contact a real NT server.

    On the author's  page (see above)  you can try  the test. It  only
    works with Internet explorer on windows NT.

    Anyway, this is it (by PAul Ashton, posted to mailing list):

        >telnet www.foo.com 80
        >GET / 1.0
        >
        <401 access denied
        <Authenticate: NTLM

        >GET / 1.0
        >Authorization: NTLM SDFSDFSDFSDFKLJLKJLKJFL... (netbios host and workgroup)
        >

        <401 access denied
        <Authenticate: NTLM GHGHGHGHGHGHDFJDJFHDFHFHFH... (8 byte challenge)

        >GET / 1.0
        >Authorization: NTLM FHFHHSHDHSDHSDHSHDSHDS... (my plaintext
         username, hostname,domain name,encrypted passwords)
        >

    The  brute  force  attack  only  has  to  work  through upper case
    characters and numerals (plus whatever else is valid and  likely),
    not lower case characters, and also you will notice if you  access
    Paul's web page that it is  possible to detect if the password  is
    shorter  than  8  characters  or   sometimes  what  the  first   7
    characters are even if the rest are unknown.

    This depends if you attack  the LanMan compatible or NT  password.
    It is correct in that  the LanMan password is only  uppercase, but
    you  can  think  of  a  reason  to attack the NT password instead.
    Inorder to hash  the LanMan password,  the password string  (up to
    14 chars, padded  with nulls if  shorter) is actually  used as two
    seperate DES  keys, the  first 7  chars as  the first  key and the
    second 7 as the  second key, to encrypt  a known string.   For the
    NT password, the pasword string is converted to Unicode  (trivial)
    and then  hashed using  MD4. So,  it is  far more  computationally
    intensive to hash  LanMan passwords than  NT passwords.   This may
    be a real concern in launching an attack, but it would have to  be
    weighed against the greater key space created by the use of  lower
    case.

SOLUTION

    For now, following solutions are given by author (I agree):

        * Immediately upgrade to Netscape,
        * Disable  the  NTLM  SSP  service  in  control-panel/services
          (though this may be detrimental to other services on NT),
        * Upgrade to Unix, you know it makes sense.

    MS  official  response  to  this  ended  in  how  to  disable   LM
    Authentication on Windows NT.   Windows NT supports the  following
    two types of challenge/response authentication:

        - LanManager (LM) challenge/response
        - Windows NT challenge/response

    To allow access  to servers that  only support LM  authentication,
    Windows  NT  clients  currently  send  both  authentication types.
    Microsoft developed a patch that supports a new registry key  that
    allows  clients  to  be  configured   to  send  only  Windows   NT
    authentication.  Microsoft has  posted the patch at  the following
    Internet location:

        ftp://ftp.microsoft.com

    following path

        /bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP3/lm-fix