[jcifs] No response to NTLM challenge: **SOLVED**

[Eric Glass]

> Thanks for sending on the source. I have applied it, though as you
> suggested the patch does not fix the issue for NTLM2!
> 
> I appreciate am may be straying into M$ land now, though I am still
> thinking about the patches that you sent previously: could you explain
> the significance of the settings of the NtlmMinClientSec registry values
> to me? (Or point me at a source?) The reason I ask is that we currently
> have NtlmMinClientSec and NtlmMinServerSec set to 0x00080000, and I
> would like to understand the implications of changing these to another
> supported value. I haven't found the M$ site to be very helpful on this
> - amazingly enough! ;)
> 

The NtlmMinClientSec/NtlmMinServerSec is a bitmask over certain NTLM
flags affecting session security (signing & sealing).  When set, the
NTLMSSP will require the appropriate options to be negotiated in the
handshake.

Really, session security isn't relevant to HTTP authentication; it's
typically used in RPC, where after authentication occurs the
connection is encrypted and/or signed using a symmetric session key
established during authentication.  But since authentication is where
the options are negotiated, that's when the machine enforces the
policy.

In your case, the client and server are requiring support for NTLM2
signing & sealing.  The NTLM responses in the Type 3 message are
changed when NTLMv1 authentication is used with NTLM2 session security
(if you look at the "iis-ie6.pcap" capture you sent previously, you
can see the difference; the NTLM response is 24 bytes like "normal",
but the Lan Manager response is only 8 bytes (null-padded to 24
bytes)).  Specifics on the NTLM2 session response are here:

    http://davenport.sourceforge.net/ntlm.html#theNtlm2SessionResponse

The NTLM2 session response increases security in two ways:

1) The "normal" LanManager response is based on the uppercase
password.  This significantly reduces the work factor to break the
password (since "PaSSworD" and "PASSWORD" are effectively the same). 
In the NTLM2 session response, the Lan Manager response is replaced by
an 8-byte random client nonce.

2) The NTLM2 session response protects against precomputed dictionary
attacks.  A malicious server could take a large dictionary of
passwords, and then calculate the correct responses for a fixed
challenge.  It could then always send that challenge to the client,
and look for matches in the dictionary based on the client's response.
 In NTLM2, the NTLM response is based on both the challenge and the
nonce (which is chosen by the client, and is different each time).  To
perform the same attack, the server would have to compute the
dictionary for each challenge/nonce pair.


There are a couple of options you could likely pursue to get things
working with jCIFS:

1) Set only NtlmMinServerSec on your workstations.  Basically, you
would have the client boxes *not* enforce NTLM2.  Your servers would
still require the client boxes to negotiate NTLM2, but the client
would no longer complain if the server didn't support it.  Of course,
that kind of defeats the protection against malicious servers.  It
would also allow man-in-the-middle attackers to downgrade the
authentication and run the same precomputed dictionary attack (the
real server would complain that the client didn't negotiate NTLM2, but
by that point the MITM has already harvested the response).

2) Use NTLMv2 authentication on your clients.  This is set in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

Set it to "3" on your clients; this will send the LMv2 and NTLMv2
responses, which jCIFS can support.  You would set the
"jcifs.smb.lmCompatibility" parameter on jCIFS to "3" as well.  jCIFS
will use the LMv2 response to authenticate on the backend.  You would
need to apply a similar patch to before (to add the
NTLMSSP_NEGOTIATE_NTLM2 flag into jCIFS response, since the client
would still be enforcing this flag).  But jCIFS should be able to
handle the responses properly.


Eric