Mitigate Authentication Mechanism Assurance (AMA) abuse
In the last blog post series – When your Enterprise PKI becomes one of your enemies (Part 4) we vent trough how Authentication Mechanism Assurance (AMA) works and how it can be abused together with Public Key Infrastructure (PKI) to compromise an Active Directory forest if it’s not designed the right way.
One of the core issues here is that has been demonstrated in the previous blog article(s) is that AMA abuse can be performed by obtaining a certificate from a certificate authority that is trusted by the KDC (but not necessarily being trusted in NTAuth) – to summary the requirements again.
- Obtain a certificate from a certificate authority (CA) that is trusted on the KDC and being able to supply the AMA Issuance Policy OID – this can be archived by:
- Certificate Template configured for ‘Supply in the request’ – SITR
- Being able to write to at least one user account’s altSecId (altSecurityIdentities) attribute.
- Using key-trust and obtain a certificate from a certificate authority (CA) that is trusted in NTAuth and being able to supply the AMA Issuance Policy OID – this can be archived by:
- Certificate Template configured for ‘Supply in the request’ – SITR
- Being local administrator or being able to become SYSTEM on any domain member within the forest e.g. a regular client is enough.
Note the privilege escalation using AMA abuse depends on the privilege that is linked to the ‘AMA Issuance Policy OID’
So how can we mitigate those?
Mitigation 1: Un-trust ”Issuing CA 2″ on all Domain Controllers / Key Distribution Centers
Let’s think a bit about the first scenario, (1.) – here it’s not even required that the certificate authority is trusted within NTAuth, it’s only enough that the CA is trusted on the KDCs. So even with our two Enterprise CA design where on of them (CA2 is NOT trusted in NTAuth) – where not going to be protected as ‘Issuing CA 2’ is still an Enterprise CA and is going to be be rolled out to all domain members to the ‘intermediate certificate authorities’ store including on domain controllers / kdc’s.
One way to block this could be to to specifically “Un-trust” the certificate authority (CA) on the domain controllers / kdc’s. This can be accomplished by adding the ‘Issuing CA 2’ CA certificate to the “Untrusted Certificates” store on all domain controllers / kdc’s.
Note: This can be done using a Group Policy of course but it needs to be updated every time the CA certificate on ‘Issuing CA 2’ is renewed.
The real downside with this is the manual maintenance of blocking ‘Issuing CA2’ as new certificates will be issued over time.
Let’s try another approach
Mitigation 2 – Require an Issuance Policy
One way to mitigate the AMA abuse would be to ensure that no one can supply an issuance policy at all in certificates issued by ‘Issuing CA2’ or any other certificate authority within the forest that is being trusted on domain controllers / kdc’s – that might be certificate authorities that host supply in the request (SITR) templates but is not limited to, It can also be standalone or 3rd party CAs.
By including your own Issuance Policy OID (Let’s call it ‘Low TLS Low Assurance Policy’) into ‘Issuing CA 2’s CA certificate and omitting the “2.5.29.32.0” – All Issuance Policy, It becomes an enforcement that all leaf certificates issued by the CA also needs to include your own Issuance Policy. Since all leaf certificate needs to contain your own Issuance Policy OID it would by design be impossible to include the policy OID used by AMA, hence blocking any AMA abuse.
So how is this implemented in the reality, well it depends on the type of certificate auhtority but for Active Directory Certificate Services (AD CS) – this would go into your capolicy.inf.
[Version]
Signature= "$Windows NT$"
[BasicConstraintsExtension]
Pathlength = 0
Critical = true
[PolicyStatementExtension]
Policies = EnterpriseCA02Oid,LowIssuancePolicy
Critical = 0
[EnterpriseCA02Oid]
Notice = "Chrisse Issuing CA 2"
OID = 1.3.6.1.4.1.51467.2.1.2.1.3
[LowIssuancePolicy]
Notice = "Chrisse TLS Low Assurance Policy"
OID = 1.3.6.1.4.1.51467.2.1.2.3.1
[Certsrv_Server]
RenewalKeyLength = 4096
RenewalValidityPeriodUnits = 6
RenewalValidityPeriod = years
CRLPeriod = days
CRLPeriodUnits = 3
CRLDeltaPeriod = days
CRLDeltaPeriodUnits = 0
ClockSkewMinutes = 20
LoadDefaultTemplates = 0
AlternateSignatureAlgorithm = 0Now to the downside of this mitigation approach – how do you ensure that the ‘TLS Low Assurance Policy’ is included in every leaf certificate, because if you don’t the issuance will fail. If you have an Active Directory Certificate Service (AD CS) – Enterprise CA as in this case ‘Issuing CA 2’ is, it’s just not member of NTAuth, you can simply include this certificate policy in all templates that is being published on the ‘Issuing CA 2’, this also safeguards from someone mistakenly publishing a certificate template that do not belong their because if that template is missing the ‘TLS Low Assurance Policy’ it would again fail enrollment of any certificate using that template.
But what about 3rd party CAs or Active Directory Certificate Services (AD CS) installed as a standalone certificate authority, well then it must be included in the request (CSR).
This can be done fairly simple with openssl:
openssl req -new -subj "/CN=RHEL9" -addext "subjectAltName = DNS:RHEL9, DNS:RHEL9.eur.corp.chrisse.com" -addext "certificatePolicies = 1.3.6.1.4.1.51467.2.1.2.3.1" -newkey rsa:2048 -keyout key.pem -out req.pem -nodesIt’s a bit more complicated using native PowerShell, but relatively easy using Carl Sörqvist’s module.
Import-Module -Name CertRequestTools
$CA2 = "nttest-ca-02.nttest.chrisse.com\Chrisse Issuing CA 2"
$IssuancePolicyExtension = New-CertificatePoliciesExtension -Oid "1.3.6.1.4.1.51467.2.1.2.3.1"
New-PrivateKey -RsaKeySize 2048 -KeyName ([Guid]::NewGuid()) `
| New-CertificateRequest `
-Subject "CN=DEMO3" `
-UserPrincipalName "caso@nttest.chrisse.com" `
-OtherExtension $IssuancePolicyExtension `
| Submit-CertificateRequest `
-ConfigString $CA2 `
| Install-Certificate -Name My -Location CurrentUserSo an Enterprise CA can never be managed outside of T0
Why? Let’s have a look at this scenario – assume that ‘Issuing CA 2’ would not be managed from Tier 0 for a while:
In that scenario a Tier 1 administrator could logon to ‘Issuing CA 2’ become SYSTEM and acting as the machines security context, Enterprise CAs are automatically added to the ‘Cert Publishers’ Group and that group is always given ‘Full Control’ to a Enterprise CAs ‘certificationAuthority’ object within ‘CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=nttest,DC=chrisse,DC=com’
This is unfortunately hardcoded into the installation of an Enterprise CA – But now to the interesting part what can you do if you’re member of ‘Cert Publishers’? Stay tuned for the next part in this blog series “When your Enterprise PKI becomes one of your enemies (Part 6)”