MS14-068原理浅析

内网

漏洞简介

影响范围：全版本的Windows服务器

漏洞危害：允许任意域成员提权为域管权限

利用条件：

1
2
3
4
1.域控没有打KB3011780补丁
2.一台域用户的权限
3.域用户的用户名、密码/hash、SID
4.域名和域控的IP

利用工具：

kekeo 下载地址：https://github.com/gentilkiwi/kekeo/

PyKEY 工具包 下载地址：https://github.com/mubix/pykek

Ms14-068.exe 下载地址:https://github.com/abatchy17/WindowsExploits/tree/master/MS14-068

mimikatz 下载地址:https://github.com/gentilkiwi/mimikatz/releases/

msf中的模块 use auxiliary/admin/kerberos/ms14_068_kerberos_checksum

cs中的插件

漏洞原理

主要是由于Kerberos协议中的认证问题。这里对Kerberos协议不作深入探讨。

下图是Kerberos协议的认证流程图

image-20210925103321890

搭配这张图更容易理解

image-20210925103535675

Kerberos认证流程大致是这样

  1. AS_REQ: client向KDC的AS请求AS_REQ，请求时带上自己的凭据：client的hash加密的时间戳以及其他一些信息

  2. AS_REP: AS收到信息，去询问AD是否有这个用户，有就拿出NTLM-hash对AS_REQ请求中加密的时间戳进行解密，解密成功，就会返回用krbtgt hash加密的TGT票据，TGT里面包含PAC，PAC包含client的sid，client所在的组

  3. TGS_REQ: Client凭借TGT票据向KDC中的TGS发起针对特定服务的TGS_REQ请求

  4. TGS_REP: TGS使用krbtgt hash解密，结果正确，返回 Server hash加密的TGS票据（这一步没有验证client有没有访问服务的权限，只要TGT正确，就返回TGS票据）

  5. AP_REQ: Client拿着TGS票据去请求服务

  6. AP_REP: server使用自身的hash解密TGS。解密成功，server会拿着PAC去询问DC，该用户是否具有访问权限，DC拿到PAC后解密，获取client的sid以及所在的组信息，再根据该服务的ACL，判断client是否具有访问server的权限。通过认证后server 将返回最终的AP_REP并与client建立通信 (有些服务并没有验证PAC这一步，这也是白银票据能成功的前提，因为就算拥有用户hash，可以制作TGS，也不能制作PAC，PAC当然也验证不成功，但是有些服务不去验证PAC，这是白银票据成功的前提)

至此，Kerberos协议认证基本结束。只是大概讲一下认证流程，很多细节认证没有讲。

关键来了，第4步中没有验证client是否具有访问server的权限，在上述认证流程中，只要用户的hash正确，就可以拿到TGT，继而拿到TGS去访问服务。就是说上面的认证只解决了“Who am I”的问题，而没有解决 “ What can I do” 的问题

因此微软引进了 PAC

PAC包含Client的User的SID、Group的SID。PAC决定了Client的组属性，即决定了Client的权限PAC为了保证自身的合法性，还包含2个签名，Key为krbtgt的NTLM hash，签名的内容除了User SID、Group SID外，还有其他部分PAC作为TGT的一部分，是加密的，key为krbtgt的NTLM hash。Client向KDC的AS模块发起认证请求，AS返回TGT时，会根据Client所在的组，生成PAC，包含Client的User SID、Group SID，以及用于确保PAC不被篡改的2个签名

PAC 是用来验证 Client 的访问权限的，它会被放在 TGT 里发送给 Client，然后由 Client 发送给 TGS。但也恰恰是这个 PAC 造成了 MS14-068 这个漏洞。

更多关于PAC的介绍参考链接：

https://docs.microsoft.com/en-us/previous-versions/aa302203(v=msdn.10)#security-considerations

该漏洞是位于 kdcsvc.dll 域控制器的密钥分发中心（KDC）服务中的 Windows 漏洞，它允许经过身份验证的用户在其获得的票证 TGT 中插入任意的PAC 。

漏洞三个成因：

  1. KDC对PAC进行验证时，对于PAC尾部的签名算法，虽然原理上规定必须是带有Key的签名算法才可以，但微软在实现上，却允许任意签名算法，只要客户端指定任意签名算法，KDC服务器就会使用指定的算法进行签名验证。因此伪造的任意内容都可以是合法的，直接加上内容的MD5值作为签名即可

  2. PAC没有被放在TGT中，放在其它地方。KDC在仍然能够正确解析出没有放在TGT中的PAC信息，PAC必须是密文，经过Key加密的KDC会从Authenticator中取出来subkey，把PAC信息解密并利用客户端设定的签名算法验证签名

  3. KDC验证缺少PAC的TGT成功后，再验证不在TGT中 的PAC的合法性。如果2个均验证成功，KDC把PAC中的User SID、Group SID取出来，重新使用进行签名，签名算法和密钥与设置inclue-pac标志位为TRUE时一模一样。将新产生的PAC加入到解密后的TGT中，再重新加密制作全新的TGT发送给Client，不是TGS

至此，漏洞的原理大致了解，普通用户可以通过改变 PAC 的 TGT 来伪造票据获得管理员权限。

编写exp脚本的话无非就是按照这个思路，当然，我是废物，不会写exp，这里就画个大饼。

生成一张TGT票据（此时没有伪造的PAC，为了给伪造的PAC腾出位置），伪造PAC，向TGS请求，此时返回的TGS票据（ST）里面就含有伪造的PAC

简单分析到这，以后再补充.

如果哪里有错误，请大佬与我邮箱联系。

Peace