New ESC15 vulnerability discovered in Active Directory Certificate Services - easy-to-implement countermeasures

The purposes for which a digital certificate may be used are controlled via the "Key Usage" and "Extended Key Usage" certificate extensions. In the "Extended Key Usage" certificate extension, the extended key uses for which the certificate may be used.

However, there is another certificate extension called "Application Policies" for certificates issued by a Microsoft Certification Authority, which also contains a list very similar to the Extended Key Usages extension.

Justin Bollinger from TrustedSec has found outthat there are offline certificate requests against Schema version 1 certificate templates is possible (similar to the Security identifier extension), any Application Policies in the certificate request, which are transferred unchanged to the issued certificate and can then be used for an attack on the overall Active Directory structure. The attack was christened ESC15.

How does the attack work?

The attack works by an attacker exploiting one of the standard version 1 certificate templates, provided it is published on a certificate authority.

In most cases, this will be the "Webserver" template, as this allows authorized applicants to supply the identity of the issued certificate in the certificate request ("Supply in the Request" option).

Certificates issued would not be suitable for increasing rights, however, as they would only Extended Key Usage (EKU) contain "Server Authentication", i.e. they can only represent one server identity.

Here comes the Application Policies certificate extension comes into play. This is a Microsoft-proprietary certificate extension from the times of Windows (Server) 2000. It is very similar in content to the "Extended Key Usage" extension, and according to Microsoft it was also intended for comparable functions.

Application policy is Microsoft specific and is treated much like Extended Key Usage.

The attacker can add a corresponding "Application Policies" extension to his certificate application, which includes "Client Authentication", for example.

The issued certificate will then adopt this extension 1:1.

It will be even more exciting to see how applications behave now.

As Justin Bollinger has found out, such certificates are perfectly suitable for logging into the Active Directory. An increase in rights up to Enterprise Administrator is therefore possible with such a certificate.

Other Microsoft libraries are also vulnerable. For example, an "application policy" for code signing could also be applied for and malicious code could be signed accordingly.

Is it really that simple?

In my opinion, not really, because many circumstances have to come together for the attack to work:

  • The error only exists with version 1 certificate templates.
  • The error only occurs with offline certificate templates, i.e. those where the applicant is free to choose the identity of the certificate issued anyway.
  • To exploit the error, the attacker needs rights to request certificates from the corresponding certificate template.
  • There are simple countermeasures, which are described below.

However, it can be assumed that there are still many generally poorly secured installations of Active Directory Certificate Services.

There is currently no patch from Microsoft (I also assume that no one will come any time soon).

Countermeasures

Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.

Deactivating the version 1 standard certificate templates

The following certificate templates are vulnerable to the attack:

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

If these are removed by the certification authority, it is no longer possible to attack them. It is generally advisable not to use version 1 certificate templates, but to always use self-defined templates that are derived from the version 2 and 3 certificate templates supplied.

The discoverer of the gap also has provided a scriptbut there is an even simpler way:

"ExchangeUserSignature", "ExchangeUser", "CEPEncryption", "OfflineRouter", "IPSECIntermediateOffline", "SubCA", "CA", "WebServer", "EnrollmentAgentOffline" | % { if ( (Get-CATemplate).Name.Contains($_)) { Remove-CATemplate -Force }}

Prevent the publication of version 1 certificate templates directly during the installation of the certification authority

If you install a Microsoft certification authority with default settings, the default certificate templates are automatically published on the certification authority.

However, this behavior can be changed by setting the LoadDefaultTemplates directive to "false" in a configuration file (capolicy.inf) can be prevented. A minimal variant of such a file could look like this:

[Version]
Signature="$Windows NT$"

[Certsrv_Server]
LoadDefaultTemplates=0

The file must be saved in the C:\Windows directory with ANSI / Windows-1252 (Latin-1, Western European) encoding before the certification authority role is configured.

The information I have used and installation scripts published on GitHub for Microsoft certification bodies take this into account accordingly.

Removing the "Application Policies" certificate extension from issued certificates

By default, the Windows Default Policy module of the certification authority is responsible for writing this certificate extension to issued certificates.

The "Application Policies" certificate extension can be disabled with the following command line command on the certificate authority.

certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.21.10

The certification authority service must then be restarted for the changes to take effect.

Certificates issued from this moment on only contain the "Extended Key Usage" extension, but not the "Application Policies" extension.

The information I have used and installation scripts published on GitHub for Microsoft certification bodies take this into account accordingly.

Other

Try it out with PSCertificateEnrollment

I have the PSCertifiateEnrollment PowerShell module is supplemented by the Application Policies extension, so that the scenario can be easily recreated.

Import-Module PSCertificateEnrollment
$Csr = New-CertificateRequest -Upn "Administrator@domain.tld" -ApplicationPolicy ClientAuthentication
$Csr | Get-IssuedCertificate -ConfigString "CA-Name\Hostname" -CertificateTemplate "WebServer"

Does a policy module help here?

Yes and no.

The error lies in the Windows default Policy modulewhich is part of the Active Directory Certificate Services. It would also be very easy to add protection to the TameMyCerts Policy Module to integrate.

However, in my opinion, the countermeasures available with on-board resources are completely sufficient to render the attack ineffective. Even a patch cannot save poorly configured and poorly secured certification authorities.

In any case, it makes sense to restrict the usable certificate fields and the format and scope of the identities that can be requested as much as possible for offline certificate templates. This can be easily implemented with the TameMyCerts Policy Module for Microsoft Active Directory Services.

Related links:

External sources

en_USEnglish