How to hack a smartcard to gain privileged access

Using smartcards in a Microsoft Active Directory environment makes them vulnerable to this privilege escalation attack.

I can change an email address and steal your most privileged credentials.

One of the most consistent IT security best practice recommendations is to require that admins use multi-factor authentication (MFA). In many corporate environments, this means using smartcards. Most smartcard environments don’t know that using smartcards (in an Active Directory environment) makes privilege escalation incredibly easy.

The hack I will discuss isn’t new. I learned it from someone else about 15 years ago. I can’t remember who, and they didn’t invent it. When I show this hack, it still seems to surprise everyone, especially smartcard administrators. I’m showing this smartcard hack demo for the first time here and as part of my RSA 2019 12 Ways to Hack MFA presentation on March 8.

Multi-factor authentication basics

Every MFA solution is tied to a specific “subject.” The subject is an identifier for a particular identity. The identity can be a random label, a name, email address, LDAP address, DNS address, IP address…almost anything as long as it is unique in a particular namespace (e.g., DNS, Active Directory, LDAP directory or authentication database). Multiple instances of an authentication device can have the same subject label, but the subject name must be unique in the namespace. In most cases, the authentication device is tied, often cryptographically, to the subject label it is representing.

For example, when a digital certificate is created, many of the included fields are cryptographically “protected” (meaning verifiable) to the private and public entity that makes the digital certificate. Changing the subject name would immediately render the digital certificate invalid. This makes sense, because the user providing the authentication device is saying, “This is who I am.” Then providing a password, PIN or biometric attribute proves they own the subject attested to by the authentication device.

Proof of owning the submitted subject/identity successfully authenticates you. The authenticated identity is then usually associated with a subject-specific access control cookie or token. This token can then be presented to the access control checking components of the (operating) system when the identity tries to access protected information. The cookie or token is associated with the assigned permissions, privileges and other authorization attributes (such as group membership).

If a hacker can take control of a subject’s access control cookie or token, they are usually treated as if they are the real user/subject. The (operating) system often has no way of knowing whether the subject presenting the access control cookie or token really is the legitimate user. It takes any submitted access control cookie or token as valid and being used correctly by the previously validated user.

How a subject hijack attack works

It’s important to understand the significance of the subject label to the overall authentication process to understand this class of hack. The overall hack can be summarized like this: If I can steal the subject label attached to your authentication method, I might be able to steal your identity even if you use otherwise very secure and trusted MFA.

As a demonstration, let me show you an example involving Active Directory and AD-integrated smartcards. Tens of millions of Active Directory users and admins secure their logons using this configuration. In this particular hack demo, the attacker is a low-privileged valid user (named HelpDesk). The target of the identity theft attack is a highly privileged user (named SuperAdmin) who belongs to every elevated group in Active Directory (schema admins, enterprise admins and domain admins).

To continue reading this article register now

Get the best of CSO ... delivered. Sign up for our FREE email newsletters!