This article provides analysis of CVE-2022–26923, a vulnerability at the intersection of Active Directory (AD) and Active Directory Certificate Services (AD CS) that was discovered and reported privately through Zero Day Initiative by Oliver Lyak and patched on May 10, 2022, which allowed for a low-privileged attacker to escalate their privileges through impersonation of another computer account under the guise of a requested authentication certificate.
As the go-to directory service from Microsoft for Windows domain networks, Active Directory (AD), or more formally Active Directory Domain Services (AD DS), is a prime target for attackers who want to obtain access to resources on a network.
In a nutshell, AD functions as both a distributed data store and an access control mechanism for organizations using it, including within its scope not just users and groups but other objects like servers, printers, and computers within the network - i.e., networked resources to which access needs to be controlled. Offering quite a simple hierarchical organization, AD makes it easy for domain administrators (often a centralized Identity and Access Management team within the organization) to control access to resources; it also enables authorized network users to navigate and query for information about other users and networked resources in their organization.
The Challenge
Let's start with an assumption: you're a user on the network with normal, non-administrative permissions - or perhaps you're not, but you have obtained the identity of someone who is.
How can you use Active Directory, as described above, to (perhaps further) escalate your privileges and obtain access to a resource on the network to which you currently do not have access?
First, privilege escalation would be a bit difficult without visibility of whose privilege level should be targeted. Of course, as mentioned previously, AD does offer the ability for an authorized domain user to simply query the data for information they're interested in like usernames, email addresses, group memberships, etc., which is one way that visibility could be obtained. However, we've seen that with a tool like Bloodhound, that same domain user (or someone impersonating them on the network) could automatically obtain a graphical visualization (built with a fantastic graph data platform called Neo4j) not only depicting who the domain administrators are within AD, but also what the shortest path of privilege escalation is to each of those administrators - all essentially at the click of a button.
Basically, any domain user can obtain this information about their domain by logging into AD, running SharpHound to collect the data from it in JSON format, and then piping that collected data right into the Neo4j-based Bloodhound visualizer. From that point, it's a matter of following the yellow brick road - that is, mapping a route to a target with desired privileges by following the graph edges that reveal useful vulnerabilities. Graph theory, permissions, memberships, oh my.
As an example, you may want to access a domain admin's account, and you notice in the Bloodhound graph that a non-admin has permission within AD to force change one or all of the domain admins' passwords, so you identify that non-admin as the next target for impersonation.
Now, assume that you have identified a target for impersonation-based escalation of privileges. Assuming that target is a computer or server account (not a user account), CVE-2022–26923 was a vulnerability that offered a method of carrying out that impersonation.
A Pause for Some Context
Introduced in Windows Server® 2008, Active Directory Certificate Services (AD CS) is another AD Server Role leveraging public key infrastructure (PKI) to provide domain users with the ability to create digital certificates. Such digital certificates could be used for general encryption to protect data confidentiality, for the generation of digital signatures to protect message integrity during transmission, or even for authentication against AD, which is the focal use case for the purpose of this analysis since successful privilege escalation via impersonation is all about false positives when authenticating.
With public key infrastructure, on which AD CS is built, one of the overarching ideas is that with any public-private key pair, the private key is kept truly private by the owner and thus can be used to identify and authenticate that owner (which has additional non-repudiation implications). If that owner signs (encrypts) something with their private key, the only way it can be decrypted is with the corresponding public key; more importantly, any message decrypted with a public key can only have come from the owner with the corresponding private key. This theory underlying PKI opens the door to digital certificate-based authentication.
By associating, or binding, the digital certificates with accounts on a network in AD (whether computer accounts, user accounts, or device accounts), AD CS allows for those accounts to authenticate against AD using their respective digital certificates. Certificate-based authentication is itself an interesting process relying on password entry in addition to digital signature verification, but this paper will avoid diving into that rabbit hole. Note that this process of binding a digital certificate to an identity for the purpose of it being used to authenticate them should be done in a way that other identities cannot forge that binding. This was the problem behind CVE-2022–26923 - AD CS allowed digital certs to be bound to identities via an attribute (dNSHostName) that could be reused arbitrarily for other identities.
Using CVE-2022–26923 to Escalate Privileges
As documented by the Semperis Research Team in August of 2022, there were ultimately two main steps that needed to be completed in order to exploit the CVE-2022–26923 privilege escalation vulnerability. First, the attacker needed to change the dNSHostName of their own computer account to match the target computer or server account's dNSHostName value (e.g., that of a domain controller computer account). Then, the attacker needed to obtain a digital certificate bound to their own falsely identified computer account by requesting one with a template configured with the SubjectAltRequireDns flag. This flag essentially sets the Subject of the digital certificate to the dNSHostName value of the requesting computer account (without any sort of validation), where the Subject ultimately identifies the computer account bound to the public key. Note that for the first step, there was actually a prerequisite of the attacker creating their own computer account as a logged in user in AD (a feature enabled by default in AD), since dNSHostName attributes can be modified only on computer accounts created by the editor.
The presence of this vulnerability meant that an attacker with access to AD could pick and choose from active AD computer accounts and use a default, built-in component of AD to arbitrarily impersonate any desired target via false digital certificate authentication.
Mitigation
The easiest, most sledgehammery (looky there, I coined a term) fix for this problem would probably be to simply not run AD CS within a Windows domain network, as AD CS is the root of the CVE-2022–26923 rot. This would entirely prevent digital certificate-based authentication, but of course flipping such a broad switch has equivalently broad implications at the enterprise scale which may include, for example, service outages for services running on machines that use certificate-based authentication against AD for valid purposes.
Luckily, Microsoft made an announcement pretty quickly in response to the vulnerability disclosure about a new change to the way certificate-based authentication would be handled by Windows domain controllers. The announcement included explicit actions that needed to be taken to protect domain environments, namely the application of the May 10, 2022 update which placed AD devices into compatibility mode designed primarily to generate audits ahead of a recommended switch to full enforcement mode which, in short, would begin blocking certain authentication attempts not meeting updated digital certificate criteria.
Those criteria were centered on the idea of certificate mappings, or the bindings mentioned previously, where a mapping between a digital certificate and an account is considered weak, or insecure, if it relies on an identifier that can be reused by other accounts (i.e., the dNSHostName attribute). Certificates weakly mapped to identities would consequently generate audit events in compatibility mode for investigation and fixing, and would entirely fail to authenticate those identities upon the enabling of the update's full enforcement mode.
Conclusion
In short, CVE-2022–26923 was a significant vulnerability within the Active Directory Certificate Services server role that allowed attackers to leverage weak bindings between identities and their digital certificates such that one could completely bypass the security of public-key infrastructure by simply requesting (and obtaining) a digital certificate identifying them in AD as their desired target. Upon its discovery and disclosure on May 10, 2022, it was quickly addressed by an update to the AD CS server role which requires stronger, non-forgeable bindings between digital certificates and AD identities.
Top comments (0)