CVE-2022-26923 A AD Certificate Services

 

A certificate signing request (CSR) is one of the first steps towards getting your own SSL/TLS certificate. Generated on the same server you plan to install the certificate on, the CSR contains information (e.g. common name, organization, country) the Certificate Authority (CA) will use to create your certificate.



This website explores CVE-2022-26923, a vulnerability in Microsoft's Active Directory Certificate Service (AD CS) that allows any AD user to escalate their privileges to Domain Admin in a single hop!.

A brief look at certificate templates

Windows Active Directory (AD) is not just for identity and access management but provides a significant amount of services to help you run and manage your organisation. 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).

When talking about certificates, we usually only think about the most common ones, such as those used to upgrade website traffic to HTTPS. But these are generally only used for applications that the organisation exposes to the internet. What about all those applications running on the internal network? Do we now have to give them internet access to allow them to request a certificate from a trusted Certificate Authority (CA)? Well, not really. Cue AD CS.

AD CS is Microsoft's Public Key Infrastructure (PKI) implementation. Since AD provides a level of trust in an organisation, it can be used as a CA to prove and delegate trust. AD CS is used for several things, such as encrypting file systems, creating and verifying digital signatures, and even user authentication, making it a promising avenue 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 invalidate the maliciously generated certificate, providing persistent credential theft for up to 10 years! The diagram below shows what the flow for certificate requests and generation looks like.

 

Since AD CS is such a privileged function, it normally runs on selected domain controllers. Meaning normal users can't really interact with the service directly. On the other side, organisations tend to be too large to have an administrator create and distribute each certificate manually. This is where certificate templates come in. 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. What SpecterOps has found, was that specific combinations of these parameters can be incredibly toxic and be abused for privilege escalation and persistent access!



Before we dive deeper into certificate abuse, some terminology:

• PKI - Public Key Infrastructure is a system that manages certificates and public key encryption
• AD CS - Active Directory Certificate Services is Microsoft's PKI implementation which usually runs on domain controllers
• CA - Certificate Authority is a PKI that issues certificates
• Certificate Template - a collection of settings and policies that defines how and when a certificate may be issued by a CA
• CSR - Certificate Signing Request is a message sent to a CA to request a signed certificate
• EKU - Extended/Enhanced Key Usage are object identifiers that define how a generated certificate may be used

1) What does the user create to ask the CA for a certificate?

Ans :- Certificate Signing Request



2) What is the name of Microsoft's PKI implementation?

Ans :- Active Directory Certificate Services

Client Authentication

As discussed in the overview of Certificate Templates, they are convenient to allow users and systems to enrol for certificates. Certificates have many use cases in the network. For CVE-2022-26923 and the template misconfigurations discovered by SpectorOps, the primary focus is on the Client Authentication use case.


Client Authentication allows the owner of the certificate to use it to verify their own identity in AD for authentication purposes. For example, a client certificate is used to authenticate against a web application. The authentication process occurs through Kerberos. If we have a valid certificate that has the Client Authentication EKU, we can interface with AD CS and the Key Distribution Centre to request a Kerberos TGT that can then be used for further authentication.


As an attacker, we can leverage this to generate a TGT to impersonate another user or system, should we have a valid certificate for them. In essence, we want to be able to modify the Subject Alternative Name (SAN) attribute of the certificate request to point to someone or something else, that has more permissions to perform privilege escalation.

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 SAN that can be used for identification. Since UPNs must be unique, and we usually do not have the ability to modify our UPN, we cannot leverage this template. Furthermore, since we don't have the ability to alter the SAN value in the certificate signing request, we cannot impersonate another user by specifying their UPN.


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 identification and authentication. 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 (literally all AD accounts) can enrol up to 10 new machines on the domain. This is often used in organisations to allow users to bring their own device (BYOD) and enrol it for use on the domain. This in itself is not really a vulnerability but has led to some interesting privilege escalation vectors in the path, exactly what we will be exploiting for this CVE.


When we enrol 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 permissions in particular cause an issue 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 associate a service instance with a service logon account. By default, the Computer AD Object receives SPNs associated with their name to allow for Kerberos authentication, which the host requires to perform specific requests against AD. SPNs must be unique, meaning two AD Objects are not allowed to have the same SPN.


You would think it would be as simple as changing the DNS hostname to another hostname, maybe the hostname of a Domain Controller for privilege escalation? However, if you change the DNS hostname, Microsoft automatically updates the SPN attribute. Since those must be unique, we will get an error if we try to impersonate another host through the DNS hostname attribute. But since we have the ability also to change the SPN, we can bypass this restriction.


The pieces of the puzzle should now start to come together. If we only had one of the two permissions, we would not have a vulnerability.  However, the combination of having those two permissions allows us to perform privilege escalation.

Putting it all Together

Using these configurations, the default AD CS Machine certificate template, the default ability to enrol a new machine, and the default permissions assigned on the created Computer AD Object, we have a privilege escalation vector on our hands. What makes it worse is that this privilege escalation vector requires minimal effort, meaning the attacker's skill level to exploit this issue is quite low. The basic steps are the following:

1. Compromise the credentials of a low-privileged AD user.
2. Use those credentials to enrol a new host on the domain.
3. Alter the DNS hostname attribute of the Computer AD Object to that of a privileged host, such as a Domain Controller.
4. Remove the SPN attributed to bypass the unique SPN conflict issue.
5. Request a Machine certificate using the default template.
6. Perform Kerberos authentication with the received template, now as the privileged machine account instead of our fake machine account.

   
   



1) Which EKU allows us to use the generated certificate for Kerberos authentication?

Ans :- Client Authentication



2) What AD group can request a certificate using the Machine Certificate Template?

Ans :- Domain Controller



3) What value in the Machine Certificate is used for identification and authentication?

Ans :- DNS Hostname

To Be Continue....Exploitation soon

Disclaimer

 

All tutorials are for informational and educational purposes only and have been made using our own routers, servers, websites and other vulnerable free resources. we do not contain any illegal activity. We believe that ethical hacking, information security and cyber security should be familiar subjects to anyone using digital information and computers. Hacking Truth is against misuse of the information and we strongly suggest against it. Please regard the word hacking as ethical hacking or penetration testing every time this word is used. We do not promote, encourage, support or excite any illegal activity or hacking.