MS14-068 权限提升漏洞域内网渗透 背景以及漏洞原理介绍 以及漏洞抓包分析整个过程详解 涉及到Kerberos协议票据认证过程

目录

涉及到得协议-Kerberos

漏洞背景

漏洞原理

漏洞复现

1.MS14-068权限提升

2.漏洞抓包分析

(1)AS-REQ

(2)AS-REP

(3)TGS-REQ

(4)TGS-REP

(5)AP-REQ&AP-REP

漏洞预防和修复

关于工具 有空会更新连接上来

涉及到得协议-Kerberos

域(内网)渗透之:Kerberos协议场景认证过程详解&&AS-REQ以及AS-REP认证过程详解 内网渗透必掌握知识-CSDN博客

漏洞背景

• 2014年11月19日，微软发布11月份安全补丁更新

  • 其中补丁KB3011780引起了人们的注意，这是一个域内权限提升漏洞，

  • 该漏洞允许安全研究员在仅有一个普通域账户的情况下将权限提升为域管理员，危害极大！

    • 微软将该漏洞命名为MS14-068(CVE-2014-6324)

漏洞原理

• 该漏洞产生的原因是KDC无法正确检查ST中PAC的有效签名

  • 导致用户可以自己构造一张高权限PAC并通过校验。

  • PAC包含两个数字签名：

    • 一个使用服务的Hash（PAC_SERVER CHECKSUM）进行签名；

    • 另一个使用krbtgt的Hash(PAC PRIVSVR CHECKSUM）进行签名。

  • 这两个签名设计的初衷是要用到HMAC系列的checksum算法

    • 也就是必须要有key的参与，这里的key 是krbtgt的Hash和服务的Hash

    • 而安全研究员没有krbtgt的Hash和服务的Hash，自然就没有办法生成有效的签名。

• 由于该签名在实现的时候允许使用所有的checksum算法，包括MD5，因此就不需要key的参与了。

  • 此时我们只需要将 PAC用MD5生成新的校验和。

  • 这意味着安全研究员可以随意更改PAC的内容

  • 更改完之后再用MD5生成一个服务检验和与KDC校验和来通过KDC的校验。

漏洞复现

实验环境如下：

• 域内主机：Win7（192.168.1.121）。

• 域控：Server2008（192.168.1.88）。

• 域用户：test --- 环境自己搭建可任意创建一个普通用户

• 域用户密码：321@qq.com

• 域：xie.com

• 域内主机win7权限 该机器上登陆了普通用户hack

  • 提升这个hack用户到管理员权限

1.MS14-068权限提升

• 首先查看当前用户hack的SID

  • 然后在Win7 机器上执行如下命令进行漏洞利用。

MS14-068.exe -u hack@xie.com -p 321@qq.com -s S-1-5-21-1919879345-2108362463-108218295-1103 -d 192.168.1.88

• 参数含义如下

  

  用户名 SID ======== ============================================= xie\hack S-1-5-21-1919879345-2108362463-108218295-1103

  查询sid 用户
  whoami /all

  查询sid 用户 whoami /all
  
  -u：指定域用户名，这里是hack@xie.com
  
  -p：指定域密码，域用户hack的密码
  
  为:321@qq.com
  
  -s：指定域用户的SID查询的内容。
  
  -d：指定域控，域控的I为192.168.1.88。

• 命令运行成功后，会在当前目录生成 .ccache 格式的票据

  MS14-068.exe -u hack@xie.com -p 321@qq.com -s S-1-5-21-1919879345-2108362463-108218295-1103 -d 192.168.1.88

  

• 然后使用mimikatz 执行如下命令导入上一步生成的票据.

  #删除当前缓存的Kerberos票据
  kerberos::purge
  #导入指定路径的票据
  kerberos::ptc C:\users\hack\Desktop\TGT_hack@xie.com.ccache

使用mimikatz导入票据

• 可以看到没导入票据之前是无法访问域控的，导入了票据后就可以访问域控了。

2.漏洞抓包分析

• 对以上过程使用Wireshark进行抓包分析，过滤出与Kerberos协议相关的包.

  • 访问域控磁盘

  • dir \\192.168.1.88\c$

    • wireshark 64位 win 版本下载地址

    • https://2.na.dl.wireshark.org/win64/all-versions/?C=M;O=A

图5-5票据导入前后访问域控对比

• ip.src == 192.168.1.121

• ip.addr == 192.168.1.121

• ip.addr == 192.168.1.121 and kerberos

图5-6Wireshark抓包分析

(1)AS-REQ

图5-7所示是第1个AS-REQ包，重点查看include-pac的值，可以看到是True。

• 注意：AS-REQ包中include-pac的值可以是True或False

  • 这是微软规定的，不属于漏洞。

  • KDC根据include的值来确定返回的票据中是否需要携带PAC。

(2)AS-REP

• 在第2个AS-REP包中，KDC 返回的TGT是不携带PAC的，以59cba开头的cipher加密部分即是TGT.

  

(3)TGS-REQ

• 这个阶段使用了两个函数来实现这个过程。

  • 首先，通过build pac函数构建PAC。

  • 然后，通过build_tgs_req 函数构造TGS-REQ包

• 如下是build_pac函数源代码。

  • 该函数中的chksum1和chksum2是PAC_SERVER CHECKSUM校验和与PAC_PRIVSVR_CHECKSUM校验和。

  • server_key[0]和 kdc_key[0]的值都

    • 为：RSA_MD5，server_key[1]和kdc_key[1]的值都为None

• 我们跟踪一下checksum函数，当cksumtype的值为RSA_MD5时，直接返回data 参数MD5的Hash。

• 我们再来看看build_pac 是如何构建高权限账户的，利用脚本通过构造高权限组的SID加入GroupIds中，从而伪造高权限PAC。

• 如下是一些常见用户的RID:

  • 域用户（513）；

  • 域管理员（512）；

  • 架构管理员（518）；

  • 企业管理员（519）；

  • 组策略创建者所有者（520）。

• 现在已经伪造了高权限的PAC，并且伪造了校验和。

  • 但还有一个问题，可以看到PAC是包含在TGT中的

  • 而TGT又是被 krbtgt的密码Hash加密的

  • 我们没有用户krbtgt 的密码Hash

  • 如何才能将PAC放在TGT中呢

• 发现在padata中已经声明了不包含PAC，因此PAC不用放在TGT中。

  

  • 但是对比正常的TGS-REQ包，发现req-body多了一个enc-authorization-data数据

  • 于是猜想 PAC可能放在enc-authorization-data 数据中

AS-REP

TGS-REQ

• 查看利用脚本源代码，发现确实在req-body AS-REP 回复包body

  • 中加了一个 authorization_data 参数，authorization_data参数的值为enc_ad。

  • 仔细查看enc_ad 的构成，发现是由subkey 加密了构造的PAC。

  • subkey 又是由 generate_subkey 函数生成的

  • 跟踪generate_subkey 函数，其作用是生成一串16位的随机数，

• 最后梳理一下：在脚本中首先使用generate_subkey函数生成一串16位的随机数subkey，

  • 然后用这个16位的随机数subkey 对构造的PAC进行加密，

  • 最后将加密后的数据放在req-body 的enc-authorization-data中

  • 发送TGS-REQ包给KDC的TGS服务。

(4)TGS-REP

• KDC的TGS服务收到TGS-REQ后，如何解密req-body 中的enc-authorization-data得到其中的PAC呢？

  

  • KDC收到TGS-REQ后，从padata的ap-req 中获得加密密钥subkey，然后对encauthorization-data进行解密，得到其中的PAC。

• KDC的TGS服务在校验了PAC和TGT后，会发送高权限的ST给客户端

  • ST中的服务为krbtgt，因此该ST也相当于一张高权限的TGT

  • 也就是以411b开头的cipher。

  • 我们使用工具生成的、保存在本地的 TGT_hack@xie.com.ccache就是该票据。

• 使用mimikatz导入该票据后，尝试访问域控的数据包

  

• 主机使用411b开头的TGT请求ST

• KDC的TGS-REP 服务返回了高权限的ST，即以287bd开头的cipher 加密部分

  

(5)AP-REQ&AP-REP

• 客户端使用287bd开头的高权限ST访问域控Server2008.xie.com的CIFS

• 这个是:AP-REQ包与AP-REP包

  

• 可以看到AP-REQ包中的票据是上一步KDC返回的以287bd开头的高权限ST。

漏洞预防和修复

• 对防守方或蓝队来说，如何针对MS14-068漏洞进行预防和修复呢？微软已经发布了该漏洞的补丁程序，可以直接通过Windows自动更新解决以上漏洞。

关于工具 有空会更新连接上来

• 点个赞吧 ~~ 哈哈