Since I assume that the following information is also of interest to non-German-speaking readers, I am writing this post in English as an exception.
Preface
This post is in no way meant to discourage the use of the Yubico YubiHSM2 for CA keys of AD Certificate Services CAs. On the contrary, I recommend using a YubiHSM2 over storing the CA private key in software (i. e. using the Microsoft Software Key Storage Provider) in almost all usage scenarios.
It is merely intended as a warning not to forget hardening of the CA server, in particular limiting network and console access to authorized users, just because the key is stored in a hardware security module.
ESC1 to ESC11
Various privilege escalation (vulgo attack) methods to obtain certificates that can be abused to obtain Kerberos tickets for high-privileged user or computer accounts (a.k.a. Golden Certificates) have been published before. In their important whitepaper "Certified Pre-Owned" the SpecterOps team numbered several potential ways by which attackers can obtain Golden Certificates from ESC1 to ESC8. Later-on Oliver Lyak described ESC9 and ESC10 and Sylvain Heiniger of Compass Security added ESC11.
In this tradition, I take the liberty of naming the following attack vector ESC12.
Peculiarities of the YubiHSM Key Storage Provider
Yubico's YubiHSM2 is arguably the most affordable FIPS-140 certified hardware security module and as such a good alterative to storing CA keys in software. It is a USB device in the same form factor as the smallest of the popular YubiKeys. It is either directly connected to a USB port of the CA server or (most often if the CA server is a virtual machine) via a USB device server (a.k.a. "dongle server") and corresponding client software that pretends it to be a locally connected USB device.
The way to access a YubiHSM2 from the AD Certificate Services as well as from other Windows CNG compatible applications is to use the YubiHSM Key Storage Provider.
In order to generate and use keys in the YubiHSM, the Key Storage Provider must use an authentication key (sometimes dubbed "password"). This key/password is stored in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword
in cleartext (!).
Furthermore, the YubiHSM Key Storage Provider does not check under which user account processes calling it via CNG are running.
Abusing shell access to the CA server
It is always a good idea to limit access to a Windows server running a CA instance to PKI administrators and comparable administrators.
[With "comparable" I mean in particular AD domain admins who might place themselves in the security group of PKI administrators or reset a PKI administrator's password for impersonation and enterprise admins who might modify certificate templates in the AD Global Catalog to be vulnerable to ESC1 ff. attacks.]
For CAs using a YubiHSM this kind of hardening of system access is essential.
An attacker who can access the CA server as a regular non-privileged user can use two ways to access the CA's private key in the HSM.
Redirect USB device server
If the YubiHSM is connected to the CA server via a USB device server and the attacker has sufficient administrative access to this USB device server, he might abuse that to connect the YubiHSM to a machine under his control.
With local or network (or, heaven forbid, remote registry) access to the CA server, he can read the cleartext AuthKeysetPassword and configure this key/password in the registry of his own server to access the CA key. Note that restricting read access to HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword might prevent this.
The drawback of this way of attack is that - for most of the USB device servers that I know - either the USB HSM cannot be connected to another system as long as it is connected to the CA server or that the connection to the regular CA server is lost. In the latter case, the CA will stop working (i.e. fail to issue new certificates or CRLs), which should hopefully be detectable by some form of service monitoring.
Forge your own certificate
Another way of abusing local or network CA server access that does not require abuse of a USB device server and should be harder to detect is to access the CA key directly on the CA server as non-privileged user.
Assume the attacker is logged into the CA server as a non-privileged user. Then he can obtain the CA certificate as a certificate file (easy, it is public at least throughout the whole AD) and import it in his user profile certificate store on the CA server as his own via
certutil -addstore -user my <CA certificate file>
certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my <CA Common Name>
certutil -sign ...
to a creative use to forge his own certificate.
As an added bonus, this new forged certificate is not seen in the regular CA's database, its event log entries or the mails sent by the SMTP exit module. If the serial number of the base certificate modified using the "certutil -sign" command is set to an arbitrary new value, it cannot even be revoked by the CA - at least not until it is found in the wild and imported into the CA database.
What about other types of HSM?
Some other types of HSM (or more precisely: the associated Key Storage Provider, which is aware of its calling user account) are not susceptible to the latter type of attack.
However, since I am not familiar with all HSM brands on the market (let alone have access to test equipment), it seems not entirely unlikely to me that some HSM types are also susceptible to this.
