ICode9

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

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

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

标签: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

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

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

ICode9版权所有