ESC15/EKUwu PR

[dru1d-foofus]

Initial PR of ESC15 attack discovered and disclosed by Justin Bollinger from TrustedSec (https://x.com/Bandrel)

Edit: Here are some additional details about the attack.

As other people have noted, this is essentially ESC1 without the need to have a "Client Authentication" EKU. I didn't RE all of the binaries/libraries associated with Windows ADCS (I tried, but it's a lot) - so I don't have a clear picture on all of the internals that lead to this specific edge case. I am able to surmise that this is possible for a few different reasons:

1. Schema Version 1 templates do not contain a populated msPKI-Certificate-Application-Policy (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-crtd/44012f2d-5ef3-440d-a61b-b30d3d978130) attribute whereas templates with version 2+ have it populated automatically. If you delete that attribute on a version 2+ template, you'll actually find it vulnerable to multiple ESC bug classes.
2. Only templates where enrollee supplies SAN are vulnerable (in my testing). It appears that you can only supply the application policies extension on a request where you are already providing a SAN. While trying to supply EKU on certificate templates that do not support enrollee supplied SAN, the supplied application policy extension does not stay populated on the requested certificate.
3. These requested certificates do not support PKINIT out of the box. However, you can essentially conduct an ESC3-style attack by just supplying the Certificate Enrollment Agent EKU via ESC15 and request a User certificate template to address that hurdle.

This is not something that is vulnerable default, like many other ADCS vulnerabilities. You have to go out of your way to create a vulnerable condition. Microsoft's own documentation does not recommend ever configuring a certificate in this way and they actually would advise against it. However, other vendors/third-parties are not as scrupulous. Here are a few interesting examples I found during my research into this vulnerability:

• https://www.firewall.cx/operating-systems/microsoft/windows-servers/how-to-enaable-webserver-certificate-template.html
• https://bgelens.nl/integrating-vm-role-with-desired-state-configuration-part-2-pki/
• https://deskalertssupport.zendesk.com/hc/en-us/articles/19299662937107-How-to-create-an-SSL-certificate-using-Active-Directory-Certificate-Services

I've had over a month working with this fork and during the testing of several client organization, found instances where a vulnerable certificate template was available - typically the WebServer template and I believe it because of the proliferation of bad third-party vendor documentation.

Honorable mentions: TrustedSec released their internal BOF that also exploits this vulnerability. You can snag it from https://github.com/trustedsec/CS-Remote-OPs-BOF

[daddycocoaman]

Crazy that you snitched. 😭

[dru1d-foofus]

Crazy that you snitched. 😭

Hello, @daddycocoaman/Ohm-I!

I have published my fork of Certipy for several reasons:

1. Details about the attack have already been publicized.
2. Other people have already figured out how to replicate it.
3. Due to the overwhelming amount of bad vendor documentation encouraging people to misconfigure templates, a way to test and validate this vulnerability needed to be brought to light.

I wrote this code based on information that was made public over a month ago and have provided credit to the original researcher who discovered it. It's still their work and I'm not taking that away from them. However, this is my work and I have a right to publish it.

Thanks!

[daddycocoaman]

Crazy that you snitched. 😭

Hello, @daddycocoaman/Ohm-I!

I have published my fork of Certipy for several reasons:

1. Details about the attack have already been publicized.
2. Other people have already figured out how to replicate it.
3. Due to the overwhelming amount of bad vendor documentation encouraging people to misconfigure templates, a way to test and validate this vulnerability needed to be brought to light.

I wrote this code based on information that was made public over a month ago and have provided credit to the original researcher who discovered it. It's still their work and I'm not taking that away from them. However, this is my work and I have a right to publish it.

Thanks!

You do you. Many of us have implementations but I just hope that you discussed the impact on the researcher and their company before dropping this specifically for public consumption because some things go beyond technical implications.

PR looks great though!

[linuxkd]

First off, this is awesome. Wanted to point out though that the PR has some comments removed that are links to the official documentation related to the functionality, specifically in req.py. Probably worth sticking those back in.

[dru1d-foofus]

First off, this is awesome. Wanted to point out though that the PR has some comments removed that are links to the official documentation related to the functionality, specifically in req.py. Probably worth sticking those back in.

@linuxkd - I have added those comments back. That was a Copilot thing as I was trying to ensure my additions were in the style of the original project.

[network-node]

Justin Bollinger (https://github.com/Bandrel) is smart as hell. Not shocked he figured it out. Credit to him for finding this <3

[spyr0-sec]

After playing around with this, I've noticed there are currently false positives in regards to the identification of ESC15 templates as there is no check against the msPKI-Certificate-Application-Policy attribute values.

In this example I have a template which is reporting as vulnerable:

However, when requesting a certificate, authentication does not work as the application policy overrides any additional polices:

This is confirmed in the issued certificate:

Removing the application policies from the certificate results in obtaining a certificate with the requested client authentication policy

Get-ADObject "CN=ESC15,CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Properties * | Set-ADObject -Clear 'msPKI-Certificate-Application-Policy', 'pKIExtendedKeyUsage'

[daddycocoaman]

@spyr0-sec It's known that requesting the cert with Client Authentication can't be used for PKINIT client auth (it works for SChannel, so you can use that original cert with certipy auth -ldap-shell), so that's not a false positive.

However, you might have just solved the PKINIT issue by removing the pKIExtendedKeyUsage and policies all together.

[spyr0-sec]

Thats what I get for jumping in with two feet before getting to the end of the blog post!

I've just tried -ldap-shell and I get an error 😕

LDAPS is definitely configured in the lab and this is with a certificate where it just has EFS application policies

I've tried with all the different options available. Will have to come back to it tomorrow

[daddycocoaman]

@spyr0-sec Just to clarify, you still need the cert to have Client Auth app policy (from your second screenshot). It cannot be used for PKINIT but it can be used with -ldap-shell.

[evilmog]

You can also request a certificate enrollment agent certificate and then direct request a certificate on behalf of any other user which can pkinit