ICode9

精准搜索请尝试: 精确搜索
首页 > 系统相关> 文章详细

CVE-2021-42287(Windows域服务权限提升漏洞)

2021-12-16 18:31:53  阅读:132  来源: 互联网

标签:TGS 42287 hash Windows 用户 KDC PAC 服务 CVE


PAC

PAC(Privilege Attribute Certificate),特权属性证书 需要提供User的SID和所在组Group的SID

只看上述的就简单解释并不能很清晰的了解,那么想要知道PAC这个概念,我们首先理一下kerberos的流程

网上很多kerberos如下:

1:用户向KDC发起AS_REQ,请求凭据是用户hash加密的时间戳,KDC使用用户hash进行解密,如果结果正确返回用krbtgt hash加密的TGT票据

2:用户凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求,KDC使用krbtgt hash进行解密,如果结果正确,就返回用服务hash 加密的TGS票据

3:用户拿着TGS票据去请求服务,服务使用自己的hash解密TGS票据。如果解密正确,就允许用户访问。

上面这个流程看起来没错,却忽略一个最重要的因素,那就是用户有没有权限访问该服务,在上面的流程里面,只要用户的hash正确,那么就可以拿到TGT,有了TGT,就可以拿到TGS,有了TGS,就可以访问服务,任何一个用户都可以访问任何服务。

为了解决上面的这个问题,微软引进了PAC,引进PAC之后的kerberos流程变成

1:用户向KDC发起AS_REQ,请求凭据是用户hash加密的时间戳,KDC使用用户hash进行解密,如果结果正确返回用krbtgt hash加密的TGT票据,TGT里面包含PAC,PAC包含用户的sid,用户所在的组。

2:用户凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求,KDC使用krbtgt hash进行解密,如果结果正确,就返回用服务hash 加密的TGS票据(这一步不管用户有没有访问服务的权限,只要TGT正确,就返回TGS票据,这也是kerberoating能利用的原因,任何一个用户,只要hash正确,可以请求域内任何一个服务的TGS票据。

3:用户拿着TGS票据去请求服务,服务使用自己的hash解密TGS票据。如果解密正确,就拿着PAC去KDC那边询问用户有没有访问权限,域控解密PAC。获取用户的sid,以及所在的组,再判断用户是否有访问服务的权限,有访问权限(有些服务并没有验证PAC这一步,这也是白银票据能成功的前提,因为就算拥有用户hash,可以制作TGS,也不能制作PAC,PAC当然也验证不成功,但是有些服务不去验证PAC,这是白银票据成功的前提)就允许用户访问。

特别说明的是,PAC对于用户和服务全程都是透明的。只有KDC能制作和查看PAC。

上述那么一大段,边界骇客总结如下,建议还是先细细的看一遍然后再来看总结:

TGT票据中带PAC,PAC根据AS_REQ和 AS_REP的相关请求和结果生成
票据交换的时候不校验PAC内用户是否有权限访问服务
服务请求的时候才会去校验票据服务是否有权限
任何一个用户,只要hash正确,可以请求域内任何一个服务的TGS票据
漏洞原理
原理:在AD认证的过程中,如果存在一个机器账户,此账户的名称和AD机器名(下面
为test$)去掉$后相同,当我们请求了TGT以后删除此账户,如果利用此TGT
进行正常请求,由于没有这个用户,所以域控无法正确来解密此票据。但是域控有
一个机制,当数据库中未检索到这个账户,会寻找samaccountname为此账户的用
户,此时就可以利用 S4U2self 去请求DC秘钥加密的TS票据。

这里S4U2self 这个概念是:
在TGSREQ & TGSREP阶段,用户通过AS_REP拿到的TGT票据,去向KDC申请特定服务的访问权限,KDC校验TGT票据,如果校验通过的话,会向用户发送一个TGS票据,之后用户再拿着TGS去访问特定的服务。这一阶段,微软引进了两个扩展S4U2SELF和S4U2PROXY。
S4U2self 使得服务可以代表用户获得针对服务自身的kerberos服务票据。这使得服务可以获得用户的授权( 可转发 的用户TGS票据),然后将其用于后期的认证(主要是后期的s4u2proxy),这是为了在用户以不使用 Kerberos 的方式对服务进行身份验证的情况下使用。这里面很重要的一点是服务代表用户获得针对服务自身的kerberos票据这个过程,服务是不需要用户的凭据的

工具:https://github.com/cube0x0/noPac
noPac64.exe scan -domain god.org -user yuchen-pass Admin_123
noPac64.exe -domain god.org -user yuchen-pass Admin_123 /dc owa.god.org /mAccount demol /mPassword pAss123! /service cifs /ptt

在这里插入图片描述

MS14068成因:
补丁编号是KB3011780,域里面最严重的漏洞之一,它允许任意用户提升到域管权限。下面简要分析下该漏洞。
该漏洞最本质的地方在于Microsoft Windows Kerberos KDC无法正确检查Kerberos票证请求随附的特权属性证书(PAC)中的有效签名,这里面的签名就是上面提到的服务检验和以及KDC校验和。导致用户可以自己构造一张PAC。 签名原本的设计是要用到HMAC系列的checksum算法,也就是必须要有key的参与,我们没有krbtgt的hash以及服务的hash,就没有办法生成有效的签名,但是问题就出在,实现的时候允许所有的checksum算法都可以,包括MD5。那我们只需要把PAC 进行md5,就生成新的校验和。这也就意味着我们可以随意更改PAC的内容,完了之后再用md5 给他生成一个服务检验和以及KDC校验和。在MS14-068修补程序之后,Microsoft添加了一个附加的验证步骤,以确保校验和类型为KRBCHECKSUMHMAC_MD5。

PAC:由于MS14068只验证么用户是谁,没有验证用户能做什么引入的一个安全机制。
是用户申请TGT的时候由KDC回复的包含用户SID,用户组等的信息。此时和传统的
kerber认证相比,当服务端解密了用户的TGS会获取到用户的PAC拿去和KDC对比查
看用户具有权限(PAC不可伪造),但是有些服务不验证KDC所以能利用白银票价,
而所有正常的用户都能申请TGS,所以kerberosting能够利用成功。

此文重在自我理解,然后个人记录,没有连贯性,请谅解
参考:
https://www.anquanke.com/post/id/190261
https://www.anquanke.com/post/id/190625
https://www.anquanke.com/post/id/192810
https://mp.weixin.qq.com/s/OI9XiUGe4-1exmFOkV9ZVQ
https://www.geekby.site/2021/12/samaccountname-spoofing/

标签:TGS,42287,hash,Windows,用户,KDC,PAC,服务,CVE
来源: https://blog.csdn.net/weixin_45682070/article/details/121980350

专注分享技术,共同学习,共同进步。侵权联系[admin#icode9.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有