Options for reducing NTLM exposure

[David Collier-Brown]

On 01/09/2013 07:07 PM, Andrew Bartlett wrote:
> On Wed, 2013-01-09 at 17:04 -0600, Christopher R. Hertel wrote:
>> On 01/09/2013 04:47 PM, David Collier-Brown wrote:
>>> On 01/09/2013 04:29 PM, Christopher R. Hertel wrote:
>>>> Dave,
>>>>
>>>> There is information in my book about the settings used to force
>>>> LMv2/NTLMv2 authentication.  Note that there is no negotiation, so the
>>>> client in particular has to be configured to disallow v1.
>>>
>>> Bother!  I was really rather hoping that we could offer only the "good
>>> NTLMs" in a negotiation and thereby have the older clients behave securely.
>>
>> Well...  the way to enforce this is to have the servers require LMv2/NTLMv2. 
>>   I suppose that Samba could be made to accept only NTLMv2.  In that case, 
>> clients that use LMv1/NTLMv1 would fail to authenticate, thus prompting a 
>> wringing of hands and an outcry from the masses to please allow us to run 
>> naked on the Internet with big signs saysing "shoot me now, shoot me now".
>>
>> Eventually, those clients would be configured to use the better 
>> authentication mechanisms, possibly bypassing NTLMv2 and going straight to 
>> Kerberos or somesuch.
>>
>> I believe, in fact, that Windows servers may already come configured out of 
>> the box to accept only LMv2/NTLMv2, but I'm not certain.  Worth checking.
> 
> This is, essentially, the problem.  If we turn this on, and break many
> existing clients without any way to negotiate with them to improve what
> they send, we (and the vendors we supply) get seen as 'breaking the
> world', without a good way to fix the clients. 
> 
> The other issue is that there are too many things that pretend to be
> NTLMv2 (for Microsoft's definition of NTLMv2 only) that are not, as I
> understand things.
> 
> For example, MSCHAPv2.  This, as the paper explains, is really not
> significantly more secure than NTLM.  If we have an NTLMv2 only domain,
> do we want to break MSCHAPv2 VPNs and wireless (802.1x) clients?
> 
> We have done what we can in our clients.  Samba 3.6 and later sends only
> NTLMv2 by default in the client, and I think I worked with the team to
> close off LM in a previous release. 
> 
> I have pondered doing things like requiring NTLM2 session security (the
> mode where the client specifies part of the challenge for NTLM) in our
> client and server.  Essentially the same algorithms as the 'broken'
> MSCHAPv2 this would at least avoid chosen challenge attacks, but does
> nothing if the attacker can cheaply break an arbitrary challenge.  (This
> would break connections to 'security=server' samba servers, and any
> server that doesn't support NTLMSSP, but most users would not notice). 
> 
> This last step is about the only thing I think we can do in the short
> term.  For the client, we could plausibly, with warning, do it in the
> 4.0 series if we want to have some useful response here.  (It is harder
> to justify doing it in the server, but we could for 4.1).
> 
> Andrew Bartlett

Instead of proposing a change in Samba that requires one know what
clients will fail,
I would be inclined to work with a customer concerned about the security
issue, and
with their help write a HOW-TO about securing NT clients and optionally
migrating them to a (virtual) server that only supports a secure
configuration.

A lot less attractive than changing values in a negotiation (:-()

--dave
-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain
(416) 223-8968