写在最前

如果你是信息安全爱好者，如果你想考一些证书来提升自己的能力，那么欢迎大家来我的 Discord 频道 Northern Bay。邀请链接在这里：

https://discord.gg/9XvvuFq9Wb

我会提供备考过程中尽可能多的帮助，并分享学习和实践过程中的资源和心得，大家一起进步，一起 NB~

---

背景

在过去的两篇文章当中：

Active Directory 02 - Windows Kerberos Authentication（Kerberos 协议鉴权）

Active Directory 03 - Delegation（委派），MS-SFU 规范以及 Protocol Transition

我们已经讨论了整个 Kerberos 鉴权的过程，以及 Delegation 涉及的各种概念。

首先，我们稍微回顾一下 Active Directory 02 篇中讲到的 TGS 的内容以及 S4U2Proxy 协议的交互过程，然后展开今天的主题：Bronze Bit Attack (CVE-2020-17049)。

回顾

使用同样的示例图片，我们回顾一下当用户进行 TGS_REQ 请求之后，KDC 返回的 TGS 的特性，以及包含的内容。

TGS

1. 用户名（这张 TGS 是给谁的）；
2. 用户可解密部分，使用 logon session key（紫色） 加密；
3. 用户不可解密部分，使用 服务 Key（绿色） 加密；

重要信息

• Service Ticket 是用 服务 Key（绿色） 加密的；
• TGS 票据中 Forwardable 这个属性的值，是接下来需要关注的

S4U2Proxy 过程

回顾了 TGS_REQ 的过程，在前进到 Bronze Bit Attack 之前，还必须回顾一下一个服务使用 S4U2Proxy 协议的过程。

上图中，Service 1 被配置成 Constrained Delegation，目标是 Service 2，并且用户已经访问了 Service 1。Service 1 现在持有用户的 Service Ticket。

步骤说明：

1. Service 1 将用户的 Service Ticket 以及自己的 TGT 发送给 KDC，代表用户申请 Service 2 的 TGS；
2. KDC 校验 Service 1 发送来的数据，校验通过，发送用户的 Service Ticket（用于访问Service 2） 给 Service 1；
3. Service 1 代表用户向 Service 2 发起 Application Request（AP_REQ），发送刚才获取的 TGS；
4. Service 1 现在可以访问和使用 Service 2；

关注加粗的第 2 步。

• 在 Service 1 发送用户的 Service Ticket 给KDC 之后，KDC 会使用 服务 Key（绿色）（记得 KDC 会保存域中任何主体的 Key）解密 Service Ticket，检查 Forwardable 属性是否为 1。
• 如果为 1，则返回用户可以访问 Service 2 的 TGS 给 Service 1；如果为 0，校验失败，KDC 报错，Service 1 无法获得 Service 2 的访问权限。

现在我们来好好看一下 Forwardable 属性。

Forwardable 属性

顾名思义，这个属性确定了当前 TGS 是否可以从一个主体，被发送到另一个主体使用。

这里，不得不再说一下 Constrained Delegation 的保护机制。

Constrained Delegation 保护机制

在继续之前，我们必须了解 Constrained Delegation 中（非 Resource-Based Constrained Delegation）的保护机制，来限制服务对于用户账户的 impersonation。

这个保护机制是这样的：

如果一个服务被设置成 Constrained Delegation without Protocol Transition，这个服务代表用户（非 Kerberos 鉴权）在向 KDC 申请后端服务使用权的时候，KDC 会返回 TGS，但是会将这张 TGS 的 Forwardable 属性设置为 0。那么，之后前端服务在使用 S4U2Proxy 协议申请第二服务的 TGS 时，KDC 将报错，拒绝鉴权。

这就是 without Protocol Transition 选项，是如何限制一个服务 impersonate 任何用户的。

再进一步用例子解释一下。

在我的 E-Corp Lab 中，Web03 服务被设置成 Constrained Delegation without Protocol Transition，目标是 SQL03 服务。域中有一个 apachesvc03 账户，将被设置成 Web03 的本地管理员。

配置如下。

添加 Web Admins 组。

将 apachesvc03 账户添加到 Web Admins组。

到 Web03 机器，将 Web Admins组 添加到本地管理员组。

假设我们拿下了 apachesvc03 账户。由于他是 Web03 服务的管理员，我们可以导出 Web03 机器的 服务 Key（绿色）（AES 以及 NTLM）。

接下来，我们要 impersonate Domain Admin 用户 mecorp 来拿下 SQL03。

由于我们配置 Web03 为 Constrained Delegation without Protocol Transition，也就是说，mecorp 必须以 Kerberos 协议先和 Web03 鉴权，Web03 才能通过 S4U2Proxy 协议向 KDC 申请 SQL03 的使用权。

现在，如果直接使用 getST 来申请 mecorp 对于 SQL03 的使用权，就会报错。

那么，如果我们将 Web03 配置成 Constrained Delegation with Protocol Transition，也就是说 mecorp 账户无需使用 Kerberos 协议与 Web03 鉴权。

那么使用 getST 就可以顺利获得 mecorp 对于 SQL03 的 Service Ticket（ccache）。

看过了 Constrained Delegation 的保护机制，说一下为什么第一次请求 mecorp 账户的 Service Ticket 会报错。就是由于 Constrained Delegation without Protocol Transition 的设置，使 Web03 在使用 S4U2Self 协议向 KDC 请求 mecorp 对于自身的 TGS 时，KDC 将会限制返回的 TGS Forwardable 属性，将其设置为了 0。那么，Web03 拿着这张 Forwardable 属性为 0 的 Service Ticket，再代表 mecorp 用户向 KDC 申请 SQL03 的使用权时，KDC 就会报错。

因此，Forwardable 属性就可以这么简单理解。

该属性值为 1，则可以发送到 KDC 做后方服务的鉴权。如果值是 0，KDC 则会报错，并拒绝鉴权。

Bronze Bit Attack（CVE-2020-17049）

上面的回顾环节，我们可以知道：

1. Constrained Delegation 在使用 S4U2Self 环节，可能会获取到 Forwardable 属性为 0 的 Service Ticket；这将无法继续使用 S4U2Proxy 协议代表用户向 KDC 申请后方服务的使用权；
2. S4U2Self 协议返回的 Service Ticket，是用 服务 Key（绿色） 加密的；
3. KDC 在 S4U2Proxy 协议的交互过程中，会根据 Forwardable 属性，决定是否给前端服务返回后方服务的 Service Ticket；

我们考虑一个场景。如果你拿下了一个 Constrained Delegation 的前端服务，并获得了这个服务的 服务 Key（绿色）。那么，是不是可以：

1. 前端服务先使用 S4U2Self 协议，向 KDC 拿到一张用户对于自身的 Service Ticket；
2. 使用获取的 服务 Key（绿色） 解密 Service Ticket，将 Forwardable 属性强制改为 1；
3. 然后使用这张 Service Ticket，代表任意用户，向 KDC 申请后端服务的使用权；
4. KDC 看到这张 Service Ticket 的 Forwardable 属性为 1，就返回了可用的后端服务 Service Ticket；
5. 前端服务就可以用这张 Service Ticket，访问后端服务了；

这就是 Bronze Bit Attack 的基本原理。

Bronze Bit Attack 的影响

Bronze Bit Attack 使 Active Directory 的另外两大保护机制失去了作用。

Account is sensitive and cannot be delegated

Active Directory 对于敏感账户，可以勾选这个选项，让委派对于其失效。比如，Domain Admin 一般都会被设置成 Account is sensitive and cannot be delegated。

那么前端服务在使用 S4U2Self 申请 Domain Admin 用户对于自身的 Service Ticket 时（无论 with Protocol Transition 或者 without Protocol Transition），KDC 都会返回 Forwardable 为 0 的 Service Ticket。

Protected Users Group

Active Directory 对于敏感账户，可以将其加入 Protected Users Group，让委派对于其失效。比如，可以将 Domain
Admin 账户加入到该组。

那么前端服务在使用 S4U2Self 申请 Domain Admin 用户对于自身的 Service Ticket 时（无论 with Protocol Transition 或者 without Protocol Transition），KDC 都会返回 Forwardable 为 0 的 Service Ticket。

总结

这篇文章我们讲了 Bronze Bit Attack 的基本原理。在未打上补丁 November 10, 2020—KB4586793 (OS Build 17763.1577)的域环境中，S4U2Self 及 S4U2Proxy 协议成了被利用的对象。

下一篇文章，将进入实践环节。了解一下整个 Bronze Bit Attack 的链路。

参考链接

• https://www.netspi.com/blog/technical/network-penetration-testing/cve-2020-17049-kerberos-bronze-bit-theory/
• https://docs.oracle.com/cd/E19253-01/816-4557/refer-123456/index.html
• https://support.microsoft.com/en-us/topic/november-10-2020-kb4586793-os-build-17763-1577-expired-e6a24f90-5659-8b80-5a50-8752de3d90b7