MS14-068漏洞分析—不安全的PAC-创新互联

这是一个危害较高的漏洞：只需要一个域内的普通用户的账户密码，便可拿到域控的权限

建议看本文章前，先把之前写的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，也就达到漏洞利用的目的。

1. KDC机构对PAC进行验证时，对于PAC尾部的签名算法，理上规定必须是带有Key的签名算法才可以，但实际上却允许任意签名算法，所以只要我们客户端去随便指定一个方便验证通过的签名算法，那么KDC服务器就会使用我们指定的算法来进行签名验证。比如说我们可以规定使用md5算法，将 md5(内容) 来作为签名，这样当KDC接收以后，发现我们在数据包中规定了使用md5算法，那么KDC就会将我们的内容进行md5后与我们的签名进行比对。如此一来我们可以对内容进行伪装。‘
2. PAC没有被放在TGT中，而是放在了TGS_REQ数据包的其它地方。但KDC还是能够正确解析出放在其它地方的PAC信息。KDC会使用subkey，将PAC信息解密并利用我们客户端设定的签名算法验证签名
3. 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元起，快前往官网查看详情吧