The tale of Enhanced Key (mis)Usage

One of the commonly recommended solutions to increase the security of user accounts in the on-premise Active Directory is to require two-factor authentication using Smart Cards. Not everyone knows that Windows Smart Card implementation has undergone a significant change years ago that has not been clearly reflected in the publicly available documentation. Since Public Key Infrastructure (PKI) security is not a typical piece of knowledge, therefore many enterprises may be at risk.

Smart Card Logon

In order to logon to the Windows system with a Smart Card, a specific user certificate needs to be present on it. There are different ways of mapping certificate to a particular user account in Active Directory and concrete requirements for such a certificate described in Smart Card Technical Reference document.

One of these requirements is related to Enhanced Key Usage (EKU) extended property value:

“If an EKU is present, it must contain the smart card sign-in EKU”

The document also precisely defines how the Key Distribution Center (KDC) located on a domain controller should handle EKU:

“By default, the KDC verifies that the client’s certificate contains the smart card client authentication EKU szOID_KP_SMARTCARD_LOGON. However, if enabled, the Allow certificates with no extended key usage certificate attribute Group Policy setting allow the KDC to not require the SC-LOGON EKU.”

Certificates intended for Smart Card logons are usually issued by Active Directory Certificate Services using dedicated templates with szOID_KP_SMARTCARD_LOGON (1.3.6.1.4.1.311.20.2.2) EKU, for instance:

Certificates intended for Smart Card logons are usually issued by Active Directory Certificate Services

Example certificate template

Certificate allowing for Smart Card logons is then another type of authentication credential in Active Directory environments which is valid for an extensive period of time, i.e. until its expiration time (by default 1 year) regardless of password changes for the account or until explicit revocation. It’s also important that Smart Card logon is natively supported end enabled in Windows default configuration, ready to use if PKI is in place.

A bit of history

In Windows Server 2003 R2 and below Smart Card Logon EKU was mandatory. Logons with certificates without szOID_KP_SMARTCARD_LOGON EKU were not allowed at all:

In Windows Server 2003 R2 and below Smart Card Logon EKU was mandatory.

Windows 2003 R2 failed logon event

To allow for more flexibility, this restriction has been relaxed in Windows 2008 / Vista but Microsoft emphasized that it’s still considered as a best practice and it needs be explicitly changed by system administrator:

“To better support smart card deployments, Windows Vista enables support for a range of certificates. Customers now have the ability to deploy smart cards with certificates that are not limited by the previous requirements. Specific certificate requirements that were changed are itemized in the following list:

  • UPN is no longer required.
  • For smart card logon, the Enhanced Key Usage (no need for smart card logon object identifier) and Subject Alternative Name (need not contain e-mail ID) fields are not required. If an enhanced key usage is present, it must contain the Smart Card Logon enhanced key usage.
  • You can enable any certificate to be visible for the smart card credential provider.
  • Smart card logon certificates do not require a Key Exchange (AT_KEYEXCHANGE) field.
  • Certificate Revocation List (CRL) is no longer a required field.

Because the restrictions found in previous versions of Windows are still considered best practices for certificate deployment, the listed changes are not enabled by default except for multiple certificates support (some certificates are excluded). Administrators need to configure the registry keys on client computers to enable the functionality. Group Policy can be used to accomplish this configuration.”

Allow certificates with no extended key usage certificate attribute Group Policy setting has been introduced in Windows Server 2008 but according to its description, the scope was limited to a listing of certificates on the logon screen only:

Allow certificates with no extended key usage certificate attribute Group Policy setting has been introduced in Windows Server 2008

Old policy setting description

Current state

Windows 2008 R2 introduced the current shape of Allow certificates with no extended key usage certificate attribute Group Policy setting description:

Windows 2008 R2 introduced current shape of Allow certificates with no extended key usage certificate attribute Group Policy setting description

Current policy setting description

As shown above, the Group Policy setting no longer explains that it applies only to the listing of certificates in GUI so one can reasonably assume that this setting applies to both clients (logon screen) and servers (KDC). Surprisingly, KDC now allows certificates with just Client Authentication Enhanced Key Usage extended property value alone to be used for Smart Card logons.

In other words, certificates with no Smart Card Logon EKU can be used for Smart Card logons, regardless of the value of ‘Allow certificates with no extended key usage certificate attribute’ Group Policy setting.

(mis)Use Cases

Many enterprises using Public Key Infrastructure (PKI) based on Microsoft Active Directory Certificate Services may be affected by some of the scenarios related to the certificate / Smart Card Logon EKU issue described in this article. The biggest space for misuse exists when it is combined with PKI configuration flaws which allow users to request and obtain certificates with arbitrary Subject or Subject Alternate Name (SAN). This can easily lead to impersonation of every user in the domain including Domain / Enterprise Admins group members and in consequence compromise of the entire Active Directory forest.

Subject Alternate Name (SAN)

One of the common use cases for internal PKI is issuing certificates for webservers serving intranet applications. Administrators usually want to add additional hostnames to such certificates which can be achieved in combination with allowing SAN request attributes to be provided (+EDITF_ATTRIBUTESUBJECTALTNAME2 flag set on CA). If done without expertise in PKI, this can have truly catastrophic consequences.

Why?

EDITF_ATTRIBUTESUBJECTALTNAME2 flag applies to the entire Certificate Authority so every single certificate template which allows non or less privileged user to enroll for a certificate with Client Authentication (1.3.6.1.5.5.7.3.2) EKU can be misused to issue certificate having Domain / Enterprise Admins member as additional User Principal Name (UPN). If Certification Authority is also present in the Enterprise NTAuth store, then such a certificate allows for Smart Card logon as the most privileged Active Directory users and the game is over.

If this flag is set on a CA, issuance of certificates with Client Authentication EKU must be strictly controlled

If this flag is set on a CA, issuance of certificates with Client Authentication EKU must be strictly controlled

Example certificate allowing to logon as domain admin which can be obtained by regular user with permissions to use template with Client Authentication EKU when EDITF_ATTRIBUTESUBJECTALTNAME2 flag is set on CA

Example certificate allowing to logon as domain admin which can be obtained by a regular user with permissions to use template with Client Authentication EKU when EDITF_ATTRIBUTESUBJECTALTNAME2 flag is set on CA

Compromised workstation

Even if the spectacular elevation of privileges to Domain Admin is not possible, users sometimes are given certificates having Client Authentication EKU needed for authenticating them to different services. Again, if the Certification Authority which issues such certificates is present in the Enterprise NTAuth store, then the certificate allows for Smart Card logon even when the company does not use Smart Cards knowingly at all.

When a user’s workstation is compromised, the attacker can potentially steal certificates along with their private keys (unless additional protection is in a place like by Trusted Platform Module (TPM)). Then reimage of the workstation and resetting the user’s password(s) is not enough because the attacker may still possess a valid user certificate which allows for network logon using the victim’s identity. Furthermore, it is possible to use the certificate for remote logon from a computer which is not a domain member.

In both cases, the attacker doesn’t need to use a physical Smart Card and install any additional drivers, thanks to the Microsoft Virtual Smart Cards feature introduced in Windows 8. Besides direct logon to remote resources, the certificate holder can also obtain NTLM hash or Kerberos tickets which can be used later for lateral movement.

Is it right?

Microsoft Security Response Center (MSRC) has been informed about this issue on 01/01/2020 as a potential PKINIT implementation flaw. The described behavior has been classified as “by design”. After further inquiries, MSRC replied that part of the Smart Card Technical Reference describing KDC behavior may be incorrect and they are working on documentation updates. The cited documentation parts have not been updated so far (as of 15 Sep 2020). Likely due to features introduced relying on certificates without Smart Card Logon EKU like Domain-joined Device Public Key Authentication or Next Generation Credentials, there’s no easy way to return to behavior which is documented.

Recommendations

PKI is definitely a Tier-0 and critical security infrastructure. In order to protect themselves from attack vectors described above, companies should carefully plan and manage their PKI deployments, especially:

  • Follow Microsoft recommendations on securing Public Key Infrastructure (PKI)
  • Do not use EDITF_ATTRIBUTESUBJECTALTNAME2 flag on Certificate Authorities issuing certificates with Client Authentication EKU
  • Require CA certificate manager approval for certificate enrollment using templates allowing for arbitrary Subject / Subject Alternate Name attribute and having Client Authentication EKU
  • Consider separate Certification Authority for issuing certificates intended for Smart Card logons
  • Limit number of Certificate Authorities in Enterprise NTAuth store
  • Use secure key storage providers to ensure certificate private keys are non-exportable
  • Audit PKI infrastructure regularly

Detection

It’s also recommended to track logons using Smart Cards to monitor suspicious events. Kerberos Authentication Service auditing allows for logging of the certificate issuer and pre-authentication type:

  1. The user certificate has a Smart Card Logon EKU
  2. The user certificate has a UPN in Subject Alternative Name.
  • Pre-Authentication Type 16 (PA-PK-AS-REQ) — can be used to identify authentications with certificates without Smart Card Logon EKU. 

Note: When Windows Defender Credential Guard is active on source client then the PA-PK-AS-REQ identifier (16) is being sent regardless of Smart Card Logon EKU. Also, other features may interfere.

Event log information helpful with tracking Smart Card logons. Note: Pre-Authentication Type of 16 is not liOfficial documentation of event 4768

Event log information helpful with tracking Smart Card logons. Note: Pre-Authentication Type of 16 is not listed in the official documentation of event 4768

Summary

There are not many people with an in-depth understanding of Microsoft PKI and, as shown in this document, it is not possible to fully rely on publicly available documentation. This creates dangerous conditions exposing many enterprises to extreme risk. Companies using Public Key Infrastructure are strongly advised to perform an assessment of their PKI deployments and consider presented recommendations to ensure they don’t allow for unforeseen authentications.

TL;DR

Despite what official documentation says, Smart Card logon EKU is not required for Smart Card-based user authentication in Active Directory. If you are not aware of this fact, review your PKI configuration because under certain circumstances (e.g. EDITF_ATTRIBUTESUBJECTALTNAME2 flag enabled on CA issuing certificates with Client Authentication EKU), it may be possible to elevate privileges from regular user to Domain Admin within 5 minutes and without any hacking tools.

About the Authors

The above case study was investigated and explained by Maciej Kosz in cooperation with Mike Jankowski-Lorek.

Maciej Kosz is a cybersecurity passionate with 19 years of experience in IT and 8 years in IT Security. During that time, he had the opportunity to practice in various areas and gain insight into the holistic security of enterprises. Currently, he focuses on cyber defense and purple team operations. He is also an occasional speaker at industry conferences. He is also a graduate of the CQURE Academy Advanced Windows Security Course. LinkedIn: Maciej K.

Mike Jankowski-Lorek, Ph.D. and CQURE expert, is a solution architect, developer, data scientist, and security expert with more than 15-years’ experience in the field. He designs and implements solutions for Databases, Network & Management area, mainly for Microsoft platform for medium to enterprise-level organizations. He is a lecturer at the Polish-Japanese Academy of Information Technology in Warsaw and he has appeared as a speaker at the most important cybersecurity conferences, including RSA, Black Hat, and NT Konferenca. LinkedIn: Mike Jankowski-Lorek

References

Check if your cyber-skills are still on point by taking the new CQURE quiz created by Paula J. and the team of experts at CQURE. We’ve set nearly 30 multiple-choice questions for the class of 2020 to sort the cyber-savvy from the geeky newbies.

Ready for the challenge? Take CQURE Quiz 5.0

 

 

Comments