当前位置: 首页 > 科技观察

CVE-2022–26923漏洞分析

时间:2023-03-13 01:17:44 科技观察

漏洞介绍2022年5月10日,微软发布补丁修复AD域提权漏洞(CVE-2022–26923)。该漏洞是由于申请证书时对AD域计算机账户身份验证不够严格所致。经过身份验证的攻击者可以操纵他们拥有或管理的计算机帐户的属性,伪造DC从ADCS服务器获取DC证书,最终导致普通权限用户提升为域管理员权限。该漏洞于2021年12月14日由安全研究员OliverLyak首次报告给微软,微软在2022年5月的安全更新中对其进行了修补。ADCS身份识别默认情况下,CA允许域用户注册用户模板证书,并允许域计算机注册计算机模板证书。两个证书模板都允许客户端身份验证。这意味着颁发的证书可用于通过PKINITKerberos扩展对KDC进行身份验证。通过对比User和DomainController模板的msPKI-Certificate-Name-Flag属性,我们可以看到User模板包含SUBJECT_ALT_REQUIRE_UPN,DomainController包含SUBJECT_ALT_REQUIRE_DNS。这两个字段分别标识了证书中用户和计算机的身份,被CA用来标识证书的所有者。例如,当我们使用User模板申请证书时,证书中会嵌入用户账号的UPN。进行身份验证时,KDC会尝试将UPN从证书映射到用户。尝试修改用户的UPN属性。如果能修改AD管理员账号的UPN属性,就可以欺骗ADCS获取AD管理员证书。但实际上,DC会保持UPN校验在整个森林中的唯一性。虽然UPN无法伪造,但并不意味着dnsHostName无法伪造。在MS-ADTS(3.1.1.5.1.3唯一约束)文档中,dnsHostName属性未被标识为唯一。其实通过下面的漏洞分析,我们也可以发现这个属性是可以重复的,这也是造成这个漏洞的主要原因。漏洞分析复现成功利用该漏洞需要满足以下必要条件:攻击者获得经过身份验证的普通域用户凭据或计算机帐户凭据AD域已配置ADCS服务机器模板证书可自动申请第一步您需要获取具有已知凭据的计算机帐户。如果没有,您可以使用普通帐户通过Impacket创建一个新的计算机帐户。默认情况下,每个普通用户有权添加10个机器账号。添加机器的权限可以通过编辑组策略来控制。WindowsServer2012以下版本的DC可以通过用户的属性MS-DS-Machine-Account-Quota设置可以添加的计算机账户数。尝试直接修改本机的dnsHostName,提示操作错误(无法更新属性值),但没有显示唯一性错误,因此可以猜测该值可以修改为DC的dnsHostName,但是由于某些限制,比如值的类型不正确或者是因为某些对象的值依赖于这个值,所以无法成功更新和修改到AD。观察用test3账号创建的主机,发现其ACL信息很有意思。虽然是test3创建的计算机账户,但是机器账户的所有者是DomainAdmins账户。机器账户中有几条ACL信息非常有价值,即:验证写入DNS主机名验证写入服务主体名称验证写入计算机属性这证明创建了计算机账户用户账户具有写入权限计算机账户的dnsHostName、servicePrincipalName等属性,因此修改具有ACL权限的dnsHostName属性的值是可行的。创建主机的dnsHostName被普通域用户修改,值修改为不存在的主机名。发现成功。因此,实现该漏洞的关键是如何绕过限制并对其进行修改。将dnsHostName从mc7.moin.com修改为xxx.moin.com时,发现电脑账号的servicePricipalName属性也发生了变化,其中有两个字段包含了新的dnsHostName。可以推测此属性依赖于dnsHostName。查看微软的官方文档https://docs.microsoft.com/en-us/windows/win32/adschema/r-validated-spn发现官方对servicePrincipalName属性的描述是“VerifywritepermissionstoenablecompliancewithcomputerDNShostsNameSPN属性设置”,所以猜测该属性中对应的值包含已有的dnsHostName,尝试删除servicePrincipalName中包含hostHostName的值,或者直接删除servicePrincipalName属性。删除后,通过修改dnsHostName属性值为DC的dnHostName,发现修改成功。现在成功获取一个dnsHostName与域控一致的机器账号。由于在创建账户时指定了账户密码,因此可以利用该账户欺骗ADCS获取域控制器权限证书。该漏洞的主要实现过程可以概括为以下步骤:获取一个已知密码的计算机账号,删除该计算机账号的servicePrincipalName属性或者删除dnsHostName相关的值,修改dnsHostName为DC的dnsHostName,以及最后使用机器账号向ADCS服务器申请模板为“Machine”的证书并保存在本地。这时候拿到的证书其实就是一个有DC权限的证书。使用该证书申请TGT,可以成功获取到域控账号的NTHash,说明证书有效。这表明普通域用户权限已成功提升为域控制器权限。查看ADCS服务器中的证书申请记录,也可以看出ADCS认为颁发的证书是一个DC。跟踪信息当dnsHostName的值被修改时,域控制器上将生成事件ID为5136的目录服务更改日志。其中一个功能是将计算机对象的dNSHostName值修改为DC的名称。同时会生成事件ID为4742的计算机管理审核成功日志,日志信息包括修改后的计算机账号信息和修改后的dnsHostName信息。如果你在使用这个漏洞后需要清理痕迹,这两个日志是最关键的。综上所述,造成该漏洞的主要原因是计算机账户关键属性的ACL设置问题以及ADCS对客户端身份的检查不严格。使用其他字段作为身份认证标志而不使用域中唯一的自动编号字段SID,从安全性上来说是不安全的。该漏洞利用容易,流量特征不明显,检测难度大。同时,获得的AD域证书长期有效,对于AD域的推广和维护具有很高的利用价值。