Kerberos Weaknesses: Pass the Ticket Is a Real Threat

August is always a good time to check up on the dark side.  Black Hat had its annual conference earlier this month, and there are always presentations worth looking at. I’ve been writing about Kerberos recently, and while it’s a big improvement over Microsoft’s NLTM, nothing is ever perfect. I came across a presentation that looks more closely at the weaker points of Kerberos.

Let me point out that researchers have seen attacks launched against Kerberos, but not nearly as frequently as ones targeted at the more widely deployed NTLM. The hackcraft for Kerberos is newer, and in fact one of the more ominous attack possibilities has only recently been addressed—I’ll get to that later.

The tough three-headed doggie has a few fleas.

The one I know about involves passively listening on the wire, scooping up packets involved in the last part of the Kerberos exchange. Remember that? The client already has the final ride ticket — the Server Ticket — and the server session key. So when the request to the actual service is made, the client just has to encrypt some identifier information with the server session key and then add the Server Ticket.

If hackers could resend that last exchange—yeah, this is a replay attack—then in theory they could access the service. But Kerberos time stamps everything, so the attacker would have to work quickly. And since IP sources address can be part of the identifier information that’s encrypted, the hackers should in theory be stopped in their tracks.

Is there another way to break Kerberos?

Metadata Era blog readers know that our fundamental philosophy is that the hacker will get in. Or to put it another way, cryptography ain’t that healthy. The underlying issue, of course, is that hackers are more adept at getting through the front door and looking at formerly hidden parts of the crypto-machinery.

With that in mind, the Black Hat presentation shows a PtH-style attack for Kerberos, using, what else, but tickets—i.e., PtT.  The slides tell us that in Windows environments the TGT and session ID  are kept in memory, and in fact the same part of memory that the NTLM hashes are stored— Local Security Authority Subsystem or LSASS.  Who would have thunk it?

Security pen testers have already figured out where in LSASS the Kerberos tickets reside, and they now  have the tools to pull these out— one of the presenters, Benjamin Delpy, did the heavy lifting here.

What does all this mean? A lot of the advice we gave about PtH would seem to apply to Kerberos as well— overall, you want to reduce the chances of higher-privilege tickets from being scooped up. In Kerberos’s favor, though, is the setting of the expiration period for the TGT—in Windows, it defaults to a lifetime of 10 hours.  So the attackers would have to work somewhat speedily.

But what if the ticket had an incredibly long lifetime—perhaps measured in years—and had broad authorizations? That scary idea—known as “The Golden Ticket”—is taken up in another part of the presentation.

And I’ll talk about that in my next post.