Options for reducing NTLM exposure (was: Re: Can samba mitigate the vulnerability of NT hashes?)

Andrew Bartlett abartlet at samba.org
Wed Jan 9 17:07:44 MST 2013


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

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org




More information about the samba-technical mailing list