Kerberos协议认证流程及安全分析

1. Kerberos协议概述

Kerberos是一种网络身份验证协议，通过密钥加密技术为客户端/服务器应用程序提供身份验证，主要用于域环境下的身份验证。它支持Windows和Linux系统，使用88端口进行认证，464端口进行密码重设。

主要角色

KDC (Kerberos Distribution Center)：密钥分发中心，作为域控制器提供两种服务：
- Authentication Service (AS)
- Ticket-Granting Service (TGS)
- 服务帐户为krbtgt（密码系统随机生成，无法正常登录主机）
Client：客户端，执行需要身份验证的操作
Server：域内提供服务的服务端，每个服务端有唯一的SPN

2. Kerberos认证流程

2.1 客户端与AS的交互 (AS Exchange)

准备阶段：

用户输入账号密码后，客户端对密码进行hash计算（NTLM-Hash）

请求阶段 (KRB_AS_REQ)：

客户端向KDC的AS发送认证请求
请求内容包含：
- Pre-authentication data：用用户NTLM-Hash或AES Key加密的时间戳
- Client name & realm：用户信息
- Server Name：KDC的TGS服务名（不是用户要访问的实际服务名）
- 版本号、消息类型、票据有效时间、是否包含PAC等

响应阶段 (KRB_AS_REP)：

AS验证过程：
- 根据用户名在AD数据库中查找
- 用用户NTLM-Hash解密时间戳
- 验证时间戳是否合法（5分钟内）
验证通过后：
- 生成Login Session Key（登录会话密钥）
- 发送响应包含：
  - 用用户NTLM-Hash加密的Logon Session Key
  - TGT（Ticket Granting Ticket），包含：
    - Logon Session Key
    - TimeStamp
    - 域名
    - PAC（特权属性证书）
    - 用户信息
    - TGT到期时间
    - 整体用krbtgt的密码HASH加密
客户端：
- 用自己的NTLM-Hash解密获得Logon Session Key
- 携带TGT进入TGS认证

2.2 客户端与TGS的交互 (TGS Exchange)

请求阶段 (KRB_TGS_REQ)：

客户端向TGS发送请求，包含：
- TGT（AS认证获得）
- Authentication：用Login Session Key加密的时间戳
- Client name & realm：用户信息
- Server name & realm：实际要访问的服务信息

响应阶段 (KRB_TGS_REP)：

TGS验证过程：
- 用krbtgt密码HASH解密TGT，获得Logon Session Key和PAC
- 用Logon Session Key解密Authenticator验证身份
- 仅验证PAC是否被篡改，不验证用户权限
验证通过后：
- 生成Service Session Key（服务会话密钥）和Ticket
- 发送响应包含：
  - 用Logon Session Key加密的Service Session Key
  - 用服务器密码Hash加密的Ticket，包含：
    - Service Session Key
    - Client name & realm
    - Ticket到期时间
客户端：
- 用Logon Session Key解密获得Service Session Key
- 现在拥有Service Session Key和Ticket，可直接与服务器交互

2.3 客户端与Server的交互 (CS Exchange)

请求阶段：

客户端向服务器发送：
- Ticket
- 用Service Session Key加密的Authentication信息

响应阶段（双向认证）：

服务器：
- 用自己的密码Hash解密Ticket，获取Service Session Key
- 用Service Session Key解密Authentication
- 认证成功后，从Ticket中取出PAC与请求的服务ACL对比，生成访问令牌
双向认证（可选）：
- 客户端设置mutual-required协商选项为True
- 服务器将Authentication中的Timestamp用Service Session Key加密后返回
- 客户端验证Timestamp一致则信任服务器
后续访问：
- 客户端在请求中携带加密的Ticket信息即可，无需重新认证

3. PAC（特权属性证书）

Kerberos最初只验证身份不验证权限，PAC解决了权限问题：

KDC在AS-REQ阶段：
- 从请求中取出cname字段
- 查询AD数据库，找到sAMAccountName匹配的用户
- 用该用户身份生成对应的PAC

4. Kerberos安全问题

4.1 域用户枚举

通过AS-REQ响应判断用户存在性：

响应类型	结果
AS-REP响应	账号存在且开启了"不要求Kerberos预身份验证"选项
KRB-ERROR: PREAUTH-REQUIRED	账号存在未开启"不要求Kerberos预身份验证"
KRB-ERROR: CLIENT-REVOKED	账号存在但被锁定
KRB-ERROR: UNKNOWN-PRINCIPLE	账号不存在

4.2 PTH和PTK攻击

PTH（Pass-the-Hash）：用NTLM Hash发起AS-REQ请求
PTK（Pass-the-Key）：用AES Key发起AS-REQ请求

4.3 黄金票据（Golden Ticket）

伪造TGT进行TGS认证：

需要获取：
- 用户、域、SID信息
- krbtgt的hash值（通常需要域管权限）
特点：
- 可伪造域管账号票据
- 控制整个域
- 跳过AS认证，不受密码修改影响

4.4 白银票据（Silver Ticket）

伪造Server Ticket：

需要获取服务器密码Hash
伪造Ticket参与第三阶段认证

4.5 MS14-068漏洞

原因：KDC无法正确检查PAC中的有效签名
利用方式：
- 使用MD5等算法伪造PAC
- 加入域管SID和组信息
- 提升为域管理员
补丁：KB3011780

4.6 委派攻击

非约束性委派：
- 客户端将TGT发送给service1
- service1可用该TGT访问用户有权限的服务
约束委派：
- 微软为解决非约束委派安全问题引入
- 利用更复杂

5. 防御建议

定期更换krbtgt账户密码
限制域管权限分配
及时安装安全补丁（如MS14-068）
监控异常Kerberos请求
合理配置委派权限
启用Kerberos审计日志

6. 总结

Kerberos协议提供了强大的网络身份验证机制，但其实现中的安全漏洞（如票据伪造、PAC篡改等）也带来了重大安全风险。理解Kerberos协议的详细流程和安全问题，对于域环境的安全防护至关重要。

Kerberos协议认证流程及安全分析 1. Kerberos协议概述 Kerberos是一种网络身份验证协议，通过密钥加密技术为客户端/服务器应用程序提供身份验证，主要用于域环境下的身份验证。它支持Windows和Linux系统，使用88端口进行认证，464端口进行密码重设。主要角色 KDC (Kerberos Distribution Center) ：密钥分发中心，作为域控制器提供两种服务： Authentication Service (AS) Ticket-Granting Service (TGS) 服务帐户为krbtgt（密码系统随机生成，无法正常登录主机） Client ：客户端，执行需要身份验证的操作 Server ：域内提供服务的服务端，每个服务端有唯一的SPN 2. Kerberos认证流程 2.1 客户端与AS的交互 (AS Exchange) 准备阶段：用户输入账号密码后，客户端对密码进行hash计算（NTLM-Hash）请求阶段 (KRB_ AS_ REQ) ：客户端向KDC的AS发送认证请求请求内容包含： Pre-authentication data：用用户NTLM-Hash或AES Key加密的时间戳 Client name & realm：用户信息 Server Name：KDC的TGS服务名（不是用户要访问的实际服务名）版本号、消息类型、票据有效时间、是否包含PAC等响应阶段 (KRB_ AS_ REP) ： AS验证过程：根据用户名在AD数据库中查找用用户NTLM-Hash解密时间戳验证时间戳是否合法（5分钟内）验证通过后：生成Login Session Key（登录会话密钥）发送响应包含：用用户NTLM-Hash加密的Logon Session Key TGT（Ticket Granting Ticket），包含： Logon Session Key TimeStamp 域名 PAC（特权属性证书）用户信息 TGT到期时间整体用krbtgt的密码HASH加密客户端：用自己的NTLM-Hash解密获得Logon Session Key 携带TGT进入TGS认证 2.2 客户端与TGS的交互 (TGS Exchange) 请求阶段 (KRB_ TGS_ REQ) ：客户端向TGS发送请求，包含： TGT（AS认证获得） Authentication：用Login Session Key加密的时间戳 Client name & realm：用户信息 Server name & realm：实际要访问的服务信息响应阶段 (KRB_ TGS_ REP) ： TGS验证过程：用krbtgt密码HASH解密TGT，获得Logon Session Key和PAC 用Logon Session Key解密Authenticator验证身份仅验证PAC是否被篡改，不验证用户权限验证通过后：生成Service Session Key（服务会话密钥）和Ticket 发送响应包含：用Logon Session Key加密的Service Session Key 用服务器密码Hash加密的Ticket，包含： Service Session Key Client name & realm Ticket到期时间客户端：用Logon Session Key解密获得Service Session Key 现在拥有Service Session Key和Ticket，可直接与服务器交互 2.3 客户端与Server的交互 (CS Exchange) 请求阶段：客户端向服务器发送： Ticket 用Service Session Key加密的Authentication信息响应阶段（双向认证）：服务器：用自己的密码Hash解密Ticket，获取Service Session Key 用Service Session Key解密Authentication 认证成功后，从Ticket中取出PAC与请求的服务ACL对比，生成访问令牌双向认证（可选）：客户端设置mutual-required协商选项为True 服务器将Authentication中的Timestamp用Service Session Key加密后返回客户端验证Timestamp一致则信任服务器后续访问：客户端在请求中携带加密的Ticket信息即可，无需重新认证 3. PAC（特权属性证书） Kerberos最初只验证身份不验证权限，PAC解决了权限问题： KDC在AS-REQ阶段：从请求中取出cname字段查询AD数据库，找到sAMAccountName匹配的用户用该用户身份生成对应的PAC 4. Kerberos安全问题 4.1 域用户枚举通过AS-REQ响应判断用户存在性： | 响应类型 | 结果 | |---------|------| | AS-REP响应 | 账号存在且开启了"不要求Kerberos预身份验证"选项 | | KRB-ERROR: PREAUTH-REQUIRED | 账号存在未开启"不要求Kerberos预身份验证" | | KRB-ERROR: CLIENT-REVOKED | 账号存在但被锁定 | | KRB-ERROR: UNKNOWN-PRINCIPLE | 账号不存在 | 4.2 PTH和PTK攻击 PTH（Pass-the-Hash）：用NTLM Hash发起AS-REQ请求 PTK（Pass-the-Key）：用AES Key发起AS-REQ请求 4.3 黄金票据（Golden Ticket）伪造TGT进行TGS认证：需要获取：用户、域、SID信息 krbtgt的hash值（通常需要域管权限）特点：可伪造域管账号票据控制整个域跳过AS认证，不受密码修改影响 4.4 白银票据（Silver Ticket）伪造Server Ticket：需要获取服务器密码Hash 伪造Ticket参与第三阶段认证 4.5 MS14-068漏洞原因：KDC无法正确检查PAC中的有效签名利用方式：使用MD5等算法伪造PAC 加入域管SID和组信息提升为域管理员补丁：KB3011780 4.6 委派攻击非约束性委派：客户端将TGT发送给service1 service1可用该TGT访问用户有权限的服务约束委派：微软为解决非约束委派安全问题引入利用更复杂 5. 防御建议定期更换krbtgt账户密码限制域管权限分配及时安装安全补丁（如MS14-068）监控异常Kerberos请求合理配置委派权限启用Kerberos审计日志 6. 总结 Kerberos协议提供了强大的网络身份验证机制，但其实现中的安全漏洞（如票据伪造、PAC篡改等）也带来了重大安全风险。理解Kerberos协议的详细流程和安全问题，对于域环境的安全防护至关重要。