原创 kalpa 2021-11-27 14:53
本文介绍了kerberos中的委派相关原理
介绍
Kerberos 协议里实现了几种委派，委派允许服务模拟客户端用户与第二个服务进行交互，并具有客户端本身的特权和权限。
委派分为：
无约束委派
约束委派
RBCD（基于资源的约束委派）
在本文中将重点了解不同类型的委派是如何工作的，包括一些特殊情况。还将介绍一些可以利用这些机制来利用域中的权限提升或设置持久性的场景。
在开始解释之前，假设大家已经了解 Kerberos 的基本概念。但如果像 TGT、TGS、KDC 或 Golden ticket 这样的词听起来还不太熟的话，那么我建议大家先去阅读本系列的第一章“ kerberos工作原理 ” 或任何相关的 Kerberos 资料。
进入正题。
服务、用户和计算机
首先，因为 Kerberos 为用户提供了一种针对域的服务进行身份验证的方法，并且委派是关于与服务交互的用户，这些服务又与其他服务交互，因此逻辑的第一个步骤是提供服务的定义、用户和它们之间的联系。
用户
通过 Microsoft 官方文档我们得知；用户是由Active Directory 中的用户帐户（或其子类）表示的代理。在 Active Directory 域中，可以找到不同类型的用户帐户：
普通用户帐户，可能是：
由人用来执行他们的日常任务。
用于仅执行特定任务，例如执行备份恢复。
计算机帐户，由域中的机器使用。这些可以被我们识别，因为它们的名称在 Active Directory 数据库中以“$”结尾。
从 Active Directory 的角度来看，计算机是用户，更具体地说，计算机是用户的一个子类。
计算机账户：
服务
一个服务：
服务委派
Anti-Delegation 措施
在后面的内容中，我们将假设委派对于不受委派保护的用户是无效的，所以为了清晰起见，示例会避免这个。
Protected Users Security Group
无约束委派（Unconstrained Delegation）
无约束委派是最简单的委派类型，它允许服务无限制地模拟任何经过身份验证的用户。在这种类型的委派中，服务为客户端用户获取一个有效的 TGT，这相当于成为 Kerberos 世界中（以及域中）的那个用户。
该服务如何为客户端用户获取 TGT？：
客户端将 TGT 发送到服务。
当客户端用户为无约束委派活动的服务请求 TGS 时，KDC 在 TGS 中包含一个（客户端用户的）TGT。
具体来说，它包含在使用服务所有者密钥加密的票据的部分中，所以在接收到 TGS 后，它可以访问客户端 TGT。
KDC 如何知道何时将 TGT 包含在 TGS 中？：
如果为目标服务的所有者设置了 TrustedForDelegation（或ADS_UF_TRUSTED_FOR_DELEGATION）标志，KDC将包含TGT。此标志存储在Active Directory用户帐户的“用户帐户控制”属性中。
还要注意注意的是，为了修改用户的 TrustedForDelegation 标志，需要在域控制器上拥有SeEnableDelegationPrivilege权限。
如果委派的目标用户由于受保护用户组或 NotDelegate 标志而受到委派保护，则委派将不起作用。
SeEnableDelegationPrivilege
示例：
下图展示了无约束委派中遵循的流程（为清晰起见，我们假设 User1 不受受保护用户或 NotDelegated 的委派保护，不然委派将失败）：
在这种情况下：
攻击者如何利用：
有几种可能的情况：
约束委派和 RBCD
除了无约束委派，还有两种委派：
约束委派
RBCD（基于资源的约束委派）（在 Windows Server 2012 中引入）
在任何这些类型中，委派仅限于一些列入白名单的第三方服务。
Kerberos 如何创建服务白名单：
Kerberos 本身无法创建特殊票据来为特定的服务组实现委派。出于这个原因，微软实现了2个 Kerberos 扩展，允许它获得这种所需的行为：
S4U2Proxy（用户代理服务）
S4U2Self（用户自我服务）
S4U2代理：
什么是 S4U2Proxy？
S4U2Proxy 是一个扩展，它允许服务使用客户端用户发送的 TGS 来代表客户端用户从 KDC 为第三个服务获取新的 TGS。
KDC 如何知道用户/服务是否可以使用客户端的 TGS 为第三个服务订购 TGS ？
KDC 必须检查 2 个列表：
一方面，每个用户都有一个可以为哪些服务订购 TGS 的列表。此列表存储在用户帐户的 msDS-AllowedToDelegateTo 属性中。要修改此属性，需要在域控制器中具有 SeEnableDelegationPrivilege 权限。这是在约束委派中使用的列表。
另一方面，每个用户都有一个允许向TGS请求其任何服务的其他用户列表，此列表存储在 msDS-AllowedToActOnBehalfOfOtherIdentity 属性中。用户自己可以根据需要编辑自己的允许用户列表。这是 RBCD 中使用的列表。
所以 KDC 将检查以下条件以确定是否可以应用委派：
（ 在 RBCD 的情况下，发送的TGS不需要是可转发的 ）
TGS does not need to be forwardable
此外，如果用户可以为相同的目标服务应用约束委派和RBCD，则约束委派将优先；这意味着在这种情况下，如果发送的 TGS 无法转发，那么甚至不去尝试应用 RBCD, S4U2Proxy 就会失败。
这里有一个奇怪的地方是 S4U2Proxy 返回的 TGS，始终是可转发的。
S4U2Proxy 在约束委派中的例子：
为了阐明 S4U2Proxy 的使用，示例展示了通过应用约束委派解决委派的情况（为清晰起见，我们假设 User1 不受受保护用户组或 NotDelegated 的委派保护，不然我们的委派将失败）：
在这个例子中：
User1 将 TGS 发送到 ServiceZ。
UserZ 拥有的 ServiceZ 使用此 TGS 代表 User1 向 KDC 请求 ServiceX 的 TGS 。
KDC 检查：
ServiceX 被列在 UserZ 中的 msDS-AllowedToDelegateTo 是否为 yes。
发送的 TGS 是否是可转发的，若是，则可以应用约束委派。
KDC 向 ServiceZ 返回 TGS，以代表 User1 与 ServiceX 交互。
ServiceZ 通过模拟 User1 使用新的 TGS 与 ServiceX 交互。
S4U2Proxy 在RBCD中的例子：
为了阐明 S4U2Proxy 的使用，示例展示了通过应用 RBCD 解决委派的情况（为清晰起见，我们假设 User1 不受受保护用户组或 NotDelegated 的委派保护，不然我们的委派将失败）：
在这个例子中：
扩展：
使用 TGS 有一个有趣的技巧：只需更改目标服务名称，就可以为同一用户的任何服务使用相同的 TGS。
to use the same TGS for any service of the same user
这是因为：
服务名称写在票据的明文部分，任何人都可以修改。
同一用户的所有服务共享相同的 Kerberos 密钥，因此任何服务都可以正确解密同一用户的另一个服务的 TGS。
此技巧可用于绕过受约束委派使用的服务的白名单 ( msDS-AllowedToDelegateTo )。
示例：
在这个例子中：
我们要注意这不是常规服务的正常操作过程，因为几乎没有服务会编辑 TGS 的服务名称来和其他服务联系，这种行为是攻击者的典型操作，攻击者试图使用这个技巧来绕过 KDC 施加的限制。
S4U2Self：
S4U2Self 的目的是什么？
S4U2Self 的目的是允许对不支持 Kerberos 身份验证的服务使用委派，所以无法从客户端用户获取 TGS。
为了绕过这个限制，S4U2Self 允许服务代表另一个用户为自己请求 KDC 的 TGS；这也称为协议转换。
任何用户都可以使用 S4U2Self ？
不是。实际上，KDC 会根据用户帐户的某些特征（例如帐户的服务和 TrustedToAuthForDelegation 标志）对 S4U2Self 请求做出不同的响应。
TrustedToAuthForDelegation（或 ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION）标志被包含在 User-Account-Control 用户帐户的属性，要修改此标志，需要在域控制器中具有 SeEnableDelegationPrivilege 权限。
User-Account-Control
为了应用 S4U2Self，KDC 将遵循以下规则：
an incorrect service name
S4U2Self 示例：
示例展示了 S4U2Self 扩展的使用（为清晰起见，我们假设 User1 不受受保护用户组或 NotDelegated 的委派保护，否则 KDC 将返回不可转发的TGS）：
在这个例子中：
S4U2Self 和 S4U2Proxy 一起使用的例子：
这个示例展示了 S4U2Self 和 S4U2Proxy 共同使用时方式，在约束委派下（为清晰起见，我们假设User1不受受保护用户组或NotDelegated 的委派保护，否则委派将失败）：
在这个例子中：
下面这个示例展示了 S4U2Self 和 S4U2Proxy 共同使用时方式，在RBCD下（为清晰起见，我们假设User1不受受保护用户组或NotDelegated 的委派保护，否则委派将失败）：
在这个例子中：
攻击者如何利用约束委派：
有几种可能的情况：
攻击者如何利用RBCD：
如果攻击者能够攻击成功并利用名为 UserX 的另一个帐户的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性中列出的帐户 UserZ，则可以通过模拟链接使用 S4U2Self 和 S4U2Proxy 来访问 UserX 的服务。
以下是此场景的示例，展示了 UserZ 使用 S4U2Self 和 S4U2Proxy 通过模拟其所有者 UserX 与服务 ServiceX 交互（我们为了演示方便，假设 UserX 不受受保护用户组或NotDelegated 的委派保护）：
在这个例子中：
ServiceZ 的 所有者UserZ（攻击者），代表 UserX (S4U2Self) 为 ServiceZ 请求一个TGS。
KDC 检查：
UserZ 是否是任何服务的所有者（yes）。
TrustedToAuthForDelegation 标志设置是否为 UserZ 帐户（yes）。
KDC 代表 UserX 为 ServiceZ 返回一个不可转发的 TGS 给 UserZ。
UserZ 使用一个新的不可转发的TGS，代表 UserX 为 ServiceX 订购另一个 TGS（S4U2Proxy）。
KDC 检查：
ServiceX 被列在 UserZ 中的 msDS-AllowedToDelegateTo 是否为NO，若是，则不能应用受约束的委派。
如果 UserZ 列在 UserX 的 msDS-AllowedToActOnBehalfOfOtherIdentity 中，则成为 ServiceX的所有者（yes）；可以应用RBCD。
KDC 将可转发的 TGS 返回给 ServiceZ 以代表 UserX 与 ServiceX 交互。
UserZ 通过模拟 UserX 使用新的 TGS 与ServiceX 交互。
还有一个可能性能作为一种持久化的方式；就是将RBCD 从任意用户配置到krbtgt帐户，然后这些任意用户将能够为任何用户生成 krbtgt 服务的TGS ，这意味着为域中的任何用户生成 TGT（因为 TGT 只是krbtgt服务的TGS ），类似于 Golden Ticket 攻击。
configure RBCD from arbitrary users to the krbtgt account
END
从此系列的文章可以看出，Kerberos具有巨大的攻击面，委派也具有三种不同的类型，在实战中，其中一些特性可能决定着入侵的成败，所以学习其中的原理非常重要。
在下一篇文章中，我会展示实际的委派攻击方式。
谢谢！
