How to gain admin privileges by exploiting CVE-2022-26923
Attackers are exploring different approaches to exploit applications and gain access every day – some more novel than others. Starting with Log4j, followed by Spring4Shell, SSL and many vulnerabilities have been observed in 1st half of 2022. Now there’s another one on the horizon – the chance to gain Domain Admin access using exploiting the Certificate services of Windows Active Directory.
Windows Active Directory (AD) is not something just for providing identity and access management, but provides a significant amount of services to help you run and manage your organization. Many of these services are less commonly known or used, meaning they are often overlooked when security hardening is performed. One of these services is the Active Directory Certificate Services (AD CS).
Talking about certificates, we only think about those used to upgrade website traffic to HTTPS and the like. But these are generally only used for applications that the organization exposes to the internet – what about the internal infrastructure which uses the internet to perform certain tasks or communicate internally? That’s when AD CS comes into the picture.
What is the purpose of AD CS?
AD CS is Microsoft’s Public Key Infrastructure (PKI) implementation. AD CS is used for several things, such as encrypting file systems, creating and verifying digital signatures, and even for user authentication, making it a target for attackers. What makes it an even more dangerous attack vector, is that certificates can survive credential rotation, meaning even if a compromised account’s password is reset, that will do nothing to nullify the maliciously generated certificate, providing persistent credential theft for up to 10 years!
The below diagram shows the workflow of Cert Generation:
Since AD CS is such a privileged function, it only runs on limited domain controllers with specific access levels. Administrators of AD CS can create several templates that can allow any user with the relevant permissions to request a certificate themselves. These templates have parameters that say which user can request the certificate and what is required.
How does this Vulnerability Works?
To understand this, we need to understand 3 parts of the AD CS with which we leverage this vulnerability and gain access.
Client Authentication Templates
Certificate templates are being used in the organization network for many purposes. For CVE-2022-26923 and the template, misconfigurations discovered have their primary focus on the client authentication use case.
Client authentication allows a user who owns the cert to verify their own identity in AD for authentication purposes. For example, a client certificate is used to authenticate sessions. If we have a valid certificate that has the usage to use it as client authentication, we can interact with AD CS and the Key Distribution Centre to request a Kerberos session that can then be used for further authentication.
As an attacker, we can leverage this to generate a false session to impersonate another user or system.
Default Certificate Templates
By default, when AD CS is installed in an environment, two certificate templates are made available for requests that support client authentication:
- User Certificate Template – This certificate template can be requested by any user that belongs to the Domain Users group.
- Machine Certificate Template – This certificate template can be requested by any host that belongs to the Domain Computers group.
The user template is not vulnerable by default. When we request a certificate based on the User template, the User Principal Name (UPNs) of the user account will be embedded in the Subject Alternative Name (SAN)/alias name that can be used for identification.
But by default, UPN and SAN characteristics do not provide the ability to modify and leverage them to use for impersonation. However, computer accounts do not have a UPN.
Instead of using a UPN for authentication, the Machine template uses the DNS Name of the machine for auth. When a certificate is requested for a machine through the Machine template, AD CS embeds the machine’s DNS Name into the SAN, which is then used for authentication.
Default Domain User Privileges
By default, any user who is a member of the Authenticated Users group can enroll up to 10 new machines on the domain. This is often used in organizations to allow users to bring their own device (BYOD) and enroll it for use on the domain. When we enroll a new host in AD, we are assigned as the owner of that host. This provides us with certain permissions over the AD Object associated with that host. Two specific permissions can cause a loophole here:
- Validate write to DNS hostname – This permission allows us to update the DNS hostname of our AD Object associated with the host.
- Validate write to Service Principal Name (SPN) – This permission allows us to update the SPN of our AD Object associated with the host.
SPNs are used by Kerberos authentication to link authenticated services to service accounts. By default, the Computer AD Object receives SPNs associated with their name to allow for Kerberos authentication. SPNs must be unique
Changing the DNS of the hostname will push the changes to modify the SPN which won’t happen due to the unique policy, it will throw the error of impersonation using DNS spoofing. But the permission to change the SPN first can help us to play with the privileges of the object and have the ability also to change the SPN, we can bypass this restriction.
Now we understood these 3 parts, so below are the steps we follow to gain access :
- Compromise the account credentials of a low-privileged AD user.
- Use those credentials to enrol a new host on the domain.
- Alter the DNS hostname value of the Computer AD Object to that of a privileged host, such as a Domain Controller.
- Remove the SPN attributed to the host using the default permission to bypass the unique SPN conflict issue.
- Request a Machine certificate using the default template.
- Perform Kerberos authentication with the received template, now as the privileged machine account instead of our fake machine account.
Keep a close eye on the SecPro in the near future, where we will run a demonstration on how to exploit this vulnerability and learn how you can stop similar issues from occurring in the future.
