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

 

posted @ 2019-10-29 18:08  紅人  阅读(8932)  评论(4编辑  收藏  举报