PTH and Kali - Status

I was directed to this bug report on the Kali list relating to the PTH-suite being missing:

So, where are we at?

I'm working on it.  The big difference between Backtrack and Kali is that Kali is based on Debian and the maintainers are trying to stick to the 'Debian' way of doing things.

When Putehate and I put together the package for Backtrack, we just shoved everything into a single package and stuck it in the repo.  The package didn't have any deps listed, no source was included, etc.  The 'Debian' way of doing things has the package manager itself build the packages from source.  This means that I actually have to pay attention to the extra bits that control package behavior as opposed to just packaging up a bunch of pre-compiled files.

This is actually a good thing because it makes it easier to update individual packages.  Also, it can actually bring less impact to the existing system.  Do you know the difference between PTH Samba 4 + Openchange and regular Samba 4 + Openchange?  One single shared library file.  So if I package that single library up all the existing Samba 4 / Openchange tools can PTH.  Remove that package and you have regular functionality.

Next week I'm on an assessment with Brav0Hax, one of the Kali maintainers and we are going to try to get a bunch of stuff packaged up.  I'll also try to get some functional stuff up on the google code page here in the not too distant future.  Unfortunately in the last year there's been a number of updates on some packages that make my build scripts fail.  I'll try to get that stuff updated sooner rather than later for folks to get back up and going quickly.

I'm also going to see what happens if you just take the package from Backtrack and dump it into Kali.  That could be a messy explosion or it could work fairly well with a couple of minor tweaks.  I'm not sure yet.

Thanks for the patience and know that I'm working on it ;-)

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...

*sigh*

Mimikatz and Digest Auth

Benjamin Delpy, aka Gentilkiwi (http://blog.gentilkiwi.com/) 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... 

Quick update - More to come

It's been a little over a month since I last updated the blog.  Had a lot going on.  I quit my old job, took a couple weeks off, then transitioned to the Accuvant Labs team.  I've also been working on multiple Blackhat/Defcon/Bsideslv CFPs. It's been busy!

I plan on getting the blog post giving an overview of Windows authentication here shortly.  Hopefully the next post will be up soon!  I was going to start with tokens, but I think an overview of windows authentication is necessary first.

Sorry for the delay!