Details emerge on Windows Kerberos vulnerability

The Windows KDC didn't properly validate parts of Kerberos tickets. It may be possible for admins to detect if they have been exploited.
Written by Larry Seltzer, Contributor

Microsoft's out-of-band update yesterday fixes a profoundly serious bug: Any user logged into the domain can elevate their own privilege to any other, up to and including Domain Administrator. When I saw in the advance notification, that one of the bugs was an elevation of privilege bug and rated critical I knew something different was up.

Later in the day Microsoft released a Security Research and Defense (SRD) Blog entry that explains the vulnerability in more, though still limited detail.

First, some good news: "Azure Active Directory does not expose Kerberos over any external interface and is therefore not affected by this vulnerability." That could have been nasty.

It turns out that Windows Servers 2008 R2 and below are vulnerable to the flaw. Windows Server 2012 is vulnerable to a related, but much harder to exploit attack. Desktop Windows is not vulnerable, but they issued the update for desktop systems anyway. The code is in the desktops, it may as well be correct.

This explains Microsoft's priority list for applying updates:

  1. Domain controllers running Windows Server 2008R2 and below
  2. Domain controllers running Windows Server 2012 and higher
  3. All other systems running any version of Windows

Don't take any breaks until you finish #1.

To understand the bug you need to know a little about how Kerberos works. Microsoft provided the following illustration:

How Kerberos Works
image courtesy Microsoft

At one point in the process (#2) the KDC (Key Distribution Center, the vulnerable component in the domain controller) sends the client a data structure called a PAC (Privilege Attribute Certificate) containing a digitally signed section itself containing information about the user's security privileges (the user's domain SID and security groups to which he belongs). The user then resends this ticket to the KDC in exchange for a Service Ticket which it can use to authenticate with Windows services.

Here's the problem: The KDC does not always properly validate the digital signature in the PAC sent back to it in request for a Service Ticket. This means it is possible for a user to forge data in the PAC about their privileges, such as by assigning themselves to the Domain Administrators security group.

Microsoft describes a way to determine if you have been exploited prior to applying the update, but it's just a test for some kinds of exploits, including those observed in the wild. Other techniques are possible which would not be detected in this way. Consider the following Security Event Log entry:

Sign of an exploit
image courtesy Microsoft

Note that the Security ID and Account Name are different. They should be identical.

After you apply the update it is possible to use a different event to look for evidence of exploit attempts.

Take this with deadly seriousness. As the description in the NVD (National Vulnerability Database) says, it's high impact and easy to exploit. And if you are exploited, the price is high, irrespective of any damage the attacker does: The only way to remediate is to rebuild the domain from scratch. Don't let this happen to you.

Editorial standards