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@[email protected].com -dc-ip 172.16.84.35 -target-ip 172.16.84.35 -debug

# goldenPac.exe
goldenPac.exe walking.com/test:1qaz@[email protected].com

运行脚本：

成功获得域控的system权限shell：