Access controls
Last updated
Was this helpful?
Last updated
Was this helpful?
In , and found multiple vectors of domain escalation based on access control misconfigurations (dubbed , and ).
Active Directory Certificate Services add multiple objects to AD, including securable ones which principals can have permissions over. This includes:
Certificate templates (ESC4): powerful rights over these objects can allow attackers to "push a misconfiguration to a template that is not otherwise vulnerable (e.g., by enabling the mspki-certificate-name-flag flag for a template that allows for domain authentication) this results in the same domain compromise scenario [...]" () as the one based on misconfigured certificate templates where low-privs users can specify an arbitrary SAN (subjectAltName) and authenticate as anyone else.
The Certificate Authority (ESC7): "The two main rights here are the ManageCA right and the ManageCertificates right, which translate to the “CA administrator” and “Certificate Manager” (sometimes known as a CA officer) respectively. known as Officer rights)" ().
Attack path 1: if an attacker gains control over a principal that has the ManageCA right over the CA, or local admin right, he can remotely flip the EDITF_ATTRIBUTESUBJECTALTNAME2 bit to allow SAN specification in any template (c.f. ). This only works if the attacker is able to restart the CertSvc service on the CA server.
Attack path 2: alternatively (or if the attacker can't restart the CertSrv), if an attacker gains control over a principal that has the ManageCA right over the CA object, he can remotely gain the ManageCertificates right, approve pending certificate requests, subverting the "CA certificate manager approval" protection (referred to as PREVENT4 in ).
Several other objects (ESC5): abuse standard over regulard AD objects.
The CA server’s AD computer object (i.e., compromise through , , , ...).
The CA server’s RPC/DCOM server
Any descendant AD object or container in the container CN=Public Key Services,CN=Services,CN=Configuration,DC=DOMAIN,DC=LOCAL (e.g., the Certificate Templates container, Certification Authorities container, the NTAuthCertificates object, the Enrollment Services Container, etc.) If a low-privileged attacker can gain control over any of these, the attack can likely compromise the PKI system.
...
In order to obtain an abusable template, some attributes and parameters need to be properly setup
Get Enrollment rights for the vulnerable template
Disable PEND_ALL_REQUESTS flag in mspki-enrollment-flag for disabling Manager Approval
Set mspki-ra-signature attribute to 0 to disable Authorized Signature requirement
Enable ENROLLEE_SUPPLIES_SUBJECT flag in mspki-certificate-name-flag to allow requesting users to specify another privileged account name as a SAN
Set mspki-certificate-application-policy to a certificate purpose for authentication
Client Authentication (OID: 1.3.6.1.5.5.7.3.2)
Smart Card Logon (OID: 1.3.6.1.4.1.311.20.2.2)
PKINIT Client Authentication (OID: 1.3.6.1.5.2.3.4)
Any Purpose (OID: 2.5.29.37.0)
No EKU
If sensitive access entries are identified, creativity will be the best ally.
Currently, the best resources for manually abusing this are
There are two attacks paths for this scenario:
If an attacker gains control over a principal that's able to edit the CA server registries (e.g. local admin, or ManageCA?), and is able to restart the CertSrv service on the server, he can make the CA vulnerable to ESC6 and exploit that
The attack can be carried out from UNIX-like systems as follows.
SubCAWhen it is not possible to restart the CertSvc service to enable the EDITF_ATTRIBUTESUBJECTALTNAME2 attribute, the SubCA built-in template can be used, along with a ManageCA right.
The SubCA template is vulnerable to the ESC1 attack, but only Domain Admins and Enterprise Admins can enroll in it. If a standard user tries to enroll in it, he will encounter a CERTSRV_E_TEMPLATE_DENIED errror and will obtain a request ID with a corresponding private key.
This ID can be used by a user with the ManageCA and ManageCertificates rights to validate the failed request anyway. The user can then retrieve the issued certificate by specifying the same ID.
In order to abuse the SubCA template with ESC7, both ManageCA and ManageCertificates are needed in order to issue a certificate from a failed request.
If sensitive rights are identified, creativity will be the best ally. Not much public tooling is available at the time of writing (October 21st, 2021).
Currently, the best resources for manually abusing this are
This can be enumerated and abused like regular AD access control abuses. Once control over an AD-CS-related is gained, creativity will be the attacker's best ally.
Request a certificate (with a high-privileged user's name set as SAN) for authentication and perform .
From UNIX-like systems, (Python) can be used to enumerate these sensitive access control entries, and to overwrite the template in order to add the SAN attribute and make it vulnerable to ESC1. It also had the capacity to save the old configuration in order to restore it after the attack.
If a more precise template modification is needed, (Python) can be used to modify each attributes of the template.
From Windows systems, the (C#) tool can be used to enumerate these sensitive access control entries. At the time of writing (October 21st, 2021) doesn't support (yet) enumeration of these access controls. can be used to modify the template.
Alternatively, if an attacker gains control over a principal that has the ManageCA right over the CA object, he can remotely obtain the ManageCertificates right and with those two rights combined, approve pending certificate requests, subverting the "CA certificate manager approval" protection (referred to as PREVENT4 in ).
If sufficient rights are obtained over the Certificate Authority (ManageCA?, local admin account, ...) an attacker could remotely edit the registries, enable the EDITF_ATTRIBUTESUBJECTALTNAME2 attribute, restart the CertSvc service, and abuse .
From Windows systems, the (C#) tool can be used to enumerate info about the CAs, including access rights over the CA object.
Then, (PowerShell) can be used to modify the CA object ( is needed on the machine where PSPKI is run).
If the attacker only has the ManageCA permission, (Python) can be used to enumerate access rights over the CA object and modify some CA's attributes like the officers list (an officer is a user with the ManageCertificates right). The attacker could also enable or disable certificate templates.
The certificate can then be used with to obtain a TGT and authenticate.
From Windows systems, the (C#) tool can be used to enumerate info about the CAs, including access rights over the CA object, and to request a certificate that requires manager approval.
Then, (PowerShell) can be used to approve a certificate request ( is needed on the machine where PSPKI is used). PSPKI is a PowerShell module used to "simplify various PKI and AD CS management tasks".
(PDF)
