Old Topic: Re: NT Security Alert: (was Re: NTDOM: SamLogon

[Luke Kenneth Casson Leighton]

phil,

the "pass-through" authentication described in the cifs documentation has
absolutely nothing to do with dce/rpc "network" logins that achieve
exactly the same end-result.

if the conversations i had with paul ashton at around the time we worked
out what the dce/rpc "network" logins tie in with the message below
(03/02/98) then referring to the cifs documentation is misleading: paul is
referring to the dce/rpc "network" logins not the cifs documentation.

luke


On Tue, 28 Apr 1998, Phil Cox wrote:

> At 07:50 PM 2/3/98 +1100, Paul Ashton wrote:
> 
> >At 01:18 03/02/98 , Paul Ashton wrote:
> 
> >>From a quick look at a packet trace, the original client that wishes
> 
> >>to access a share does an SMB negotiate and receives an 8 byte
> challenge,
> 
> >>it then does a session setup & X with a 24 byte challenge response.
> The
> 
> >>The SMB server then forwards the challenge and the response to the 
> PDC
> 
> >>without encryption. The PDC confirms whether the response was valid
> and
> 
> >>if so, returns the password hash to the SMB server (rc4 encrypted) so
> 
> >>that the SMB server could then forward the hash to other servers on
> 
> >>behalf of the client. 
> 
> >
> 
> >This means that anybody passively listening to the LAN can turn
> 
> >any NTLM challenge response sequence into a password equivalent!
> 
> >Just forward the challenge and response of a sniffed packet to an
> 
> >NT DC and it will send you the password equivalent.
> 
> 
> Just a clarification for myself. It seems to me that the challenge can't
> be replayed, because it must be the challenge that was sent during the
> "server to PDC" SMB negotiate portion of the pass-through authentication
> (steps 4-6 below)? Since this challenge is originated from the PDC (step
> 5), the server should not be able to just send it a
> challenge/challenge-response pair for validation. Is this not correct?
> Any clarification is appreciated.
> 
> 
> >From the CIFS Logon and Pass Through spec:
> 
> <bigger>The steps involved in pass through authentication are:
> 
> 
> 1 The CIFS client sends a negotiate SMB to the CIFS server
> 
> 2 The CIFS server verifies the cached Domain Controller name (as
> 
>   described above)
> 
> 3 If the cached name is invalid, the CIFS server does a Domain Controller
> Discovery
> 
> 4 The CIFS server  sends a NEGOTIATE SMB to the Domain Controller
> 
> 5 The NEGOTIATE response along with the challenge is saved by the CIFS
> server
> 
> 6 The CIFS server sends a NEGOTIATE response (to client) using the saved
> challenge
> 
> 7 The CIFS client computes the challenge response as detailed in the CIFS
> specification, and then challenge response is sent as part of a
> SessionSetupAndX SMB
> 
> 8 The CIFS server extracts the challenge response from above SMB
> 
> 9 The CIFS server sends it's own SessionSetupAndX SMB to the domain
> 
>   controller using the extracted challenge response
> 
> 10 The Domain Controller sends a SessionSetupAndX response to the CIFS
> server. This response will be successful if the CIFS client had
> 
>   provided the correct response.
> 
> 11 The CIFS server tears down the session with the Domain Controller
> 
>   that was established using user credentials. This is accomplished by
> means of a LogOffAndX SMB.
> 
> 12 The CIFS server sends a SessionSetupAndX response to the CIFS client.
> This response is based upon the response from the Domain Controller.
> 
> </bigger>
> 
> 
> Phil Cox
>