MS14-068漏洞分析—不安全的PAC-创新互联
前言
新闻名称:MS14-068漏洞分析—不安全的PAC-创新互联
转载注明:http://pwwzsj.com/article/dhecpd.html
这是一个危害较高的漏洞:只需要一个域内的普通用户的账户密码,便可拿到域控的权限
成都创新互联公司专注于延平企业网站建设,成都响应式网站建设,商城网站建设。延平网站建设公司,为延平等地区提供建站服务。全流程按需设计,专业设计,全程项目跟踪,成都创新互联公司专业和态度为您提供的服务建议看本文章前,先把之前写的NTLM与kerberos认证体系详解这篇文章看完。
漏洞原因简述利用伪造的高权限的PAC来获取一个带有高权限PAC的TGT。
(关于pac是什么可以看完上面的那个文章)
详细原因在我们的AS_REQ 请求中如果include-pac被置为 true,那么我们的 AS 会在返回的 TGT 中加入 PAC信息,如果我们在 AS_REQ 数据包中,将include-pac被置为 false,那么 AS_REP 返回的 TGT 中就不会包含 PAC
信息。在TGT中没有PAC信息后,我们就可以使用域用户去伪造"恶意"的PAC放入TGS_REQ中,KDC解密PAC后会再次加密到一个新的TGT中并返回给域用户(注意这里KDC返回的是一个TGT并不是一个ticket),此时的TGT中已经携带了“恶意”PAC,也就达到漏洞利用的目的。
- KDC机构对PAC进行验证时,对于PAC尾部的签名算法,理上规定必须是带有Key的签名算法才可以,但实际上却允许任意签名算法,所以只要我们客户端去随便指定一个方便验证通过的签名算法,那么KDC服务器就会使用我们指定的算法来进行签名验证。比如说我们可以规定使用md5算法,将 md5(内容) 来作为签名,这样当KDC接收以后,发现我们在数据包中规定了使用md5算法,那么KDC就会将我们的内容进行md5后与我们的签名进行比对。如此一来我们可以对内容进行伪装。‘
- PAC没有被放在TGT中,而是放在了TGS_REQ数据包的其它地方。但KDC还是能够正确解析出放在其它地方的PAC信息。KDC会使用subkey,将PAC信息解密并利用我们客户端设定的签名算法验证签名
- KDC 验证 (缺少 PAC 的 TGT) 与(不在 TGT 中的 PAC) 这两个成功后,那么会去把 PAC 中的 User SID、Group SID 取出来,重新使用进行签名,签名算法和密钥与设置 inclue-pac 标志位为 TRUE 时一模一样。将新产生的 PAC 加入到解密后的 TGT 中,再重新加密制作全新的 TGT 发送给 Client。(注意这里KDC返回的是一个TGT并不是一个ST)
通过以上流程我们成功获得了一个高权限的TGT。
漏洞演示攻击机:mac
域控:win2008 172.16.84.35
域内普通用户:test/1qaz@WSX
攻击工具: goldenPac
(这个工具最方便,有py与exe两种。是 ms14-068 与 psexec 的结合,可以直接获得一个shell回来)
# goldenPac.py
python3 goldenPac.py walking.com/test:1qaz@WSX@DC.walking.com -dc-ip 172.16.84.35 -target-ip 172.16.84.35 -debug
# goldenPac.exe
goldenPac.exe walking.com/test:1qaz@WSX@DC.walking.com
运行脚本:
成功获得域控的system权限shell:
你是否还在寻找稳定的海外服务器提供商?创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源,准确流量调度确保服务器高可用性,企业级服务器适合批量采购,新人活动首月15元起,快前往官网查看详情吧
新闻名称:MS14-068漏洞分析—不安全的PAC-创新互联
转载注明:http://pwwzsj.com/article/dhecpd.html