Security - 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.

How the TameMyCerts Policy Module for Active Directory Certificate Services (ADCS) can prevent attacks against the ESC1 attack vector

Attacks on Microsoft certification authorities can be aimed at exploiting authorizations on certificate templates. In many cases, certificate templates must be configured to grant the applicant the right to apply for any identities. This can lead to the attacker taking over the identities of Active Directory accounts and subsequently to the elevation of rights. Attacks of this type are known in the security scene as "ESC1" is labeled.

How the TameMyCerts Policy Module for Active Directory Certificate Services (ADCS) can detect and prevent attacks against the ESC6 and ESC7 attack vectors

With the supposedly good intention of making it possible to issue such certificate requirements with a SAN, guess unfortunately much at many Instructions to set the flag on the certification authority EDITF_ATTRIBUTESUBJECTALTNAME2 to activate.

If this flag is activated, a very large attack surface is offered, as any applicant can now instruct the certification authority to issue certificates with any content. This type of attack is known in the security scene as ESC6 and ESC7 known.

How the TameMyCerts Policy Module for Active Directory Certificate Services (ADCS) can help secure scenarios with Microsoft Intune and other Mobile Device Management (MDM) systems

Companies use Mobile Device Management (MDM) Products for managing, configuring and updating mobile devices such as smartphones, tablet computers or desktop systems via the Internet (over-the-air, OTA).

Common mobile device management products are:

Microsoft Intune
VMware Workspace One (previously known under the brand name AirWatch)
Ivanti MobileIron UEM
Jamf Pro
Baramundi Enterprise Mobility Management
BlackBerry Enterprise Mobility Suite
Sophos Mobile Control
SOTI MobiControl

Signing certificates bypassing the certification authority - solely using built-in tools

In the article "Signing certificates bypassing the certification authority"I described how an attacker with administrative rights on the certification authority can generate a logon certificate for administrative accounts of the domain by bypassing the certification authority software, i.e. by directly using the private key of the certification authority.

In the previous article I described the PSCertificateEnrollment Powershell Module is used to demonstrate the procedure. Microsoft supplies with certreq and certutil However, perfectly suitable pentesting tools are already included with the operating system ex works.

A policy module to tame them all: Introducing the TameMyCerts Policy Module for the Microsoft Certification Authority.

As a Certification Authority operator, you are (among other things) responsible for the identification of the enrollees and the confirmation of the requested identities. The fact that this task is carried out conscientiously and without error is the central pillar of the trust placed in the certification body. Well-known companies are already failed in this task, even had to file for insolvency as a result of misrepresentations and / or were taken over by the big players in the market sensitive punished.

In many cases, we as (Microsoft) PKI operators in companies (regardless of the associated quality) are able to delegate our task of uniquely identifying an applicant to the Active Directory. In many cases, however, we unfortunately also have to instruct our certification authority(ies) to simply issue everything that is requested.

Enabling Basic Authentication for the Network Device Enrollment Service (NDES)

If the Network Device Enrollment Service (NDES) is reinstalled (Preferably without Enterprise Administrator permissions), only the Windows-integrated authentication for the administration web page is activated at first. With this (via NT LAN Manager, NTLM) protocol, authentication via user name and password is also possible. However, not all client applications support this.

Likewise, a company might be willing to, Disable NTLM where possible and enforce Kerberos for login. Enforcing Kerberos removes the ability to log in to the Network Device Registration Service administration page via username and password (since this is done with NTLM credentials). However, Basic Authentication can be retrofitted to provide an option here again.

One way out of this dilemma can be Basic Authentication, the setup of which will be explained below.

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.

Changes to Certificate Issuance and Certificate-Based Logon to Active Directory with the May 10, 2022 Patch for Windows Server (KB5014754)

With the May 10, 2022 patch, Microsoft is attempting to patch a vulnerability in the Active Directory in which the certificate-based enrollment (commonly known as PKINIT or also Smartcard Logon) to close.

The update changes both the behavior of the Certification Authority as well as the behavior of Active Directory when processing certificate-based logins.

Basics: Name Constraints

Name restrictions are a part of the X.509 standard and in the RFC 5280 described. They are a tool that can be used within the qualified subordination can be used to control the validity range of a certification authority certificate in a fine-grained manner.

Limits of Microsoft Active Directory Certificate Services

Active Directory Certificate Services have existed (albeit under a different name) in their basic form since Windows NT 4.0. The architecture based on Active Directory used today was introduced with Windows 2000 Server. AD CS are very well integrated into the Windows ecosystem and continue to be very popular in enterprises and government agencies of all sizes worldwide.

People like to point out the many possibilities offered by Active Directory Certificate Services. Rarely, however, is reference made to what can be done with them. not is possible. In the meantime, the product has also reached its limits in many places.

What these are will be explained in more detail below in order to better decide whether the AD CS can be the right solution for planned projects.

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.

Configuring the Trusted Platform Module (TPM) Key Attestation

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 only a default setting for the client. The certification authority will, when requesting do not explicitly check whether a Trusted Platform Module was really used.

To ensure that the private key of a certificate request has really been protected with a Trusted Platform Module, only the TPM Key Attestation remains.

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.

Is there a dependency of the Network Devices Registration Service (NDES) with the NTAuthCertificates object?

The Network Device Registration Service (NDES) has two Registration Authority Certificates. With the enrollment agent certificate, certificate requests are signed and one can use the Configure NDES device template accordingly so that certificates are also only issued if the submitted certificate requests also have a corresponding signature..

Do you plan to use the Certification Authority connected to the NDES remove from the NTAuthCertificates objectThe question may arise as to whether mutual dependencies need to be taken into account here - after all, this requires Enroll on Behalf Of (EOBO) the presence of the certificate authority certificate in NTAuthCertificates.