From eb2c2b5610f93a198a9453e71b767e26566c7d65 Mon Sep 17 00:00:00 2001 From: CPol Date: Thu, 1 Sep 2022 19:44:54 +0000 Subject: [PATCH] GitBook: [#3439] No subject --- .../ad-certificates/domain-escalation.md | 127 ++++++++++++++++++ 1 file changed, 127 insertions(+) diff --git a/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md b/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md index f39cc9e4..8a729dab 100644 --- a/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md +++ b/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md @@ -61,6 +61,133 @@ Moreover, the following LDAP query when run against the AD Forest’s configurat ## Misconfigured Certificate Templates - ESC2 +The second abuse scenario is a variation of the first one: + +1. The Enterprise CA grants low-privileged users enrollment rights. +2. Manager approval is disabled. +3. No authorized signatures are required. +4. An overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users. +5. **The certificate template defines the Any Purpose EKU or no EKU.** + +The **Any Purpose EKU** allows an attacker to get a **certificate** for **any purpose** like client authentication, server authentication, code signing, etc. + +A **certificate with no EKUs** — a subordinate CA certificate —  can be abused for **any purpose** as well but could **also use it to sign new certificates**. As such, using a subordinate CA certificate, an attacker could **specify arbitrary EKUs or fields in the new certificates.** + +However, if the **subordinate CA is not trusted** by the **`NTAuthCertificates`** object (which it won’t be by default), the attacker **cannot create new certificates** that will work for **domain authentication**. Still, the attacker can create **new certificates with any EKU** and arbitrary certificate values, of which there’s **plenty** the attacker could potentially **abuse** (e.g., code signing, server authentication, etc.) and might have large implications for other applications in the network like SAML, AD FS, or IPSec. + +The following LDAP query when run against the AD Forest’s configuration schema can be used to enumerate templates matching this scenario: + +``` +(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))) +``` + +## Misconfigured Enrolment Agent Templates - ESC3 + +This scenario is like the first and second one but **abusing** a **different EKU** (Certificate Request Agent) and **2 different templates** (therefore it has 2 sets of requirements), + +The **Certificate Request Agent EKU** (OID 1.3.6.1.4.1.311.20.2.1), known as **Enrollment Agent** in Microsoft documentation, allows a principal to **enroll** for a **certificate** on **behalf of another user**. + +The **“enrollment agent”** enrolls in such a **template** and uses the resulting **certificate to co-sign a CSR on behalf of the other user**. It then **sends** the **co-signed CSR** to the CA, enrolling in a **template** that **permits “enroll on behalf of”**, and the CA responds with a **certificate belong to the “other” user**. + +**Requirements 1:** + +1. The Enterprise CA allows low-privileged users enrollment rights. +2. Manager approval is disabled. +3. No authorized signatures are required. +4. An overly permissive certificate template security descriptor allows certificate enrollment rights to low-privileged users. +5. The **certificate template defines the Certificate Request Agent EKU**. The Certificate Request Agent OID (1.3.6.1.4.1.311.20.2.1) allows for requesting other certificate templates on behalf of other principals. + +**Requirements 2:** + +1. The Enterprise CA allows low-privileged users enrollment rights. +2. Manager approval is disabled. +3. **The template schema version 1 or is greater than 2 and specifies an Application Policy Issuance Requirement requiring the Certificate Request Agent EKU.** +4. The certificate template defines an EKU that allows for domain authentication. +5. Enrollment agent restrictions are not implemented on the CA. + +You can use [**Certify**](https://github.com/GhostPack/Certify) to abuse this scenario: + +```bash +# Request an enrollment agent certificate +Certify.exe request /ca:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:Vuln-EnrollmentAgent + +# Enrollment agent certificate to issue a certificate request on behalf of +# another user to a template that allow for domain authentication +Certify.exe request /ca:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:User /onbehalfof:CORP\itadmin /enrollment:enrollmentcert.pfx /enrollcertpwd:asdf + +# Use Rubeus with the certificate to authenticate as the other user +Certify.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf +``` + +Enterprise CAs can **constrain** the **users** who can **obtain** an **enrollment agent certificate**, the templates enrollment **agents can enroll in**, and which **accounts** the enrollment agent can **act on behalf of** by opening `certsrc.msc` `snap-in -> right clicking on the CA -> clicking Properties -> navigating` to the “Enrollment Agents” tab. + +However, the **default** CA setting is “**Do not restrict enrollment agents”.** Even when administrators enable “Restrict enrollment agents”, the default setting is extremely permissive, allowing Everyone access enroll in all templates as anyone. + +## Vulnerable Certificate Template Access Control - ESC4 + +**Certificate templates** have a **security descriptor** that specifies which AD **principals** have specific **permissions over the template**. + +If an **attacker** has enough **permissions** to **modify** a **template** and **create** any of the exploitable **misconfigurations** from the **previous sections**, he will be able to exploit it and **escalate privileges**. + +Interesting rights over certificate templates: + +* **Owner:** Implicit full control of the object, can edit any properties. +* **FullControl:** Full control of the object, can edit any properties. +* **WriteOwner:** Can modify the owner to an attacker-controlled principal. +* **WriteDacl**: Can modify access control to grant an attacker FullControl. +* **WriteProperty:** Can edit any properties + +## Vulnerable PKI Object Access Control - ESC5 + +The web of interconnected ACL based relationships that can affect the security of AD CS is extensive. Several **objects outside of certificate** templates and the certificate authority itself can have a **security impact on the entire AD CS system**. These possibilities include (but are not limited to): + +* The **CA server’s AD computer object** (i.e., compromise through S4U2Self or S4U2Proxy) +* 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=,DC=` (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**. + +## EDITF\_ATTRIBUTESUBJECTALTNAME2 - ESC6 + +There is another similar issue, described in the [**CQure Academy post**](https://cqureacademy.com/blog/enhanced-key-usage), which involves the **`EDITF_ATTRIBUTESUBJECTALTNAME2`** flag. As Microsoft describes, “**If** this flag is **set** on the CA, **any request** (including when the subject is built from Active Directory®) can have **user defined values** in the **subject alternative name**.”\ +This means that an **attacker** can enroll in **ANY template** configured for domain **authentication** that also **allows unprivileged** users to enroll (e.g., the default User template) and **obtain a certificate** that allows us to **authenticate** as a domain admin (or **any other active user/machine**). + +**Note**: the **alternative names** here are **included** in a CSR via the `-attrib "SAN:"` argument to `certreq.exe` (i.e., “Name Value Pairs”). This is **different** than the method for **abusing SANs** in ESC1 as it **stores account information in a certificate attribute vs a certificate extension**. + +Organizations can **check if the setting is enabled** using the following `certutil.exe` command: + +```bash +certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags" +``` + +Underneath, this just uses **remote** **registry**, so the following command may work as well: + +``` +reg.exe query \\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags +``` + +****[**Certify**](https://github.com/GhostPack/Certify) also checks for this and can be used to abuse this misconfiguration: + +```bash +# Check for vulns, including this one +Certify.exe find + +# Abuse vuln +Certify.exe request /ca:dc.theshire.local\theshire-DC-CA /template:User /altname:localadmin +``` + +These settings can be **set**, assuming **domain administrative** (or equivalent) rights, from any system: + +```bash +certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 +``` + +If you find this setting in your environment, you can **remove this flag** with: + +```bash +certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 +``` +
Support HackTricks and get benefits!