Two of the big vulnerabilities in Microsoft’s Patch Tuesday updates this month were CVE-2022-26923 and CVE-2022-26931who affected authentication security in Windows.
Even though these were supposedly EoP holes rather than RCE bugs (elevation of privilegeinstead of the more serious problem of remote code execution), they were nevertheless rated Criticalsince the bugs applied to Active Directory (AD) and Windows Domain Controllers (DC).
The name domain controller means exactly what it says: domain controllers are servers that handle authentication and access control for users, computers, services, and devices for an entire network domain .
An old Latin satirical poem asks ironically, “Quis custodiet ipsos custodes?” (Who will guard the guards themselves?), and in the case of a Windows network, the short answer is that the guard guarding everything else is your domain controller.
In other words, an authentication bypass against your domain controller could quickly lead to the compromise of almost everything else in your network.
Mismanaged digital certificates
Simply put, anyone who is already on your network, even if they are logged in with (or have compromised) an account with minimal access rights, could use domain controller EoP bugs. Of this genre to grant themselves the same kind of power that only your most trusted system administrators would normally be allowed.
Ironically, bugs CVE-2022-26923 and CVE-2022-26931 only seem to apply if you’re using digital certificates for increased authentication security.
(These are the same type of digital certificates that browsers and websites use to secure HTTPS connections, or applications use to prove to the operating system that they haven’t been tampered with since they were approved. )
Apparently adding a
$ sign at the end of a computer name could lead to erroneous verification of authentication certificates, as could the creation of cleverly crafted certificates identifying the certificate holder in two different and inconsistent ways.
Even though these weren’t RCE bugs; even if these were not already zero-days known to cybercriminals; and even though attackers would have to break into your network first to be able to exploit them…
…you can see why Microsoft would consider them critical bugs.
One step too far
Unfortunately, the KB5014754 The update went a bit too far in some cases, and by acting to make it harder for fake users and programs to get where they shouldn’t, Microsoft also caused some legitimate services to be locked down.
Some Windows services trying to authenticate with digital certificates could end up being looked up in the wrong place in the Active Directory database, and therefore being denied access when they should have been allowed.
Microsoft was quick to acknowledge the issue, with Elizabeth Tyler from the Detection and Response team tweeting just two days after the patch on Tuesday to say:
We are aware (as you can imagine). We know the root cause is that the subject name is incorrectly used to map the certificate to a machine account in AD rather than the DNSHostname in the subject alternative name on domain controllers that have 5b installed and we are working.
— Elizabeth Tyler (@MSetyler) May 12, 2022
Apparently there was a workaround, officially explained by Microsoft in their article KB5014754, but it involved manual update a database entry titled
altSecurityIdentities in the Active Directory database record of each service.
Elizabeth Taylor returned to Twitter today to confirm that this bug fix has now been fixed:
Yes, corrected and published on May 19.
WS 2022: KB5015013
WS, version 20H2: KB5015020
WS 2019: KB5015018
WS 2016: KB5015019
WS 2012 R2: KB5014986
WS 2012: KB5014991
WS 2008 R2 SP1: KB5014987
WS 2008 SP2: KB5014990
— Elizabeth Tyler (@MSetyler) May 20, 2022
There is also a numbered knowledge base article KB5015013 which you can consult for more details.
According to KB5015013, the bugs fixed in this out-of-band patch for the patch:
- Only applies to domain controllers. Other servers and end user computers are not affected.
- Only affects authentication for certain Windows services and protocols, to know Network Policy Server (NPS), Routing and Remote Access Service (RRAS), Ray, Extensible Authentication Protocol (EAP), and Protected Extensible Authentication Protocol (PEAP).
Patches that need patches inevitably give our own favorite principle of Patch early, Patch often a bad name…
…but in this case, keep in mind that the original security flaws that were patched were taken into account Critical; that the errant patch did not affect all Windows authentication; that there was a workaround for those who wanted to use it; and that rolling back this fix (while leaving all other Patch Tuesday fixes in place) was apparently another viable temporary fix.
And while it’s easy to look back through rose-tinted glasses and remember a distant past in which security patches hardly ever needed patches, it’s the same distant past where there were hardly any security patches to begin with.
It’s also a distant past where almost any stack buffer overflow discovered in Windows was almost certainly exploitable with almost no effort and with almost immediate effect.
So we’ll say again, as we did when we wrote about the latest VMware patches just a few hours ago: Don’t delay – do it today.