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