Why private keys of certificates need to be protected in a mimikatz world

As you might have heared from the news Dell is maybe selling some Windows based machines with a dangerous security flaw that could allow hackers (or after reading this articel, you) to access your computer. The following lines will explain why it is curcial to protect a certificates private key and for those of you who are more interessted in technical details I’ll explain how to export the private key from the machine even though it is marked as not exportable.

A user named „Rotocowboy“ reported on Reddit (https://www.reddit.com/r/technology/comments/3twmfv/dell_ships_laptops_with_rogue_root_ca_exactly/) that recent models of Dells laptops come with a preloaded self-signed digital certificate that could allow criminals to impersonate Dell and incertept traffice from and to your computer.

A certificate named „eDellRoot“ and a certificate „DSDTestProvider“ can be found in the machines „Trusted Root Certification Authority Certification“ store. In the following article I will only focus on the eDellRoot certificate but the same steps can be performed on the DSDTestProvider certificate.

„By default, the Trusted Root Certification Authorities certificate store is configured with a set of public CAs that has met the requirements of the Microsoft Root Certificate Program. Administrators can configure the default set of trusted CAs and install their own private CA for verifying software.
Note: A private CA is unlikely to be trusted outside the network environment.“
https://msdn.microsoft.com/en-us/library/windows/hardware/ff553506(v=vs.85).aspx

In this case the „eDellRoot“ certificate can be considered a private CA but due to the fact that the certificate comes pre-installed on some Dell machines, and without a little help gets automatically reinstalled after deletion, it is more or less trusted by anyone with a Dell machine.

Normaly certificates in the „Trusted Root Certification Authorities“ store are X.509 certificates without a private key. There is no reason to install a private key into this store because only the public key is required to validate a certificate offered/used by e.g. a HTTPS website.

The public key of the certification authority is used to build the so called certificate chain.
„A certificate chain consists of all the certificates needed to certify the subject identified by the end certificate.“
https://msdn.microsoft.com/de-de/library/windows/desktop/aa376515(v=vs.85).aspx

Now that the eDellRoot certificate includes both the private and the public key an attacker can use the private key of the certificate to sign its own certificate which is then automatically trusted by all affected Dell computers.

Let me give you an example:
- I’m the attacker and downloaded the eDellRoot certificate including the private key from the internet.
- Now that I have the certificate I can install by own certification authority using the existing key pair. https://technet.microsoft.com/en-us/library/hh848389(v=wps.630).aspx
- Create certificate for any purpose and any subject name that I like and signe them using my CA. e.g. a certificate for www.gmail.com
- Setup a fake website and install my own www.gmail.com certificate.
- With a little manipulation of the local hosts file or the DNS I redirect every request to www.gmail.com to my website and collect all usernames and passwords in your environment.
Sounds to easy to be true? It is that easy!

The private key of our CA certificate (it doesn’t really matter if it is the private of your CA or any other certificate) in this case is our most valuable property. Therefore we need to protect it as good as possible using a smartcard or a HSM. Security measures need to be taken and operations procedures must be in place to protect your private keys.

„My private key cannot be exported from the certificate store. I’ve configured this restriction when issuing/requesting the certificate. We are safe.“

I hear this excuse very often when talking to my customers about key protection. The truth is…THIS IS NO KEY PROTECTION!
Yes, you can configure a Windows certificate template to not allow the private key to be exported but this option can be changed manually when requesting the certificate. After that the private key can be exported even though you configerd the template the other way round.
And even if the certificate was sign and the export option was not changed during the request the private key is not safe on your machine.

As long as you are not using any kind of physical protection (Smartcard, HSM) the private key is allways stored in software on your Windows based machine. The is a way (a very simple one to be honest) to export the private key from the machine.

The following steps are just an example of how attackers would gain access to the private key. I do not recommend to use this as some kind of backup procedure or key recovery.

Now for the technicians out there I’ll show you how to export a certificate including its private key from the Windows certificate store even though the private key was marked as not exportable.

For this task to be completed we use a tool called „mimikatz“. (By the way one of my favourite tools when it comes to passwords and Kerberos tickets :-)).

In my lab I’ve configured a Windows Enterprise Root CA and a certificate template called „Lab-Computer“

The template does not allow the private key to be exportable.

I then enrolled a certificate on my Windows 10 client using this template and the default settings.

As you can see, the certificate can only be exported without its private key.

By the way…it could be any certificate and could also be the user certificate store instead of the machine store.

How do we get the certificate exported including the private key?

This is where mimikatz comes into the game. Mimikatz can be downloaded from http://blog.gentilkiwi.com/mimikatz and must be copied to the Windows machine where the certificate is installed. Please be aware that some anti virus scanners confiscate the mimikatz executables.
We now run mimikatz with administrative privileges. If I would be an attacker and don’t have administrative privileges on the target machine I could also use mimikatz to get these privileges using a pass the hash or pass the token attack. I might write an article about this topic later.

After mimikatz is started we can use the following two commands to export the previously

crypto::capi
crypto::certificates /systemstore=CERT_SYSTEM_STORE_LOCAL_MACHINE /export

This will export all existing certificates including the private key to the current directory.
The password for the generated pfx files is ‚mimkatz‘.

 To validate the export I’ll now import the pfx file to the user store just to show you that it includes the private key of the certificate.

Simply double click the pfx file and click „Next“.

We now can find the certificate including the private key (as you can see from the small key in the icon) in our personal certificate store.

Very easy and very dangerous.

God safe the keys!
Chris