Attack vector on Active Directory directory service via smart card logon mechanism

In simple terms, public key cryptography can be reduced to the assumption that the private part of each key pair is known only to its owner.

A certification authority is responsible for the correct identification of users, computers or resources. Its issued certificates are therefore granted a trust status because all participants assume that its private key is known only to it.

If an attacker succeeds in gaining knowledge of a certification authority's private key, or at least to perform signatures using the private key , the integrity of the certification authority is no longer guaranteed.

To attack the Active Directory, the mechanism known as smart card logon is a good choice. Here, the user logs on using a certificate issued by a certification authority. The user's identity is represented in the certificate's "Subject Alternative Name" (SAN) of the "User Principal Name" (UPN) type.

A domain controller that has successfully verified the user's logon will then look up the same field in Active Directory and issue a corresponding Ticket Granting Ticket (TGT) to the user logging on - including that user's permissions.

The domain controller delegates the correct identification of the user to the certification authority. It is responsible for ensuring that the digital identity is actually assigned to the natural person behind it.

If the private key of the certification authority is compromised, signatures can be forged. This would enable an attacker to assume any identity in Active Directory, including administrative accounts.

Theft of private keys is effectively prevented by the use of hardware security modules (HSM) on the certification authorities. HSMs are special hardware devices that, among other things, allow authorized participants (such as a certification authority) to use a cryptographic key, but prevent copies of the key from being made.

However, even when hardware security modules are used, there is still an attack vector via the certification authority itself: In order for this to communicate with the HSM, middleware provided by the HSM manufacturer, a Key Storage Provider (KSP) is installed on the associated server. This enables programs to address a wide variety of key stores (e.g. smart card, trusted platform module, software, hardware security module) via a uniform interface.

The certification authority runs in the security context of the computer account (SYSTEM). If an attacker succeeds in gaining administrative rights on a certification authority, he can address the KSP directly with appropriate software and trigger signatures.

Corresponding software has been available in relevant circles since 2017 at the latest and also exists in the form of open source projects. Since signing certificates is a completely legitimate technical process, administration tools such as the PSCertificateEnrollment PowerShell module or even built-in Windows tools can be used for such a purpose .

With the resulting certificate, the attacker can then log on to the domain.

He is then assigned the permissions of the impersonated user (Enterprise Administrator in the example).

Countermeasures

The following options are available to counteract the problem:

• Remove all certification authorities for which smart card logon is not desired from the NTAuthCertificates object of the Active Directory forest (unless other services require the certificate here). See article "Editing the NTAuthCertificates object in Active Directory ".
• Basics: Restricting Extended Key Usage (EKU) in Certification Authority Certificates .
• Issue domain controller certificates that do not allow smart card logon when smart card logons are not desired in the enterprise. See article "Configuring a Certificate Template for Domain Controllers ".
• Force domain controller (or other participants) to use an Online Responder (OCSP) and combine this with deterministic Good to obtain an audit trail for the performed logons and to prevent logons with unknown certificates.
• Insecure interfaces (such as SCEP ) and certificate templates, which allow the identity to be specified by the enrollee, can be effectively restricted with the TameMyCerts Policy Module for Microsoft Certification Authority .

Related links:

• Basics: Restricting Extended Key Usage (EKU) in Certification Authority Certificates
• Domain controllers do not check Extended Key Usage on smart card logon
• Signing certificates bypassing the certification authority
• Signing certificates bypassing the certification authority - using built-in tools alone
• Active Directory forest compromised by EDITF_ATTRIBUTESUBJECTALTNAME2 flag
• From Zero to Enterprise Administrator through Network Device Enrollment Service (NDES) - and What to Do About It
• Basics: Cryptographic Service Provider (CSP) and Key Storage Provider (KSP)
• A policy module to tame them all: Introducing the TameMyCerts Policy Module for the Microsoft Certification Authority
• Network Device Enrollment Service (NDES) Basics

External sources

• Guidelines for enabling smart card logon with third-party certification authorities (Microsoft)