本文主要说明如何针对Kerberos Bronze Bit漏洞(CVE-2020-17049)进行实际利用的过程。在阅读这篇文章之前,我强烈建议大家首先阅读《Bronze Bit攻击理论》这篇文章,以了解这种攻击的根本原因和攻击效果。
值得关注的是,Microsoft在2020年11月10日发布了该漏洞的补丁程序。这个补丁程序的发布将持续到2021年2月9日。以下的攻击场景中假设攻击者在未安装补丁的域控制器环境中进行。
Bronze Bit漏洞攻击是Kerberos委派导致的其他已知攻击的一种扩展方法。此前Elad Shamir和Will Schroeder曾发表过文章,说明了这些攻击方法以及利用条件。而Bronze Bit的漏洞利用则是绕过了现有原始路径的两种潜在缓解措施,从而提高了漏洞利用的有效性和功能性。攻击者现在可以执行以下操作:
1、攻击者可以冒充不允许委派的用户。其中包括Protected Users组的成员,以及任何其他明确配置为“敏感且无法委派”的用户。
2、攻击者可以从不允许执行身份验证协议转换的服务发起攻击。这意味着,如果配置的服务没有TrustedToAuthForDelegation属性(在AD GUI中显示为“信任此用户仅委派指定的服务 - 仅使用Kerberos”),则攻击者可以利用漏洞利用来获取票证,其效果等价于设置了TrustedToAuthForDelegation属性(在AD GUI中显示为“信任此用户仅委派指定的服务 - 使用任何身份验证协议”)的情况。
该漏洞的一般攻击路径如下:
1、攻击者在AD环境中找到立足点;
2、攻击者获取环境中服务的密码哈希。我们将这个服务称为Service1。攻击者可以通过多种方式获取必要的哈希,例如DC Sync攻击、Kerberoasting,甚至可以通过Powermad使用SPN创建新的计算机帐户。
3、Service1与另一个服务具有受约束的委派信任关系。我们将其称为Service2。信任关系可以是下列之一:
(1) Service1配置为执行对Service2的约束委派。也就是说,Service2在Service1的AllowedToDelegateTo列表中。
(2) Service2配置为接受来自Service1的基于资源的约束委派。也就是说,Service1在Service2的PrincipalsAllowedToDelegateToAccount列表中。
i. 如果攻击者对AD中的Service2对象具有写权限(GenericAll、GenericWrite、WriteOwner等),则攻击者可以将Service1添加到Service2的PrincipalsAllowedToDelegateToAccount列表中。这样就不再需要Elad Shamir和Will Schroeder所描述的域管理员特权了。
4、攻击者利用该漏洞仿冒为Service1,并获得Kerberos服务票证作为Service2的目标用户。
5、攻击者冒充目标用户,向Service2提供服务票证。攻击者现在已经作为目标用户向Service2进行身份验证,并可以在目标用户的权限下与Service2进行交互。
我们使用的Bronze Bit漏洞利用,是由SecureAuth的优秀研究人员开发的Impacket框架的扩展。目前已经提交合并请求,期待能作为其中一个新的漏洞利用功能。Impacket中内置了许多出色的功能,但是我们对其中的getST.py程序比较感兴趣。我们先不看漏洞利用,回顾一下之前的步骤。在第4步,我们进入到攻击路径。假设我们已经获得了Service1的哈希值,Service1与Service2的委派信任关系受到限制,