AD Certificate Services：有风险的设置及其修复

Active Directory Certificate Services 已经存在很长时间了，但用于学习它的资料并不多。因此，它往往存在配置错误，而这些错误正日益成为攻击的入口。事实上，SpecterOps 发布了一份 whitepaper ，其中详细说明了多种配置错误与潜在攻击，并提供了加固建议。在本博客中，我将介绍一些容易配置错误的设置、如何识别它们；还会提供若干进一步加固安全性的选项，并解释如何使用免费的工具来检查你的环境。

背景

当认证基于身份的证书签发给某个身份时，该证书可用于以 Subject Alternative Name (SAN) 中所设置的身份进行认证；通常这是一 个 UPN 或 DNS 名称。随后，该证书会在初始认证时代替密码使用。有关此初始认证的技术参考是 RFC4556 如果你想了解更多细节。

一旦签发了基于认证的证书，它就可以在证书被吊销或过期之前一直以证书主体身份进行认证。这样会绕过依赖于诸如重置用户密码以赶走攻击者之类策略的事件响应计划；除非同时吊销证书，否则攻击者可能会对该账户保持持续访问。

有风险的模板设置

以下是一些可能导致错误配置的证书模板设置。

基于认证的 EKU

首先查找能够支持任何类型的域级认证的增强密钥用法（Enhanced Key Usages，EKUs）。下面是一个简要列表：

• 任意用途 (2.5.29.37.0)
• SubCA（无）
• 客户端身份验证 (1.3.6.1.5.5.7.3.2)
• PKINIT 客户端身份验证 (1.3.6.1.5.2.3.4)
• 智能卡登录 (1.3.6.1.4.1.311.20.2.2)

手动查找所有允许此功能的证书模板，最简单的方法是打开证书颁发机构 (Certificate Authority) 的 MMC 管理单元，连接到你的 Certificate Authority，然后查看“Certificate Template（证书模板）”部分，并扫描“Intended Purpose（用途/预期用途）”列中是否包含任意这些身份验证 EKU。 例如，下图显示“Computer”、“Copy of Smartcard Logon”以及两个“Domain Controller”模板都至少包含一个 PKU。

在处理你找到的这些模板之后，请务必记住：还存在滥用常规证书的方法。例如，PoshADCS 的 Get-SmartCardCertificate 函数可以修改模板，为其请求证书，然后再撤销对模板所做的更改。

“Enrollee Supplies Subject（注册者提供主题）” 标志

当标志 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 出现在 mspki-certificate-name-flag 属性中时，证书的注册人可以在证书签名请求中提供自己指定的替代“主题名称”（Subject Name）。这意味着，任何被允许使用此设置注册证书的用户，都可以以网络中的任何用户身份（包括特权用户）来请求证书。

你可以在“Certificate Template（证书模板）”控制台中检查此标志；它位于“Subject Name（主题名称）”选项卡下，作为“Supply in the request（在请求中提供）”单选项显示：

或者，你可以使用类似下面的 PowerShell 命令从 AD 获取模板，并检查证书中是否设置了该标志：

      Get-ADobject -Filter { ObjectClass -eq "PKIcertificateTemplate" } -SearchBase (Get-ADRootDSE).ConfigurationNamingContext -prop * | Select Name, mspki-certificate-name-flag, @{ Name = "SupplyInRequest" ; Expression = { $_.'mspki-certificate-name-flag' -band 0x00000001 } }
      

进一步降低风险

除了纠正证书配置错误之外，还可以考虑使用以下选项来控制证书的签发。

CA 证书管理器批准或授权签名

首先，可能也是最重要的一点：查看每个证书上的“签发要求（Issuance Requirements）”选项卡，看看它是否需要由证书颁发机构（CA）管理器或一个或多个获授权人员进行批准。

启用这两个设置中的一个或两个，都可以通过在证书签发前要求进行检查来显著降低风险。如果您不确定是否需要授权签名，那么至少应要求 CA 证书管理器批准；这样，每次请求证书时，它都会在签发前提交给证书颁发机构（Certificate Authority）进行人工审查。

注册权限

其次，请查看每个模板中的“注册权限”，可在“安全（Security）”选项卡中找到。许多错误配置只有在通用主体（generic principals）或大型组拥有这些权限时才会变得至关重要。尤其要检查是否包含“已验证用户（Authenticated Users）”“域用户（Domain Users）”以及任何不应能请求证书的用户大型组；如果发现这些情况，请考虑撤销它们的“注册（Enroll）”或“自动注册（AutoEnroll）”权限。

EDITF_ATTRIBUTESUBJECTALTNAME2 注册表项

最后，请检查 EDITF_ATTRIBUTESUBJECALTNAME2 注册表设置。该设置是最值得关注的设置之一：如果在 CA 上启用，那么 any 已签发的基于认证的证书（包括主题从 Active Directory 自动生成的证书）可以在 SAN 中包含用户自定义的值。

要检查此设置，可以运行以下命令：

      certutil –getreg policyEditFlags
      

如果输出列表中包含 EDITF_ATTRIBUTESUBJECALTNAME2，应使用以下命令将其移除：

      certutil -config "CA CONNECTION STRING" -setreg policyEditFlags - EDITF_ATTRIBUTESUBJECTALTNAME2
      

有关此设置的进一步指导请参见 here。

使用 PSPKIAudit 检查高风险设置

该 PSPKIAudit 工具可帮助你审计 PKI 基础设施。要使用 PSPKIAudit，只需从 GitHub 下载该工具，导入模块并运行 Invoke-PKIAudit 命令。该过程会先从 Active Directory 枚举证书颁发机构（Certificate Authority），然后查询其部分默认选项。

下面是几张截图，展示该工具的输出结果。输出结果揭示了配置错误的证书以及 CA 上的配置错误。如果 PSPKIAudit 检测到本文未涵盖的任何配置错误，请查看 SpecterOps paper 以获取修复建议。

结论

我预计针对 Active Directory Certificate Services 的攻击数量会不断增加。事实上，自 SpecterOps 论文发布以来，已经出现了带有 PetitPotam 且使用 ADCS NTLM Relaying 的攻击；同时，SpecterOps 还将在 BlackHat 2021 发布 ForgeCert，证书界的“金票（Golden Ticket）”。因此，迫切需要检查你们环境中的配置错误，并尽快加以修复，然后定期重复这一过程。

要实现端到端保护，请考虑 Netwrix Active Directory security solution。它将帮助您：

• 通过深入的风险评估，主动识别安全漏洞。
• 最大限度地减少昂贵的停机时间和业务中断。
• 及时发现甚至是高级威胁，并迅速做出响应。