"Secure" channel demystifying?

[Eric Glass]

> > But not in the same order.. Look how the challenge is
> > generated. This mode of the NTLM/LANMAN protocols is only
> It's generated on the member server that is accessed.
> 
> > available from the domain controller because of the trust
> > chain established by the domain computer account.
> Can't figure out that. Why?
> 
> > > Where is that "protection" ? :(
> >
> > It is not the NTLM challenge/response which is protected,
> > this is public information. What is protected is the user
> > session key contained within the netlogin response. Not
> > strongly protected, but protected. The user
> > session key is not part of NTLM but is used in other aspects
> > related to
> > authentication.
> What it (session key) is used for?
> 

I'm not terribly familiar with the "dirty" details of NETLOGON, but I
can speak from what I understand (possibly incorrectly) to be the
general process:

The user session key is used as the basis for SMB MAC signing between
the client and member server (in this sense; it has other uses as
well, such as NTLMSSP sign & seal).  The "old" (passthrough)
authentication went like this:

1) Client connects to member server.
2) Member server connects to DC, gets a challenge.
3) Member server sends challenge to client.
4) Client sends challenge response to member server.
5) Member server forwards response to DC, who verifies it is correct.

Basically, the member server is a benevolent man-in-the-middle between
the client and the DC.  The problem with this scenario is that a
malicious man-in-the-middle could be sitting between the client and
member server; such an entity could hijack the session after
authentication and modify/inject commands to the member server as the
client.

The NETLOGON style works like this:

1) Client connects to member server.
2) Member server generates its own challenge.
3) Member server sends challenge to client.
4) Client sends challenge response to member server.
5) Member server sends both challenge and response to DC over the
NETLOGON secure channel.
6) DC verifies response is valid for challenge and sends back the user
session key.
7) Server signs and verifies using the MAC key (which is derived from
the session key).

The client can calculate the session key because it knows the
password.  The member server gets the session key from the DC (which
has the password-equivalent hash).  Since the member server gets the
session key directly from the DC, it doesn't need to know the user's
password (and shouldn't).  A man-in-the-middle doesn't have the
session key, and therefore cannot tamper with the transactions between
the client and the server.

The assumption in this scenario is that the transfer of the user
session key from the DC to the member server is indeed secure.  The
NETLOGON channel is mutually authenticated, ensuring the member server
and DC both have knowledge of the member server's machine credentials.
 Signing and sealing the secure channel using a key based on the
machine credentials serves to protect the transfer of the user session
key.


Eric