Kerberos 笔记

在 Kerberos 协议中，主要有以下三个角色：

• 访问服务的客户端
• 提供服务的服务端
• 用于认证的 KDC

KDC 是一种网络服务，用于向 AD 域内的用户和计算机提供会话票据和临时会话密钥。服务账户为 krbtgt，KDC 作为 AD 域服务的一部分运行在域控制器上。

krbtgt 用户，在创建 AD 时自动创建，密码随即生成，无法正常登陆。

Kerberos 是一种基于票据（Ticket）的认证方式。客户端想要访问某个服务时，需要先购买服务端认可的 ST（Service Ticket）服务票据。购买 ST 需要一张 TGT（Ticket Granting Ticket）认购权证。TGT 和 ST 均是由域空中的 KDC 发放。

因此，认证的流程可以简述为：客户端先向域空认证得到 TGT，然后使用 TGT 获取所需服务的 ST，然后使用 ST 访问对应服务。

Kerberos 使用 TCP/UDP 88 端口进行认证，使用 TCP/UDP 464 端口进行密码重置。

Kerberos 协议有两个基础认证模块——AS_REQ & AS_REP 和 TGS_REQ & TGS_REP，以及微软扩展的两个认证模块 S4U 和 PAC.

S4U 是微软为了实现委派而扩展的模块，分为 S4u2Self 和 S4u2Proxy。

Kerberos 最初设计中只说明了如何证明客户端的真实身份，并没有验证客户端对服务的访问权限。微软为了解决域中不同用户对不同服务的不同权限问题，引入了 PAC（Privilege Attribute Certificate）特权属性证书的概念。

PAC

PAC 包含各种授权信息、附加凭据信息、配置文件和策略信息等。一个正常的 Kerberos 认证流程中，KDC 返回的 TGT 和 ST 都是带有 PAC 的。这样做的好处是在以后对资源的访问中，服务端接收到客户端请求的时候不需要再借助 KDC 提供完整的授权信息来完成对用户的权限判断，只需要根据 PAC 信息直接与本地资源的 ACL 相比较来做出裁决。

PAC 中包含两个数字签名：PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM。PAC_SERVER_CHECKSUM 使用服务密钥签名，PAC_PRIVSVR_CHECKSUM 使用 KDC 密钥进行签名。

在 PAC 数据用于访问控制之前，服务必须检查 PAC_SERVER_CHECKSUM 签名，而 PAC_PRIVSVR_CHECKSUM 为可选项，默认不开启。它用于验证 PAC 是否由 KDC 签发。

KDC 验证 PAC

当服务端收到客户端发来的 AP-REQ 消息时，只能校验 PAC_SERVER_CHECKSUM 签名。

如果要校验 PAC_PRIVSVR_CHECKSUM 签名，服务端需要将客户端发来的 ST 中的 PAC 签名发送给 KDC 进行校验。大部分服务默认没有 KDC 验证 PAC 这一步，因此服务端就无需将 ST 中的 PAC 签名发给 KDC 校验了。这也是白银票据攻击成功的前提。

• 如何开启 KDC 校验 PAC

条件：应用程序具有 SeTcbPrivilege 权限。允许用户账户分配”作为操作系统的一部分“

设置注册表：

• 找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters;
• 添加 ValidateKdcPacSignature 的键值（DWORD），设置为1。该值为 0 时不进行 KDC PAC 校验。

PAC 在 Kerberos 中的优缺点

引入 PAC 后服务端不需要向 KDC 查询授权信息，节约了网络资源。

PAC 是微软特有特性，所以启用了 PAC 的域中不支持装有其他操作系统的服务器。

PAC 的安全性：MS14-068

Kerberos 认证流程

1. AS-REQ

当域内某个用户想要访问域内某个服务时，输入用户名和密码，本机就会向 KDC 的 AS 发送一个 AS-REQ（认证请求），其包含：

• PA-DATA pA-ENC-TIMESTAMP 用户密码 Hash 加密的时间戳
• PA-DATA pA-PAC-REQUEST 说明是否启用 PAC 支持
• include-pac 说明是否包含 PAC
• kdc-options 用于与 KDC 协商设置
• cname 用户名
• realm 域名
• sname 请求的服务（在 AS-REQ 中，sname 始终为 krbtgt）

2. AS-REP

当 KDC 的 AS 接收到客户端发来的 AS-REQ 后，AS 会从 AD 数据库中取出该用户的密钥，然后使用密钥解密请求包中用户 Hash 加密的时间戳，如果解密成功，并且时间戳在有效的范围内，则证明客户端提供的用户密钥正确。KDC 在认证成功后发送 AS-REP 给客户端。其中包括：

• ticket 认购权证票据 TGT（包含一些明文信息）
• enc-part（tricket）TGT 中的加密部分，使用 krbtgt 的密码 Hash 加密的（黄金票据原理）
• enc-part（最外层）Logon Session Key，使用请求用户密码的 Hash 加密的，作为下一阶段的认证密钥

客户端在收到 KDC 的 AS-REP 后，使用用户密钥解密 enc_Logon Session Key（最外层 enc-part）得到 Logon Session Key，并且也获得了 TGT，之后会在本地缓存此 TGT 和 Logon Session Key。

3. TGS-REQ

客户端使用 TGT 发起 TGS-REQ，向 KDC 购买针对制定服务的 ST。其主要包括：

• padata 包含 ap_req、AS-REP 中获取到的 TGT 和 Logon Session Key，可能会有 PA_FOR_USER…
• ap-req 这个是 TGS-REQ 必须携带的部分
• ticket AS-REP 回复包中返回的 TGT
• authenticator 原始 Logon Session Key 加密的时间戳，用于保证会话安全

4. TGS-REP

TGS-REP 中 KDC 不会验证客户端是否有权限访问服务端。只要 TGT 正确，均会返回 ST

KDC 的 TGS 服务接收到 TGS-REQ 后首先使用 krbtgt 密钥解密 TGT 中的加密部分，得到 Logon Session Key 和 PAC 等信息，解密成功则说明该 TGT 是 KDC 颁发的；然后验证 PAC 签名，签名正确说明未被篡改；最后使用 Logon Session Key 解密 authenticator 得到时间戳等信息，如果解密成功，并且票据时间在有效范围内，则验证了会话的安全性。其中包括：

• ticket 即 ST，包含一些明文信息
• enc-part（ticket）用服务的密钥加密
• enc-part（最外层）使用原始 Logon Session Key 加密的，作为下一阶段的认证密钥

客户端受到 KDC 返回的 TGS-REP 消息后，从中取出 ST，准备申请访问服务。

5. AP-REQ

客户端通过缓存的 Logon Session Key 解密 enc_Service Session Key 得到 Service Session Key，同时拿到了 ST。Service Session Key 和 ST 会被客户端缓存。 客户端访问制定服务时，发起 AP-REQ。其中包括：

• ticket 票据
• authenticator Service Session Key 加密的时间戳

6. AP-REP

这一步为可选，当客户端希望验证提供服务的服务端时，服务端返回 AP-REP 消息。其中包括：

• Service Session Key 加密的新时间戳

客户端通过 Service Session Key 解密时间戳验证服务器安全性

S4u2Self & S4u2Proxy 协议

为了在 Kerberos 协议层面对约束性委派进行支持

S4u2Self 可以代表任意用户请求针对自身的 ST，S4u2Proxy 使用此 ST 以用户的名义请求针对其他指定服务的 ST。

S4u2Self 比正常的 TGS-REQ 包多一个 PA-DATA pA-FOR-USER，name 为要模拟的用户，并且 sname 也是请求的服务自身。

S4u2Proxy 比正常的 TGS-REQ 包多一个 additional-tickets，为上一步利用 S4u2Self 请求的 ST。

Kerberos 协议的安全问题

• AS-REQ

  1. Pass The Hash（PTH 哈希传递攻击）

  2. Pass The Key（PTK 密钥传递攻击）

  3. Enum（域用户枚举攻击）

  4. Password Spraying（密码喷洒攻击）

• AS-REP

  5. Golden Ticket（黄金票据传递攻击）

  6. AS-REP Roasting

• TGS-REP

  7. Kerberoasting

  8. 白银票据传递攻击

• S4u2Self & S4u2Proxy 委派攻击

• PAC - MS14-068

1. 由于 AS-REQ 使用的是通过用户 Hash 加密的时间戳，所以导致 PTH
2. AS-REQ 也可能是使用用户密码的 AES Key 加密时间戳，所以导致 PTK
3. AS-REQ 包中的 cname 字段值代表用户名，用户名存在与否，返回的包不一样，因此可以用来枚举用户名。同样可以枚举密码
4. 为了避免针对同一个用户的连续密码猜测导致账户锁定而用固定的密码爆破所有用户名
5. TGT 中加密的部分是用 krbtgt 的密码 Hash 加密的，所以如果获取到了 krbtgt 的 Hash 便可以自己制作 ticket，造成 Golden Ticket 黄金票据传递攻击
6. AS-REP 阶段中，Logon Session Key 是用户密码 Hash 加密的，对于域用户如果设置了“Do not require Kerberos preauthentication”选项。攻击者向域控88端口发送AS-REQ，此时域控不会验证身份便会返回TGT和该用户Hash加密的Logon Session Key。破解成功可以得到用户明文密码，这种攻击称之为 AS-REP Roasting
7. TGS-REP 阶段，由于 ST 是用服务 Hash 加密的，并且用户向 KDC 发起 TGS-REQ 请求时，不管用户对服务有没有访问权限，只要 TGT 正确，KDC 都会返回 ST。对 ST 进行破解可以得到服务的 Hash，造成 Kerberoasting 攻击
8. TGS-REP 阶段，TGS-REP 中的 ST 是使用服务的 Hash 进行加密的，如果拥有服务的 Hash 便可以自己制作 ticket，造成 Silver ticket 白银票据传递攻击