Risk Assessment of Windows Cert Store

Question

We all know that SmartCards protect private keys much better than any software-based solution. However, when it comes to the Windows Cert Store to be compared to SmartCards: how difficult is it for an attacker to extract the private key of a certificate-bundle from that Windows Cert Store?

Asking this question, I am well aware of the conceptual challenges.

So asking differently:

• How difficult is it to extract a private key from the Cert Store? Assuming the attacker launches the attack with the following privileges:

1. power/common user,
2. local admin,
3. domain admin,
4. system

• Are there means to protect the Cert store such that it becomes more difficult for an attacker? For example, an attacker must launch an attack with "system" privileges and not just with "local admin" rights.

Alternatively: Can anybody share with me an in-depth risk assessment of the windows cert store?

Answer 1

Certificates alone don't contain private keys, but since you're talking about smart cards I presume you're comparing PKCS#11 with client certificate authentication, where the client certificate and its accompanying key is stored in the Windows certificate store.

If you just install the certificate without marking it as non-exportable, all a user has to do is right-click on it in certmgr to extract it. Normally, however, client certificates and their associated private keys are usually marked as non-exportable. Windows will not allow you to extract them through normal means.

Unfortunately, that doesn't mean you can't extract them in practice. Cryptographic secrets such as private keys are managed through either the CSP API (aka CAPI), or the newer CNG API. These APIs provide an interface to the certificate store and key store. These stores are primarily managed by the Local Security Authority (LSA), which runs as SYSTEM and is generally one of the most protected usermode processes on the system. The LSA's secrets are encrypted in memory, and only decrypted when needed. However, since a process running as SYSTEM effectively has complete control over all processes, including being able to open handles to the LSA, and the LSA itself must inherently have access to both the secrets and the key used to encrypt them, it is possible to patch the LSA to extract them.

Mimikatz supports doing this. It can patch both the CSP and CNG APIs so that all certificates can be exported even if they are marked as non-exportable.

Functionally, anyone from local admin up to domain admin can do this, since they're all capable of running commands as SYSTEM on the host. A normal user should not be able to gain the privileges they need, but that implies that there are no privilege escalation vulnerabilities on the system, in the OS itself or any software packages that are installed, and that is often not true.

This attack is made more difficult by the use of LSA isolation, which moves the core of the LSA into a protected enclave that is outside the reach of the operating system itself. However, it is still possible for an attacker who runs code as SYSTEM to install a Security Support Provider (SSP) that extracts certificates upon use. The exact level of risk depends on the specific configuration, but enabling Virtual Secure Mode so that the LSA can benefit from IUM is a significant security protection.