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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:41:48 PDT