dre4merp's blog
归档 标签 分类 关于我 订阅
dre4merp's blog

目录

CVE 2022–26923 漏洞复现及分析

dre4merp avatardre4merp
     约 2312 字   预计阅读 11 分钟 
警告
本文最后更新于 2022-06-02，文中内容可能已过时。
  • 漏洞名称：AD域权限提升漏洞
  • 漏洞编号：CVE-2022–26923
  • 漏洞类型：设计缺陷
  • 漏洞影响：权限提升
  • CVSS评分：3.1 8.8 / 7.7
  • 利用难度：Medium
  • 基础权限：需要

受影响的 Windows 版本：

  • Windows 8.1
  • Windows 10 Version 1607, 1809, 1909, 2004, 20H2, 21H1, 21H2
  • Windows 11
  • Windows Server 2008，2012，2016，2019，2022

官方已经提供了修补程序： https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26923

靶机：Windows Server 2019 Standard 17763.379 攻击机：Windows 7 x64 SP1
exp: https://github.com/ly4k/Certipy

安装过程按默认配置进行，选择企业 CA（独立 CA 虽然也能实现证书颁发，但是并不会泄露域控证书）。

20220519093735
20220519093735.png

20220519094147
20220519094147.png

20220519094335
20220519094335.png

20220519095426
20220519095426.png

20220519095458
20220519095458.png

20220519104948
20220519104948.png

20220519105151
20220519105151.png

20220520175222
20220520175222.png

20220520175245
20220520175245.png

20220520113048
20220520113048.png

20220520113342
20220520113342.png

20220520113519
20220520113519.png

20220520175026
20220520175026.png

20220530152444
20220530152444.png

Active Directory证书服务简称AD CS，是一种域内认证服务，是公钥基础设施PKI的一个实现，通过发行证书提供了文件加密、数字签名、身份验证等功能。其中，证书颁发机构（CA）负责颁发证书。

证书中包含的信息将身份（主体）绑定到公钥/私钥对。然后，应用程序可以在操作中使用密钥对作为用户身份的证明。证书颁发机构 (CA) 负责颁发证书。

证书申请流程大致过程：

  1. 客户端创建公钥/私钥对；
  2. 将公钥与其他信息 (如证书的主题和证书模板名称) 一起放在证书签名请求 (CSR) 消息中，并使用私钥签署；
  3. CA 首先判断用户是否允许进行证书申请，证书模板是否存在以及判断请求内容是否符合证书模板；
  4. 通过审核后，CA 生成含有客户端公钥的证书并使用自己的私钥来签署；
  5. 签署完的证书可以进行查看并使用。

t014391a4ac622482ee
t014391a4ac622482ee.png

默认情况下，域用户可以注册User证书模板，域计算机可以注册Machine证书模板。两个证书模板都允许客户端身份验证。这意味着颁发的证书可以通过PKINIT Kerberos扩展用于针对KDC的身份验证。

两者的主要区别在于申请者身份证明使用的属性不同，User证书模板的身份证明使用用户主体名称(User Principal Name, UPN)，而基于Machine证书模板的机器账户将使用dNSHostName属性作为证明。

20220530154944
20220530154944.png

用户账户的证书申请 | UPN

用户账户根据模板申请证书时，用户账户的UPN将被嵌入到证书中进行识别。当我们使用该证书进行认证时，KDC会尝试将证书中的UPN映射到用户身上。

User证书模板的msPKI-Certificate-Name-Flag属性存在一个CT_FLAG_SUBJECT_ALT_REQUIRE_UPN标志位，用于指示UPN标志

20220530160307
20220530160307.png

根据MS-ADTS (3.1.1.5.1.3 Uniqueness Constraints)，UPN必须具有唯一性。假如我们将win10@winsrv19.com更改成test1@winsrv19.com，系统会提示约束冲突错误，因为test1@winsrv19.com已经被test1使用了。

20220530161900
20220530161900.png

机器账户的证书申请 | dNSHostName

基于Machine证书模板的机器账户进行证书申请时需要借助dNSHostName属性进行验证。CA下发的证书中会嵌入计算机的DNS属性。

dNSHostName不同于userPrincipalName，其并不需要确保唯一性，因为在MS-ADTS (3.1.1.5.1.3 Uniqueness Constraints)中只提到了UPN和SPN的唯一性。

在证书模板的msPKI-Certificate-Name-Flag属性还存在一个CT_FLAG_SUBJECT_ALT_REQUIRE_DNS标志位，其指示CA将从Active Directory中请求者用户对象的DNS属性获得的值添加到已颁发证书的主题备用名称中。

20220530162929
20220530162929.png

通过上面的分析，漏洞点就呼之欲出了：可以通过修改dNSHostName来伪造高权限用户，直接尝试修改dNSHostName测试下。

将dre4merpc$机器账户的dNSHostName更改为win10.winsrv19.com，并没有出现不允许操作，而是出现如下错误：

20220530164234
20220530164234.png

原因是SPN的唯一性，当我们试图将dre4merpc$机器账户的dNSHostName属性更新为win10.winsrv19.com时，域控制器试图更新SPN属性，该属性将被更新为包括RestrictedKrbHost/Win10.winsrv19.com和HOST/Win10.winsrv19.com，这将与域控制器的SPN属性冲突。

因此，通过更新dre4merpc$机器账户的dNSHostName属性，当域控制器也试图更新dre4merpc$机器账户的SPN时，我们间接地造成了约束性违反。

我们注意到，当我们更新dNSHostName时，只有两个值被更新和检查，即RestrictedKrbHost/dre4merpc.winsrv19.com和HOST/dre4merpc.winsrv19.com，其中包含dNSHostName属性值，解决措施就是删除dre4merpc$机器账户中这两个SPN值，在域控同步更新时不造成冲突

20220530164851
20220530164851.png

此时，我们使用dre4merpc$机器账户申请证书时，颁发的证书中将会包含填充篡改后的dNSHostName，即win10.winsrv19.com。dre4merpc$机器账户申请的证书就具备域控的身份了。

https://mp.weixin.qq.com/s/yMTnM9mtisCgN-z2KunTNQ
https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
http://noahblog.360.cn/active-directory-certificate-services-attack-and-exploit/

更新于 2022-06-02
 | 主页