Attack vector on the Active Directory directory service via the smartcard 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 their private key is known only to it.

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

The following steps should never be performed in a production environment. The demonstration performed here is not a guide to breaking into computer systems; rather, it is intended to highlight the security risk so that countermeasures can be initiated.

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

A domain controller that has successfully verified the user's logon will then visit the same field in Active Directory and issue the logon user a corresponding Ticket Granting Ticket (TGT) - 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.

Also a Incorrectly configured certification authority, certificate template or Interface can be misused to issue a certificate usable for this attack.

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 prevented by the use of Hardware Security Modules (HSM) on the certification authorities is effectively prevented. 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. smartcard, 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.

For the sake of simplicity, the ways in which an attacker obtains system privileges on a CA will not be discussed, as these are universal to Windows servers.

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 Windows on-board resources 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 certificate authorities for which smartcard enrollment 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 logins when smart card logins 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 this with the deterministic Good combine to obtain an auditing path for the performed logins and to prevent logins with unknown certificates.
Insecure interfaces (such as SCEP) and certificate templates, which allow the identity to be specified by the enrollee, can be created with the TameMyCerts Policy Module for Microsoft Certification Authority be effectively restricted.

Attack vector on Active Directory directory service via smartcard logon mechanism

Countermeasures

Related links:

External sources

17 thoughts on “Angriffsvektor auf den Active Directory Verzeichnisdienst über den Smartcard Logon Mechanismus”