How to hack a smartcard to gain privileged access

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

The only elevated privilege HelpDesk has beyond a regular user is the ability to change a user’s Active Directory user principal name (UPN). This sort of permission is often granted to low-level admins. A user’s UPN is often identical to the user’s email address, although they do not have to be. The only requirement for the UPN is that it is unique within the same Active Directory forest.

Here’s a summary of the hack:

1. Low-privileged HelpDesk admin switches UPNs with SuperAdmin
2. HelpDesk admin logs in using their own HelpDesk smartcard and PIN
3. Viola! HelpDesk admin becomes SuperAdmin, including all group memberships
4. HelpDesk performs malicious actions
5. System tracks all actions as SuperAdmin
6. When HelpDesk is finished, they log out and switch UPNs back. No one knows the difference

Ask yourself how many people in your Active Directory environment have the ability to change a user’s UPN. Would your event logging system detect and alert on a UPN change? My guess is no for most environments.

Step-by-step smartcard hack demo

Here’s a description of the demo I’m presenting at the RSA conference:

1. Verify SuperAdmin’s UPN (which is represented as “User logon name” in Active Directory).

Roger Grimes

2. Verify that SuperAdmin belongs to elevated groups.

Roger Grimes

3. Verify that SuperAdmin’s UPN is tied to the SuperAdmin’s smartcard, including the unique digital certificate thumbprint related to SuperAdmin’s smartcard.

Roger Grimes

4. Log on as SuperAdmin using SuperAdmin’s smartcard and PIN.

Roger Grimes

5. Verify that SuperAdmin has successfully logged on using SuperAdmin’s smartcard and PIN.

Roger Grimes

6. Verify SuperAdmin has elevated group memberships.

Roger Grimes

7. The less privileged HelpDesk user logs on using their own smartcard and PIN (before the hack is accomplished to show current state).

Roger Grimes

8. HelpDesk’s smartcard information shows helpdesk@victim.com UPN and HelpDesk’s unique digital certificate thumbprint.

Roger Grimes

Roger Grimes

Roger Grimes

9. The lower-privileged HelpDesk user swaps its UPN with the SuperAdmin user using Active Directory Users and Computers. To do this, the HelpDesk user must first change to their UPN with any other value because Active Directory will not let two accounts share the same UPN at the same time.

10. The HelpDesk user updates the SuperAdmin’s UPN to read helpdesk@victim.com, to be the same as the UPN it holds on its own smartcard.

Roger Grimes

11. The HelpDesk User logs out, waits a few minutes for Active Directory replication to occur, and then logs backs in.

Roger Grimes

Roger Grimes

12. Although the HelpDesk user logged on using their associated HelpDesk smartcard and PIN, Active Directory has now associated them with the SuperAdmin user because SuperAdmin now has the helpdesk@victim.com

Roger Grimes

Roger Grimes

At this point, the HelpDesk user can do anything SuperAdmin could currently do, and Microsoft Windows and Active Directory would track all Windows events as if they were occurring from SuperAdmin, not HelpDesk. After committing other unauthorized actions, such as confirming they can always elevate their security credentials, the HelpDesk user could swap back the UPNs, and unless UPN updates are being logged and the importance of those particular actions were noticed, it would be difficult to see what actually happened.

Some logon events are registered at the domain controllers, such as Event ID 4768, which would include each supplied smartcard’s thumbprint. That could be reviewed to reveal that the HelpDesk user’s smartcard was now somehow associated with the SuperAdmin account, but forensics investigators would have to be aware of and seek to validate this particular hack scenario. It would not be easy to discover when trying to discuss what really happened.

Interesting hack, yes?

You might say that the attack requiring a previously validated user account that can change another user’s UPN is a high starting bar, and I agree. This is just a representative example of the possible outcome of a subject hijack attack. Other similar attacks using other solutions might not have as high prerequisites.

Even in this Active Directory hack type, I can use any other valid and trusted smartcard identity, even if that identity does not exist in the victim’s Active Directory. I can make up a new smartcard with the subject of frog@victim.com (which does not exist as a user in Active Directory), change SuperAdmin’s UPN to frog@victim.com, login as frog@victim.com with its valid associated PIN, and Active Directory will not care that frog@victim.com does not exist anywhere but as the UPN under SuperAdmin’s account.

Smartcard lessons to be learned

Let me be clear. This isn’t a Microsoft or Active Directory bug. This is an “as-designed” operation of smartcards. No fix is coming. If you allow the subject of a smartcard to be hijacked, you can expect this sort of mischievousness to occur. Similar attacks are likely to be executed against other MFA solutions if the subject can be hijacked.

The lesson is that any attribute that is used in an authentication consideration should be treated like a password. We obviously have all sorts of logging and protection surrounding preventing passwords from being viewed or stolen, but not around all the other authentication attributes, and there should be.