• 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
  • 相关阅读:
    【应试】数据通信与网络
    【应试】操作系统OS
    【笔记】 卷积
    【HDU 5920】 Ugly Problem
    【笔记】位运算
    【洛谷P1378】油滴扩展
    【洛谷 P1120】 小木棍[数据加强版]
    [codeforces]Round #538 (Div. 2) F. Please, another Queries on Array?
    [BZOJ]2563: 阿狸和桃子的游戏
    [BZOJ]4668: 冷战
  • 原文地址:https://www.cnblogs.com/feizianquan/p/11760564.html
Copyright © 2020-2023  润新知