Kerberos Bronze Bit攻击(CVE-2020-17049)

原创
2021/02/08 21:37
阅读数 1.2K

Kerberos Bronze Bit攻击(CVE-2020-17049)是国外netspi安全研究员Jake Karnes发现的漏洞

Microsoft在2020年11月10日发布了该漏洞的补丁程序,补丁发布持续到2021年2月9日。以下攻击情形假设域控制器没有这个补丁,攻击者正在发起攻击。

Bronze Bit漏洞启用的攻击是Kerberos委派引起的其他已知攻击的扩展。Bronze Bit漏洞绕过了现有攻击路径的两种可能的缓解措施,从而提高了其有效性和攻击性。攻击者现在可以执行以下操作:

攻击者可以模拟 “受保护用户”组的成员以及 “账户敏感且无法委派”配置的用户。

攻击者可以禁止执行身份验证协议转换的服务,发起攻击。这意味着,如果配置的服务没有“ TrustedToAuthForDelegation”属性(在AD GUI中显示为“信任此用户,仅委派指定的服务(Trust this user for delegation to specified services only)——仅使用Kerberos”),则攻击者可以利用漏洞来获取票据,就和设置了“ TrustedToAuthForDelegation”属性一样。

这个漏洞可以绕过受保护组和设置了"敏感用户,禁止委派"的用户。或者攻击设置了信任该计算机来委派指定的服务器选项===> 仅使用Kerberos

大致的攻击思路如下:

首先攻击者获取了在域内的某台机器作为立足点。并且攻击者获取了域环境里面的服务密码hash,这里我的环境里面,我获取的服务hash是DM1的。
DM1与另一个服务具有受约束的委派信任关系。在我的测试环境里是DM2。此信任关系可以是以下其中一种:把DM1配置为对DM2进行约束委派。也就是说,DM2在DM1的“ AllowedToDelegateTo”列表中。把DM2配置为接受DM1基于资源的约束委派。也就是说,Service1在Service2的“ PrincipalsAllowedToDelegateToAccount”列表中。
接着攻击者通过CVE-2020-17049漏洞来获取DM2的服务票据
攻击者利用此漏洞充当Service1,并获得Kerberos服务票证作为Service2的目标用户。
攻击者冒充目标用户,向Service2提供服务票证。攻击者现在已作为目标用户向Service2进行身份验证,并且可以在目标用户的权限下与Service2进行交互。

以下来自作者文章https://blog.netspi.com/cve-2020-17049-kerberos-bronze-bit-attack/
Bronze Bit漏洞是Impacket框架的延伸。新漏洞利用功能目前正等着pull请求的合并。Impacket内有很多强大的功能,但是我们感兴趣的是getST.py。我们首先回顾一下没有利用漏洞的程序功能。我们从上面提到的步骤4直接跳到攻击路径。假设我们已经获得了Service1的哈希值,Service1与Service2的委派信任关系受限,我们正在寻求以目标用户的身份访问Service2。

可以使用getST.py程序执行S4U交换,以指定用户的身份获得指定服务的服务票据。如果允许Service1执行协议转换(即使用“ TrustedToAuthForDelegation”进行配置),保护用户免受委托,执行过程如下:

攻击者可以利用最终的服务票据,模拟目标用户和Service2进行交互。但是,如果不允许Service1执行协议转换或保护用户免受委托,那么在S4U2self交换中获得的中间服务票据将不可转发,导致S4U2proxy请求失败。

-force-forwardable标识

Bronze Bit漏洞是getST.py的扩展。添加一个新的-force-forwardable标识,可以将其作为命令行参数传递。如果存在-force-forwardable标识,S4U2self交换之后,执行漏洞利用。由KDC在S4U2self交换中返回的服务票据用Service1的长期密钥解密、可转发标志集进行解密,然后重新加密。更改后的票据会附加在S4U2proxy交换中,KDC将作为目标用户返回Service2的服务票据。

绕过限制并准备好服务票据后,攻击者可以模拟目标用户和Service2进行交互

实验环境配置:

域:one.com
域控:dc,IP:192.168.8.155,用户:administrator
域内机器1:dm1,IP:192.168.8.158,用户:user0x1
域内机器2:dm2,IP:192.168.8.156,用户:user0x2

Example Attack #1

一开始在域控制器中对dm1进行设置,设置为仅信任此计算机来委派指定的服务。并且是选择为Kerbberos

接着要为user0x2设置SPN,然后再把它加入到受保护组或者是设置为“敏感用户,不能被委派”

接着我们在dm1中来访问dm2,这个时候是不能访问到dm2的。

按照委派约束的攻击是已经失败了的!和基于资源委派那个把administrator设置了敏感用户不能委派的差不多!

接着需要获取到dm1的hash和AES256-CTS-HMAC-SHA1-96。需要注意的就是dm1的hash格式是需要LM:NTLM这种格式,也就是需要带上空密码的那个

runas.exe /profile /user:dm1\administrator cmd

mimikatz.exe

privilege::debugsekurlsa::ekeys

获得到了必要的条件之后,使用getST.py来进行攻击,一开始不加上-force-forwardable标识,是不能获取到票据的。加上-force-forwardable标识便利用漏洞成功。

python3 getST.py -spn cifs/dm2.one.com -impersonate administrator -hashes -aesKey one.com/dm1

获取到了票据之后,通过mimikatz把票据导入进入到内存。这里我获取了一个cifs的票据

但是使用cifs的票据并不能直接登录控制到dm2的机器。

接着我再导入了一个host票据就可以登录进入到对方的机器了。

Example Attack #2

第二个是基于资源委派的攻击,首先把之前的实验配置都还原。首先删除dm1的委派权限。连接DC,并把dm1配置为“不信任此计算机进行委派”。

编辑dm2计算机对象, 授予user0x1写入权限。当我们直接向据点用户授予权限时,用户通常通过特权组的成员身份获得对一个或多个AD对象的写入权限。用户不一定是域管理员。

这里user0x1已经对dm1具有了写入权限了,那么就可以通过user0x1用户来创建用户。这里我创建一个AServer的账户,并且密码是q123456.

Import-Module .\powermad.ps1

New-MachineAccount -MachineAccount AServer -Password $(ConvertTo-SecureString 'q123456.' -AsPlainText -Force)

接着使用mimikatz获取这个用户的hash值和aes加密值

用PowerShell Active Directory模块检查我们新创建的计算机帐户。由于该模块尚不可用,所以需要安装相应的功能,这里确定了AServer用户已经添加成功。

确认计算机帐户的存在之后,我们可以在dm2和AServer之间建立受约束的委派信任关系。因为user0x1(我们的受控据点帐户)对dm2对象具有写入权限,所以我们可以把AService添加到dm2的PrincipalsAllowedToDelegateToAccount列表中。这将在dm2上建立基于资源的约束委派,并从AService接受约束委派。

Set-ADComputer dm2 -PrincipalsAllowedToDelegateToAccount AService$

Get-ADComputer dm2 -Properties PrincipalsAllowedToDelegateToAccount

python3 getST.py -spn cifs/Service2.test.local -impersonate user0x2 -hashes -aesKey one.com/AService -force-forwardable

接着使用mimikatz把Kerberos缓存导入进内存,就可以访问到dm2服务器了。

接着就可以访问到dm2.one.com了,但是不知道为什么我这里不能通过PsExec来登录进入到dm2。接着在申请到了一个host的服务票据就可以连接了。

本文由 Jen 撰写


本文分享自微信公众号 - 黑白天实验室(li0981jing)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部