COMMAND

    SMB

SYSTEMS AFFECTED

    Win NT

PROBLEM

    Following info is based on Paul Ashton's posting.  In implementing
    NT domain control for Samba, the requirement to authenticate users
    connecting  to  a  share  that  isn't  on  a DC just came up.  The
    protocol works something like following.

    Client accesses SMB file server requesting access to a  particular
    share.   The file  server responds  with an  8 byte  challenge and
    the client replies with a  24 byte challenge response.   Obviously
    these are transmitted in the clear.

    The  file  server  not  being  a  domain  controller, forwards the
    challenge  and  response  and  the  user  name  to the DC.  The DC
    possesses  the  users  password  hash  and therefore can determine
    whether the response is an authentic computation of the challenge.

    Now  comes  the  interesting  bit.   If  the  DC authenticates the
    challenge response, it  replies with an  NT session key  and an LM
    session  key.   These  session  keys  are  encrypted  with the RC4
    session key between the file server and the DC.  Some of you  will
    now  be  thinking  "hang  on   a  minute,  the  server  has   just
    authenticated   someone   based   on   a   chosen   challenge  and
    response...".  Obviously  if you sniff  the net you  can gather as
    many challenge/response  pairs as you wish and replay them.  We'll
    come back to this.

    The interesting thing  is that the  DC sends the  two session keys
    based purely on the  knowledge of a challenge/response  pair. What
    are these  two session  keys?   One is MD4(MD4(Unicode(password)),
    i.e. MD4(nthash), the other is the first half of your lmhash.  For
    example, if your  password is 7  characters or less,  this is your
    password  equivalent.   If  you  sniff  the  network  and  learn a
    challenge response pair you can ask the domain controller to  send
    you the two session keys.  If the password is 7 characters or less
    you  can  impersonate   them  at  will.    Paul  posted  a   patch
    to Samba that does this on the ntbugtraq list.

    Where does  SMB signing  come in?   SMB message  authentication is
    based on producing a MAC with MD5(K,text), where K is formed  from
    the appropriate  session key  and the  response to  the challenge.
    All of this information is either  visible on the wire or you  can
    ask the DC to send it to you.

    The  only  thing  you  need  for  these  attacks  is to be able to
    communicate over a secure channel with  the DC.  You will be  able
    to do this if you  have administrative access to your  own machine
    and grab  the workstation  trust account  password.   You can  get
    admin access to  your own machine  by using the  proxy method Paul
    found  previously  (see  Domain  Admins  Access on LAN on Security
    Bugware pages for NT), or any  method of your choosing.  There  is
    no code to exploit any of this, but it would be quite easy to  put
    into Samba.

    So,  if  you  overhear  a  server  challenge and a valid challenge
    response, you  can then,  or at  any time  later, contact a domain
    controller and ask it  for the password of  that user!  This  does
    not require or involve any processing of the  challenge/responses,
    brute force attacks  or dictionary attacks.   But it's not  *that*
    bad. Instead of the password you only get the first half of  their
    LM hash (even if lm-fix has been applied). With the first half  of
    the lmhash you  can impersonate them  only if their  password is 7
    characters or less.  You also get MD4(nthash).

SOLUTION

    To resolve this problem, obtain the following fix or wait for  the
    next Windows NT 4.0 service pack:

        ftp://ftp.microsoft.com
        /bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP3/srv-fix