Wednesday, March 13, 2013

Windows Auth - The Nightmare Begins (SSO)

I'm going to start with an overview of Windows authentication and why it's such a large, complicated, unwieldy beast.  I'm not going to go into too much detail as there are lots of posts and papers on the subject, however I will hopefully give enough detail for most folks to follow along.

Single Sign On - The Real Problem

Everybody knows that there is a trade-off between security and usability.  If a system is too complicated then nobody would use it.  If it has no security, then nobody want to store data on it.  So there needs to be balance.

"Single Sign On", henceforth "SSO", is an authentication scheme where the user is only prompted to type their username/password once and the back-end makes every attempt to keep the user from having to do it again.  The idea is that everything a user needs to authenticate to is tied together (websites, computer, file shares, email, etc).  There's a little more to it than that, but you get the gist.

Is this a good thing?  As a user, I don't mind typing in my password a couple of times here and there.  However, having to log into a computer, then log into a website, then log into email, etc can be a tad annoying.  Especially if your password is 30 characters and is a mix of lower, upper, numbers and symbols.

However, it can also be a bad thing.  If a user doesn't lock their computer before wandering off to the coffee pot or whatever, then somebody can sit down at the computer and do everything in the context of that user.  

Ultimately most places use screen savers that automatically lock after a certain amount of time, forcing the user to re-authenticate with their username / password if their computer is left idle too long.

Ok, so many of the issues with SSO can be mitigated by finding a balance.  What's the big issue?

The problem comes in the back-end implementation.

Parlez-Vous Digest Auth?

Tying together multiple back-end authentication schemes typically has some challenges.  For example, let's look at part of a packet capture between a Win 7 workstation and a domain controller when ADUC (Active Directory Users and Computers) is used.  ADUC uses LDAP to communicate with the DC and  LDAP doesn't directly support authentication mechanisms, instead it relies on the SASL (Simple Authentication and Security Layer) library.  From the screenshot below you can see that the DC offers 4 different SASL authentication methods: GSSAPI, GSS-SPNEGO, External, and DIGEST-MD5.

SASL Authentication Mechanisms supported by AD

  • GSSAPI - Generic Security Service Application Program Interface.  In this context it generally means "use Kerberos"
  • GSS-SPNEGO - Generic Security Service Simple and Protected Negotiation.  In this context it means "try to use Kerberos first, then switch to NTLM"
  • EXTERNAL - This means that the authentication is implied by the context, IE IPSec or TLS is in use
  • DIGEST-MD5 - This is an authentication mechanism sometimes used for HTTP authentication.  Essentially it  takes the security information and hashes it along with a nonce provided from the server.

Wow.  That's a lot of authentication crap to deal with for a simple LDAP query.  When ADUC was fired up I wasn't prompted for a password.  The actual authentication mechanism that was used in this case was GSSAPI in the form of Kerberos.  ADUC passed my Kerberos ticket to the DC on my behalf without me doing anything.

However, the Windows client is capable of handling the other forms of negotiation as necessary.  

Windows SSPs

It turns out Windows has many "Security Support Providers".  These allow the SSO functionality to operate transparently to the user.  Here's a brief list of the most relevant ones:

NTLMSSP - Provides NTLM capabilities, fairly straightforward
Kerberos -  Provides Kerberos also fairly straight forward
Negotiate - Try Kerberos then NTLM
Digest SSP - provides hash based authentication for HTTP/SASL

There are more SSPs and there's even a way to introduce custom SSPs if necessary.

The interesting thing to think about is, if the goal is to prevent the user from having to type in their password, how do we guarantee that we can support each of these disparate SSPs?

NTLM and Kerberos can use hashes, so there's no need to do anything with the password aside from hashing it, right?

The problem lies with DigestSSP.  How can we guarantee that we can supply the required digest if we don't ask the user for the password every time it's needed?

Sadly, the answer is you store it in memory...


Mimikatz and Digest Auth

Benjamin Delpy, aka Gentilkiwi ( discovered that the passwords themselves were being kept around in memory for use with the DigestSSP.  Initially he introduced functionality with his tool 'mimikatz' to dump the passwords stored for the digest auth package.  It turns out passwords are stored elsewhere as well.  Read his blog (it's in French).  Bring tissue, cause it'll make you cry. 

 This actually makes sense from a SSO standpoint if pestering the user for his PW is to be avoided, but the obvious question is WTFO?  Gotta love backwards compatibility and a focus on user experience... Oh, btw,  Digest Auth is enabled by default.

SSO What?

So, as it turns out, SSO has bit us in the proverbial "fourth point of contact".  By focusing on user experience over common sense security somebody (or a series of somebodies) at MS really got us good on this one.

But Wait, There's More!

My next post is going to talk about more issues with Windows authentication.  Then I'll prob start on tokens... then... we'll see where we go from there... 

No comments:

Post a Comment