ESC15 (EKUwu)/CVE-2024-49019: Vulnerability in AD CS EKU Certificate Templates

At the end of September 2024, Justin Bollinger, a researcher at TrustedSec, discovered a vulnerability in the Extended/Enhanced Key Usage (EKU) certificate templates within AD CS, and named this attack ESC15 (EKUwu). On October 8, a publicly available PoC was released online. The ESC15 vulnerability allows attackers to escalate privileges to Domain Administrator by abusing default certificate templates, or to request certificates through any identity of arbitrary users (including privileged accounts). Later on November 12, Microsoft designated this vulnerability as CVE-2024-49019.

Features of ESC15 vulnerability:

1. Compared with other ESCx vulnerabilities (ESC1–ESC14), ESC15 is more practical and easier to exploit, particularly when configuring internal HTTPS certificates where misconfigurations often occur. Numerous cases have shown how default certificate templates can unintentionally meet ESC15 exploitation conditions.

2. The Supply EKU in CSR is undocumented by Microsoft, and is often overlooked during certificate template configuration, which triggers ESC15.

AD CS and EKU Introduction

Similar to Internet Information Services (IIS), AD CS is Microsoft’s Public Key Infrastructure (PKI) service which can be optionally installed.

As implied, AD CS is highly integrated with AD aside from its PKI functionality. A common scenario is to bind AD authentication to certificates, enabling domain users or devices to authenticate via certificate requests. Within this framework, the EKU specifies the purpose of a certificate, such as code signing or client authentication.

Technical Analysis

The root cause of this attack is rather unique. When a certificate template’s schema version is set to 1 and the template includes the “Supply in the request” setting, the system allows users to define arbitrary values for msPKI-Certificate-Application-Policy field during the certificate signing request (CSR) stage. In practice, this means that as long as an attacker can register a certificate from a vulnerable template, no further misconfigurations are needed. Attackers can directly escalate privileges to Domain Administrator.

Which EKU is Effective on the Certificate Template?

A certificate template has two attributes related to EKU: pKIExtendedKeyUsage and msPKI-Certificate-Application-Policy. The effective EKU is determined based on the values of these two attributes.

The rules for determining the effective EKU are illustrated in Figure 1.

For schema versions 1/2/3/4, when authentication EKU is not considered, the effective EKU is determined by msPKI-Certificate-Application-Policy.

The authentication EKU only affects schema version 1 with complicated conditions, which will not be elaborated here.

Under normal circumstances, when the certificate template schema version is set to 1, this attribute is typically empty. So under what circumstances would a schema version 1 certificate template have a value in this attribute?

The answer lies in an undocumented feature.

Originally, when a certificate template includes the setting “Supply in the request”, it should only allow the replacement of the SAN field during the certificate request (CSR) stage (Figure 2). However, when the schema version is 1, an additional undocumented capability appears: the CSR can also supply a value for msPKI-Certificate-Application-Policy (Figure 3).

Using the default WebServer certificate template (Figure 3) as an example, its pKIExtendedKeyUsage, the intended purpose of the certificate template, is Server Authentication. Since this template meets the conditions for the undocumented feature, it is possible at the CSR stage to include additional usages in msPKI-Certificate-Application-Policy, such as Client Authentication or Enrollment Agent. According to the effective EKU rules, this results in a certificate originally intended for Server Authentication being able to perform unintended actions such as Client Authentication or Enrollment Agent.

‍

Impact

After disclosing this vulnerability, TrustedSec researcher Justin Bollinger further discovered that certificate templates with schema version 1 cannot be freely modified, unless edited with tools like ADSI Edit. This means that if administrators mistakenly allow low-privileged users to enroll certificates meeting exploitable conditions, those users could abuse them to perform actions such as

code signing, Domain Authentication (ESC1), Enrollment Agent (ESC3), and so forth.

Therefore, we consider ESC15 (EKUwu) a latent ESC2-like threat in the environment. If vulnerable certificate templates are mistakenly assigned to low-privileged users, it could lead to severe domain compromise.

Mitigation

The following certificate templates exist in default environments and include “Supply in the request”. We recommend verifying that only high-privileged users are permitted to enroll them:

• ExchangeUserSignature
• exchangeUser
• CEPEncryption
• OfflineRouter
• IPSECIntermediateOffline
• SubCA
• CA
• WebServer
• EnrollmentAgentOffline

Additionally, we suggest suspending the use of schema version 1 certificate templates. If such templates are inevitable, copy them and ensure the new template version is not 1.

For clients using CyCraft XCockpit Identity, as of October 9, the platform has been updated to detect ESC15 configurations and analyze potential attack paths (Figure 4).

References

• bandrel. (2024) “ESC15.ps1.” Github. (Oct 30, 2024).
• Bollinger, J. (2024) “EKUwu: Not just another AD CS ESC.” Trustedsec. (Oct 9, 2024).
• Knudsen, J. B. (2024) “ADCS Attack Paths in BloodHound — Part 1.” Medium. (Oct 30, 2024).
• ly4k. (2024) “Certipy.” Github. (Oct 8, 2024).

For more details, please refer to CyCraft’s research blog: https://go.cycraft.ai/research-blog