MIT krb5 for Samba4 (was: Re: Force NTLMv2 only on our server? (was: Re: krb5 vulnerability ?))

[Andrew Bartlett]

On Tue, 2015-12-15 at 08:26 +0100, Andreas Schneider wrote:
> On Monday 14 December 2015 20:53:23 Jeremy Allison wrote:
> > On Tue, Dec 15, 2015 at 03:38:19PM +1300, Andrew Bartlett wrote:
> > > On Mon, 2015-12-14 at 17:34 -0800, Jeremy Allison wrote:
> > > > On Mon, Dec 14, 2015 at 05:17:59PM -0800, Jeremy Allison wrote:
> > > > > Interesting post here:
> > > > > 
> > > > > http://dfir-blog.com/2015/12/13/protecting-windows-networks-k
> > > > > erbero
> > > > > s-attacks/
> > > > > 
> > > > > Still reading it myself to try and understand
> > > > > if it's a real issue of not, but thought the
> > > > > list would be interested.
> > > > 
> > > > Hmmm. Doesn't look real as far as I can see
> > > > (the article is full of hyperbole).
> > > > 
> > > > It's got lots of phrases like:
> > > > 
> > > > "So, if we have an access to the key.."
> > > > 
> > > > "if we’re able to steal those tickets and somehow
> > > > insert them into our own system"
> > > > 
> > > > "It’s just an account in domain controller
> > > > database, so your obviously need access to DC or it’s data."
> > > > 
> > > > So looks like a "if we can break the security
> > > > then we've broken the security" article :-).
> > > > 
> > > > Move along, nothing to see here, sorry for
> > > > the noise.
> > > 
> > > More of a worry is that per one of the talks at KiwiCon, cracking
> > > an
> > > NTLM (not NTLMv2) response is down to $100 and 8 hours on a cloud
> > > computing provider.  That gives you the NT hash, which you can of
> > > course use to get a krb5 ticket, or just do NTLM logins. 
> > > 
> > > I think we should disable NTLM (when not NTLMv2) for 4.4 by
> > > default,
> > > possibly with an optional exception for MSCHAPv2.
> > 
> > +1 from me. NTLM has gone the way of DES now....
> 
> You are aware that Samba with Heimdal Kerberos does RC4 by default?
> 
> We fixed serveral bugs (e.g. wrong saltPrincipal) in the Samba source
> code 
> because MIT Kerberos uses AES and Samba was not able to deal with it.
> It still 
> fails to do so without patches from my MIT Kerberos work in progress
> tree ...

Yes, I'm aware of that.  However I'm not aware of the same kind of
attacks on arcfour-hmac-md5, because while MD5 is weak, HMAC-MD5 is
still considered strong, and the arcfour use involves (like schannel) a
confounder, that avoids the biggest weakness of RC4, because the first
encrypted bytes are of random data.

I continue to look forward to the MIT merge - we don't have a choice in
any case:  Heimdal is essentially dead (read the recent inability to
release thread on heimdal-discuss), and we need to un-hitch from that
wagon now.  It makes me very sad, but I don't have the resources (eg
become the Heimdal maintainer) to change those facts on the ground.  

We still need to sort out some logistical matters (like how we would
get patches, like the ones metze often does into our fork upstream into
MIT), and how we keep the test coverage from my insane
'decode/inspect/reencode the packet' tests, but as I said at SambaXP,
the question is how, not if, we do this.

I wish I could do more, but for everyone's clarity I need to declare
that I'm swamped for small amount of time I'll be working over the NZ
summer, particularly before linux.conf.au.

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba