Sunday, April 5, 2015

No, Microsoft Hasn't "Fixed" Silver Tickets

Contrary to what many folks might think, I don't wait around on the Internet for somebody to be wrong to blog about it.  However, when somebody misrepresents research that myself and others have worked on, there's something to talk about.  Especially if this "advice" leads to sweeping incorrect statements that could lead C-level folks to think that an entire class of problems has been fixed when they haven't.  This is a problem :/

The post is here: http://blog.varonis.com/microsoft-fixes-kerberos-silver-ticket-vulnerability/

It's also a bit old, from December of last year, but @Gentilkiwi (Ben / Author of Mimikatz) recently pointed it out.

And it makes enough mistakes and confuses enough concepts that I felt it necessary to make sure at least one source on the web corrects the misconceptions....

What He Got Right

The author did a decent job in previous blog entries (at least from a skim) of explaining the Kerberos process and has a decent grasp on Golden Ticket Attacks.  I'll also forgive him for not updating the post or referencing in a new post Microsoft's official KRBTGT changing script found here: (blog) http://blogs.microsoft.com/cybertrust/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/
(download) https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51

Where Things Go South

So things start getting a little misunderstood talking about Service Tickets.  There's a couple points I would like to make.  Generally speaking : 

1) Service tickets destined for something the target computer deals with (file shares, rpc calls, etc) use the target computer's AD account to sign the service ticket.  The computer account is (by default) changed every 30 days or so and has a long random unicode password.  You in all likelihood will never be able to guess this password.  However, with local admin on the box or physical access, they are trivial to recover.

2) Service tickets destined for a service running as a different account (SQL server, Exchange Server, etc) will use the service account password for that particular service as the signing key for Kerberos requests.  There is a chance you can guess these passwords, since they are service accounts.  Tim Medin's research focuses on getting something to crack offline by creating a fake SPN (service principal name) and requesting service ticket(s) ( https://github.com/nidem/kerberoast / http://www.irongeek.com/i.php?page=videos/derbycon4/t120-attacking-microsoft-kerberos-kicking-the-guard-dog-of-hades-tim-medin )

Silver tickets allow an attacker to generate arbitrary service tickets when the attacker has the service account hash / password.  PAC validation is disabled by default for accounts running as services.  For more details, refer to one of my previous posts which quotes the official MS specs : http://passing-the-hash.blogspot.com/2014/09/pac-validation-20-minute-rule-and.html

No, MS14-068 Did NOT Fix Silver Tickets

Joe Bialek from Microsoft did a great job of talking about the vulnerability fixed by MS14-068 here: http://blogs.technet.com/b/srd/archive/2014/11/18/additional-information-about-cve-2014-6324.aspx

The short version is that prior to this patch there was an edge case in the Kerberos spec that could allow an attacker with a user account password/hash to modify the PAC and then the KDC would validate it as legit. The end result was an elevated TGT account.  This is completely unrelated to silver tickets.  This was an exploit against Kerberos.

Silver tickets will continue to work with the MS14-048 patch installed.

A Note to the Author

Mr. Green, feel free to reach out to me, @gentilkiwi, or @josephbialek if you need any more clarification.