Old Microsoft Kerberos vulnerability gets new spotlight

A new blog post covering a number of authentication vulnerabilities in Kerberos implementations, including Microsoft's, has stirred up new awareness of old, but dangerous flaws.

Security researcher @dfirblog detailed various ways to attack Kerberos using pass-the-ticket attacks, pass-the-hash attacks or a forged privilege attribute certificate (PAC) to allow an adversary to bypass the authentication system. In the worst vulnerability, an attacker could create a golden ticket in a Microsoft Kerberos environment, and then grant themselves admin rights and create secret passwords for existing users or for new users that don't exist.

This can be done because in Microsoft Kerberos, the key distribution center (KDC) encrypts and signs ticket-granting tickets (TGT) and PAC data using the secret key of the krbtgt account, which is created by default. The vulnerability is more hazardous because the krbtgt account is disabled and not used, so the password is rarely changed, and Microsoft Kerberos stores the past two passwords associated with that username in memory.

In the blog post, @dfirblog noted multiple ways to obtain that secret key and said once the key was in hand, an attacker would have 20 minutes before the user account is validated to do "impossible stuff like creating tickets for nonexistent or disabled users." Otherwise, an attacker would have to create a golden ticket to gain full access until the golden ticket expires, which can be set for any custom period.  

The security researcher told SearchSecurity that the vulnerabilities using forged PAC, or leading to the creation of golden or silver tickets, only affect Microsoft Kerberos and not MIT Kerberos, because Microsoft uses the proprietary PAC authorization extension.

Jeff Schiller, enterprise architect at MIT in Cambridge, Mass., and one of the original authors of the Kerberos authentication system, confirmed that this authentication vulnerability is specific to Microsoft's Kerberos implementation.

"The krbtgt user account should have a key, which is not derived from a password. In the MIT implementation, it is randomly chosen," Schiller told SearchSecurity. "One of the requirements of Kerberos is that the KDC must be secure. It contains literally all the secrets. If the KDC is compromised, it is game over. Placing the KDC inside the domain controller with a lot of other services increases the attack surface, making it easier for an attacker to break in. Many of the attacks outlined in the blog post are facilitated by access to the memory of the KDC."

According to @dfirblog, changing the password for the krbtgt account twice in rapid succession could prevent new tickets from being made, and continuing to change the password regularly would limit exposure, but there is little to be done in terms of mitigating attacks.

"Mitigation of most of these attacks is not possible, as this is simply how Kerberos works in the Windows environment. For the most part, you need to focus on protecting privileged accounts at all cost, because this is what attackers are after and protecting everyone is not possible," @dfirblog wrote. "Otherwise, you will lose control of your network really fast. The most effective mitigation, at the moment, seems to be Protected Users group and Credential Guard."

Microsoft's Credential Guard prevents passwords from being stored in memory.