PSCertificateEnrollment - Uwe Gradenegger

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.

Character encoding in the Subject Distinguished Name of certificate requests and issued certificates

Usually, the encoding of characters and strings in certificates is not a topic of great interest to the users of a PKI. However, there are cases where the default settings of the certification authority do not provide the desired results.

Disabling NTLM and enforcing Kerberos at the Network Device Enrollment Service (NDES) administration web page.

Many companies pursue the strategy of (largely) disabling the NT LAN Manager (NTLM) authentication protocol in their networks.

This is also possible for the administration web page of the network device registration service (NDES). How exactly this is implemented and how this may change the application behavior is explained below.

The key algorithm of certificate requests is not checked by the certification authority's policy module

Assume the following scenario:

A certificate template is configured to use elliptic curve based keys (e.g. ECDSA_P256).
As a result, a minimum key length of 256 bits is configured.
Nevertheless, certificate requests that use other ECC curves or RSA-based keys are also signed.

From Zero to Enterprise Administrator through Network Device Enrollment Service (NDES) - and What to Do About It

In the following, I would like to present a highly dangerous PKI configuration, perhaps not necessarily known to the general public, which can probably be encountered quite frequently in this way in corporate networks.

I show how, by exploiting various unfortunate circumstances in the Windows PKI, it is possible to elevate privileges from mere network access to complete Active Directory takeover.

The initial point of attack in this example is the Network Device Enrollment Service (NDES).

Basics: Path Length Constraint

The attack on the MD5 signature algorithm demonstrated in late 2008 could only be used to create a usable forged certification authority certificate because the attacked certification authority had not configured any path length restriction.

The limitation of the path length is defined in the RFC 5280 described. The idea behind this is that the maximum depth of the certification authority hierarchy is stored in the "Basic Constraints" extension of a certification authority certificate.

Manually requesting a web server certificate

There are cases in which you cannot or do not want to obtain web server certificates directly from a certification authority in your own Active Directory forest via the Microsoft Management Console, for example if the system in question is not a domain member.

In this case, the use of certificate templates is not possible, and one must manually create a Certificate Signing Request (CSR).

Requesting a certificate protected by a Trusted Platform Module (TPM) - without owning a TPM

Since Windows 8 it is possible, that private keys for certificates are protected with a - if available - Trusted Platform Module (TPM). This makes the key non-exportable - even with tools like mimikatz.

However, it is not obvious at first glance that it cannot be guaranteed that a TPM is really used. Although no application via Microsoft Management Console or AutoEnrollment possible if the computer does not have a TPM.

However, the configuration in the certificate template is merely a default setting for the client. The certification authority will not explicitly check whether a trusted platform module has actually been used when a request is made.

Thus - if the certificate request is done away from the MMC - arbitrary parameters can be used for the private key.

Signing certificates bypassing the certification authority

Time and again in discussions about the security of a certification authority, it comes up that abuse of the certification authority could be contained by its security settings.

However, the fact that the integrity of a certification authority is directly tied to its key material and can therefore also be compromised by it is not obvious at first glance.

one must think of the certification authority software as a kind of management around the key material. For example, the software provides a Online interface for Certificate Enrollment takes care of the authentication of the enrollees, the automated execution of signature operations (issuing certificates and Brevocation lists) and their logging (Certification Authority Database, Audit log, Event log).

However, signature operations require nothing more than the private key of the certification authority. The following example shows how an attacker, given access to the certification authority's private key, can generate and issue certificates without the certification authority software and its security mechanisms being aware of this.

With such a certificate, it would even be possible in the worst case, take over the Active Directory forest undetected.

Certificate Enrollment for Windows Systems via the Network Device Enrollment Service (NDES) with Windows PowerShell

If you want to equip Windows systems with certificates that do not have the option of communicating directly with an Active Directory-integrated certification authority, or that are not even in the same Active Directory forest, the only option in most cases is to install certificates manually.

Since Windows 8.1 / Windows Server 2012 R2, however, there is an integrated client for the Simple Certificate Enrollment Protocol (SCEP) on board. On the server side, SCEP is implemented via the Network Device Enrollment Service (NDES) implemented in the Microsoft PKI since Windows Server 2003.

A particularly interesting feature of SCEP is that the protocol allows a certificate to be renewed by specifying an existing one. So what could be more obvious than to use this interface? What is still missing is a corresponding automation via Windows PowerShell.

Authentication at the Network Device Enrollment Service (NDES) with an existing certificate (renewal mode)

The Network Device Enrollment Service (NDES) has the ability to authenticate with a previously issued certificate in order to reapply for a certificate with the same content. This is very convenient for renewal operations, as it eliminates the need to apply for a one-time password beforehand.

Manual application for a domain controller certificate

There are cases where you cannot or do not want to obtain domain controller certificates from a certification authority in your own Active Directory forest.

In this case, the use of certificate templates is not possible, and one must manually create a Certificate Signing Request (CSR).