[jcifs] NTLM and JCIFS: architecture/protocols

[Eric Glass]

> 2) If the server does not have direct (encrypted) access to the database,
>    then it performs a proxy login.  It requests a login from the Domain
>    Controller (or other server), which sends the challenge.  That challenge
>    is then passed along to the client, which creates the response.  The
>    response is then "passed through" to the DC.
>
> The second method is great because it allows a system that is not a domain
> member server to use domain authentication.  You may have noticed, however,
> that it is also the formula used to create a man-in-the-middle attack.
>

In the newer NETLOGON scenario, the intermediate web server (or file
server in the case of CIFS) generates the challenge; both the
challenge and the client's corresponding response are sent to the
domain controller over the NETLOGON RPC pipe, and the DC indicates
success by providing the session key back to the intermediate server.
This has a couple of advantages over the straight passthrough in the
case of CIFS:


1) It allows SMB/CIFS signing between the client and intermediate
server (this is not possible in a passthrough scenario, since the
intermediate server does not have access to the raw password hash
needed to calculate the session key).

2) It prevents the man-in-the-middle attack previously described (as
the NETLOGON pipe is mutually authenticated, the DC "knows" it is
actually talking to the intermediate server).


In the case of HTTP, the advantages are minimal (since there is no
signing/MAC between the web browser and web server).  It does provide
some assurance against rogue web servers I suppose (since if all
servers are configured to require signing, a malicious web server
would hypothetically not be able to participate).

In the jCIFS case, we do "preauthentication" to get around this;
basically the web server makes a CIFS connection to a backend server
(DC or other domain member), acting as a man-in-the-middle; we exploit
the fact that SMB/CIFS signing establishes a session key for each
physical connection rather than each authentication.  So we connect
using an account for which we have the credentials, setting up signing
with a key derived from the known password, and can then use that
established pipe to act as a man-in-the-middle for subsequent
authentication requests.


Eric