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.
Not that if you have local access to the CA server, you can directly forge certificates using the private key without the CA service being aware of. Works with every kind of key backend, HSM or not: https://www.gradenegger.eu/en/signing-of-certificates-bypassing-the-certification-authority-with-on-board-means-alone/
You are of course right and your blog posts on that topic are very instructive where I have been very briefly mentioning 'certutil -sign'.
However in most cases (e.g. with a CA key with default ACL in the software KSP) the attacker needs local administrative rights in the CA server in order to do so. With a CA key in YubiHSM any login with a locally unprivileged account is sufficient to use the key.
So while something like granting remote login rights on an AD member server to the Domain Users group is most often not a good idea, it is absolutely fatal on an ADCS server with CA key in a YubiHSM (unless as a bare minimum read access to AuthKeysetPassword is severly restricted to the system account).
Im curious, why is this classified as an ADCS vulnerability? From what I can tell, this doesn't appear to be any issue with ADCS itself, but rather a design flaw (and major one in that) in the HSM. I'm shocked that Yubico's YubiHSM2 is a FIPS-140 certified hardware security module since the main issues you are calling out (password stored in registry in cleartext, and no user authentication) should immediately disqualify it from being certified. In fact, it seems to me that using the default DPAPI protection would be better than using this HSM since extracting DPAPI keys is more likely to get detected as malicious than querying a single registry key.
Nevertheless, a neat find and good read.
You are right, this is no ADCS vulnerability. It is a weakness in the KSP middleware that can be mitigated by hardening the Windows server hosting ADCS.
However I see the ESCn series not defined as ADCS weaknesses (or in many cases ADCS configuration issues) but as ways for an attacker to obtain unauthorized certificates for PKINIT Kerberos authentication with privileged accounts (a.k.a. Golden Certificates).
I don't think it should be shocking that a FIPS 140(-2 or -3) certified module is not immue to such issues.
On the one hand, midleware such as a KSP is not in scope of the FIPS 140 evaluation.
On the other had, every server/application that uses keys in an HSM must store the required credentials somewhere to permit an unattended restart. Otherwise a human would have to enter these credentials after each restart, which is someting many security people would like to have but nobody wants to do in regular operation.
Of course the HSM credentials could be better hidden, protectd by DPAPI or similar.
Speaking of DPAPI: One should not compare extraction of a DPAPI-protected CA key with this (ab)use of the key in the HSM. There is no known way of extracting the CA key from a YubiHSM (to be precise: since a few weeks except for the EUCLEAK attack if the CA uses an ECDSA key and not the very latest HSM firmware version).
Whereas extraction of a DPAPI key is not easy but not impossible. Without proper disk encrption maybe even with hypervisor or storage or backup privileges only.
One should rather compare it with an unauthorized use of a DPAPI protcted key in place on the CA server. Which, as Uwe Gradenegger pointed out in his comment above, any local admin could do. Using ESC12, even a non-privileged user with access to the CA server could do it, hence the urgent recommendation to keep any non-CA-admin user off the CA server.