本文主要简单说明 Kerberos 协议的认证过程，然后介绍了 MS14-068 的漏洞原理和利用过程，同时结合了漏洞利用产生的事件日志和攻击流量进行分析。
Kerberos
Kerberos 是 MIT 提出的一种网络身份验证协议，它通过密钥加密技术验证用户或主机的身份。Kerberos 默认使用 UDP 端口88。
Windows 使用 Kerberos 作为其默认身份验证方法。如果将客户端加入 Windows 域，则说明将启用 Kerberos 作为从该客户端到 Windows 域中的服务以及与该域具有信任关系的所有域的身份验证的默认协议。但需要注意的是，如果客户端或服务端或两者都未加入域，Windows 将改为NTLM提供身份验证。
先看看Kerberos的角色功能。
-
Domain Controller (DC)：域控制器。
-
Key Distribution Center (KDC)：秘钥分发中心，默认安装在域控里，包括 AS 和 TGS。
-
Authentication Service (AS)：身份验证服务，用于 KDC 对 Client 认证。
-
Ticket Grantng Service (TGS)：票据授予服务，用于 KDC 对通过 AS 发送给 Client 的 TGT 换取 ST(Service Ticket)。
-
Active Directory (AD)：活动目录，用于存储用户、用户组、域相关的信息。
-
Privilege Attribute Certificate (PAC)：特权属性证书，用于验证是否有服务访问权限。
再来看看看认证流程。
-
AS REQ
客户端用户 Client 向 KDC 发送一条消息 AS REQ 进行预验证，其中消息包含了 Client 密码 HASH 加密的时间戳、Client-info、网络地址等。 -
AS REP
KDC 请求AD查询Client，若存在该用户则用其密码 HASH 解密 AS REQ 中的时间戳，若解密成功且时间戳在5分钟之内，则验证成功。AS 会返回 Sessionkey-AS (经过 Client 密码 HASH 加密)和 TGT (包含经 KRBTGT HASH 加密的 Sessionkey-AS 和时间戳等信息，因此 TGT 无法被 Client 解密解析)。 -
TGS REQ
Client 用自身密码解密 Sessionkey-AS，再用 Sessionkey-AS 加密时间戳和 Client-info 作为其中一部分内容，和 TGT 一起发送给 KDC 中的 TGS 以认购换取 ST 票据。 -
TGS REP
TGS 首先自检是否存在 Client 所请求的服务，若存在，则使用 KRBTGT 密码 HASH 解密 TGT，解密得到 Sessionkey-AS 、时间戳、Client-info。然后再用这个 Sessionkey-AS 解密步骤 3 中的一部分内容，得到第二份时间戳和 Client-info，两者进行比较，有效时间范围，网络地址是否相同。认证成功后，TGS 会生成用 Sessionkey-AS 加密的 Sessionkey-TGS 和 Server 密码 HASH 加密的 Sessionkey-TGS (即 ST 票据)返回给 Client。 -
AP REQ
Client 先用之前本地缓存的 Sessionkey-AS 解密得到 Sessionkey-TGS。当 Client 需要访问 Server 上的服务时，Client 使用 Sessionkey-TGS 加密时间戳等信息，和 ST 一起发送给 Server。 -
AP REP
Server 使用自己密码 HASH 解密 ST 得到 Session-Key TGS，然后再解密得到时间戳等信息，与 ST 的时间戳和 Client-info 等分别进行验证对比。
这里需要提醒的是，一般地，有些服务并不需要 PAC 验证，该服务会接受 TGS 票证中的所有数据，而不与 DC 通信。
PAC
PAC 即 Privilege Attribute Certificate(特权属性证书)，它是 Kerberos 票证的扩展。需要注意的是，Kerberos 以上认证过程说明了客户端是否为真实有效用户，但未声明该用户是否具有访问目标服务的权限，因为在域中不同权限的用户所能访问的资源是不同，而 PAC 解决了访问权限问题。
PAC 包含了用户或组安全标识符 (SID)。当用户在 AD 域中进行身份验证时，域控制器会将此信息添加到 Kerberos 票证中。当用户使用 Kerberos 票证访问其他服务进行身份验证时，可以读取 PAC 来确认其权限级别，而无需联系域控制器来查询该信息。
继续完善上面的认证流程。
-
PAC Validation Request
PAC 是在 AS REQ 后由 KDC 生成的，返回给 Client 的 TGT 包含了 PAC。CLient 与 KDC 完成认证以后，此时需要访问 Server 所提供的某项服务，Sever 会拿着 PAC 去请求 DC 查询 Client 是否有访问权限。 -
PAC Validation Response
DC 对 PAC 进行解密，通过 PAC 中的 SID 判断 Client 的用户组信息、用户权限等信息，然后将结果返回给 Server，Server 再将此信息与域用户请求的服务资源的 ACL 进行对比，最后决定是否给 Client 提供相关的服务。通过认证后 Server 将返回最终的 AP-REP 并与 Client 建立通信。
但需要说明的是，有些服务并不需要 PAC 验证，该服务会接受 TGS 票证中的所有数据，而不与 DC 通信，而银票攻击则也正利用了这个条件。
MS14-068
MS14-068 是位于 kdcsvc.dll 域控制器的 KDC 服务中的漏洞，它允许经过身份验证的用户在其获得的票证 TGT 中伪造插入任意的 PAC 。普通域用户可以通过呈现改变了的 PAC 的 TGT 来伪造票据获得管理员权限。
利用过程
域测试环境：
-
DC
系统：Windows Server 2008 R2 x64
主机名：win08
地址：192.168.1.8
域名：bbk.lab
系统信息：无 KB3011780 补丁 -
域成员机器
系统：Windows 7 x64
主机名：pc
地址：192.168.1.7
域普通账户：user1 -
exp：Pykek工具包的 ms14-068.py 编译后的可执行文件exe
漏洞利用前，收集账户信息，查看当前权限。
使用 exp 在当前目录路径下生成一个高权限的 TGT 票据
mimikatz 清楚内存中票据信息，将 TGT 票据注入到内存。
注入成功，dir查看当前权限，可以看到已经提权成功。
漏洞成因与流量分析
以下通过 exp 结合流量分析和学习 MS14-068 漏洞原理。对 exp 设置断点 debug，并使用大鲨鱼抓包。
这里的参数pac_request为 False，说明在构建 AS REQ 消息时，Client 将向 KDC 申请一张不包含 PAC 票据，这个是微软默认的设计。
查看对应流量，确认include-pac: False。
查看正常 AS REQ 请求流量，两者进行对比。
AS REP 响应，将 KDC 加密的TGT 返回给客户端。
参数tgt_a获取 TGT 票据。
构造 TGS REQ。跟进build_pac函数查看 PAC 构造。
分别提取了 domain_sid、user_id，_build_pac_logon_info构造高权限 SID 以达到提权目的。
该函数将组成员身份声明更改为包含更高特权的组，由于 PAC 包含用户或组 SID，这就使得 AD 域中具有有效 AD 凭据的计算机上的 Client 能够绕过所有已配置资源的 ACL。
往下，关注默认参数server_key=(RSA_MD5,None)、server_key=(RSA_MD5,None)，关注checksum函数，以及参数server_key和kdc_key。
关于 PAC 签名，微软也做了相应的说明。
意思就是 PAC 通过包含两个数字签名(分别为 Server 密码 HASH 与 KDC 密码 HASH)防止 PAC 被伪造。
那么这两个数字签名 PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM 则对应为chksum1和chksum2。
跟进查看checksum函数，server_key[0]和kdc_key[0]指的就是加密方式，指定为 MD5，这里server_key[1]和kdc_key[1]应为 Server 和 KDC 密码 HASH 并都设置了为None。
构造好 PAC 后，将其传入build_tgs_req函数构造 TGS REQ，然后发送给 KDC。
在上图中可以看到前面得到的 TGT 和通过eTYPE-ARCFOUR-HMAC-MD5加密方式的 PAC。
KDC 验证完成以后，返回 TGS REP，其中包含一张新的 TGT，它会将 exp 生成具有高权限的 PAC 包含在其中。
exp 收到上图新的 TGT 后会将其保存为[email protected]文件以方便 Client 导入到内存中使用。
在 Client 上使用 mimikatz 清除内存中现有的 Kerberos 票据，然后将 exp 生成的 TGT 导入到内存中进行提权。尝试连接访问 DC 的共享文件夹，继续抓包。
进行了两次的 TGS REQ 请求，第一次 TGS REQ 请求是使用上面exp生成的高权限 TGT 票据，然后返回了一张 win08.bbk.lab (win08是DC主机名)的 CIFS 服务的 ST 票据。
然后通过 SMB 协议拿着这个 ST 票据请求 CIFS 服务，发起 Session Setup Request(AP REQ)。
最后，返回 Session Setup Response(AP REP)响应。
此时，Client 拥有了 DC 上 CIFS 服务的有效 TGS，并且能够使用它通过 SMB 访问共享文件夹，甚至通过 psexec 远程连接。
日志分析与防御措施
以下是使用伪造 TGT 获取 TGS 以访问 DC 的 c
事件4769显示 [email protected] 使用伪造的 TGT 请求 TGS Kerberos服务票证。
事件4624显示 [email protected] 使用 TGS 服务票证登录到 DC。
事件5140显示 [email protected] 使用 ST 连接到只有管理员有权访问的目标域控制器的 c
事件4672显示 [email protected] 已成功验证（并登录到）只有域管理员才能访问的目标域控制器。
而且，此该用户具有 SeBackupPrivilege、SeRestorePrivilege、SeDebugPrivilege、SeTakeOwnership 等权限，表明该用户具有对此计算机的完全管理员访问权限。说明域控已经沦陷。
防御措施：
-
使用更高版本操作系统，安装补丁(KB3011780)，定期进行安全更新。
-
对域内账户进行控制，禁止使用弱口令，及时、定期修改密码。
-
当确认已被提权成功域控沦陷时，重装域服务。
-
攻击检测：内部流量分析标记
include-pac: False作为特征，结合事件日志研判攻击是否成功。
总结
MS14-068漏洞主要是经过身份验证的域用户向 Kerberos KDC 发送伪造的 Kerberos 票据，票据其中包含了声称该用户是域管理组成员的 PAC。KDC 在处理来自攻击者的请求时不正确地验证伪造的票据签名，从而允许攻击者以域管理员身份访问任何资源。
从接触内网渗透以来，第一次分析 Windows 提权类型的漏洞，收获良多，受益匪浅。MS14-068 虽然是14年的老漏洞，但是放在今天仍然还具有一定的影响，且对该漏洞的处理与防护，也能举一反三应用到其他漏洞上。关于 Kerberos 协议的认证流程和 exp 利用，还有很多细节没深入去挖掘出来，文章篇幅较长，如有错漏还请海涵。
参考
-
Microsoft Security Bulletin MS14-068 - Critical
(https://docs.microsoft.com/en-us/security-updates/securitybulletins/2014/ms14-068) -
Python Kerberos Exploitation Kit
(https://github.com/mubix/pykek)
-
Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources
(https://docs.microsoft.com/en-us/previous-versions/aa302203(v=msdn.10)) -
Digging into MS14-068, Exploitation and Defence
(https://labs.f-secure.com/archive/digging-into-ms14-068-exploitation-and-defence)
猎豹安全中心技术分享频道
长按下方二维码关注我们
原文始发于微信公众号（安全防御）：Kerberos协议之MS14-068分析和防御
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论