Poor authentication used with NT domain controllers for authenticating SMB requests.

Date: Fri, 6 Feb 1998 17:50:59 +0000
From: Paul Ashton <paul@ARGO.DEMON.CO.UK>
To: BUGTRAQ@NETSPACE.ORG
Subject: Breaking SMB signing and other holes

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

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. You can read all about these session
keys in:-

ftp://ftp.microsoft.com/developr/drg/CIFS/CIFS-Auth-Spec.doc
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. i.e.
if your password is 7 characters or less, this is
your password equivalent. Let me just emphasise
this. If I sniff the network and learn a challenge
response pair I can ask the domain controller to
send me the two session keys. If the password is
7 characters or less I can impersonate them at will.
I posted a patch to Samba that does this on the
ntbugtraq list a few months ago.

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 I mentioned previously, or any
method of your choosing.

I'm sure people will be able to come up with all
sorts of other horrible implications of this.

Note: I don't have any code to exploit any of this,
but it would be quite easy to put into Samba, so
if anyone from Microsoft would like to refute any
of this, please go ahead.

Paul