域用户更改密码提示拒绝访问_Kerberos KDC域权限提升漏洞总结

最新推荐文章于 2024-08-30 17:04:10 发布

weixin_39559333

最新推荐文章于 2024-08-30 17:04:10 发布

阅读量1k

点赞数

文章标签：域用户更改密码提示拒绝访问无需用户名和密码域验证

01漏洞起源

Windows Kerberos 对 kerberos tickets 中的 PAC(Privilege Attribute Certificate)的验证流程中存在安全漏洞，低权限的经过认证的远程攻击者利用该漏洞可以伪造一个PAC并通过 Kerberos KDC(Key Distribution Center)的验证，攻击成功使得攻击者可以提升权限，获取域管理权限。

02漏洞描述

（1）简单的相互身份验证

A向B发送信息时，会附加一个Authenticator（认证码，该数据结构=身份信息+时间戳)来进行彼此的身份验证。开始验证之前，A和B已经有一个有且只有二人知晓的密钥）

下面是工作流程：

1.A用密钥加密了[信息+Authenticator（身份信息+时间戳）]，将其发给B

2.B用密钥解密了A发来的Authenticator，并将其中包含的时间戳记录下来。B将这个时间戳与自己的当前时间进行比较，如果这个时间差大于某个值（windows下默认是5分钟），B认为信息不是A发来的，拒绝后续验证。如果这个时间差小于设定值，B要检查在过去5分钟内，是否存在含有更早时间戳的Authenticator，如果没有，B认为信息确实是A发来了。至此，完成了B对A的验证

3.B用密码加密Authenticator里的时间戳，然后将其发回给A，以证明自己确实是B

4.A收到后，解密出时间戳，经过自己的对比，确认了对方确实是B，至此完成了A对B的验证

（2）Kerberos描述

1.用户Sue登陆到自己的客户端，客户端向认证服务器发送一个TGT（Ticket Granting Ticker）请求到KDC服务

2. 认证服务器确认用户的访问权限和session key认证服务器使用用户密码HASH作为KEY去加密请求然后发送到客户端

3. 客户端后续使用这个密码去解密以后的消息。解密成功后，用户使用TGT去到TGS请求一个服务票据

4. TGS返回一个服务票据

5. 用户拿服务票据去认证

6. 开启客户端和服务端会话

（3）漏洞描述

上面的图有一个地方没有指出，无论TGT还是服务票据都包含一个PAC（Privilege Attribute Certificate）,PAC包含了两个信息，一个是用户SID，另一个是用户的组。

当用户登录KDC验证服务的时候，服务会验证PAC中的签名。如果PAC携带的签名表示“Sue”是“域控管理员”安全组的成员，那么创建的登陆session会话就将Sue当成了管理员。这样的认证存在问题，攻击者可以伪造身份。

（4）漏洞危害

这个漏洞的主要危害是以普通域用户身份可以伪造域管理员身份。

如果机器上并没有打补丁 3011780 则可能存在这个漏洞能够被恶意利用。

涉及系统：

Windows Server 2003

Windows Vista

Windows Server 2008

Windows 7

Windows Server 2008 R2

Windows 8 and Windows 8.1

Windows Server 2012 and Windows Server 2012 R2

Server Core installation option

03漏洞原理

（1）PAC原理

Server收到Client发来的TGS后，要根据TGS中Client申明所在的域组，和Server上的ACL进行对，然后决定给予Client什么样的资源访问权限。微软使用PAC来表示TGS中Client申明的域组。PAC（Privilege Attribute Certificate），特权属性证书。

PAC包含Client的User的SID、Group的SID。PAC决定了Client的组属性，即决定了Client的权限PAC为了保证自身的合法性，还包含2个签名，Key为krbtgt的NTLM，签名的内容除了User SID、Group SID外，还有其他部分PAC作为TGT的一部分，是加密的，密钥为krbtgt的NTLM作Client向KDC的AS模块发起认证请求，AS返回TGT时，会根据Client所在的组，生成PAC，包含Client的User SID、Group SID，以及用于确保PAC不被篡改的2个签名

（2）漏洞成因

Client在发起认证请求时，通过设置include-PAC为False，则返回TGT中不会包含PAC

KDC对PAC进行验证时，对于PAC尾部的签名算法，虽然原理上规定必须是带有Key的签名算法才可以，但微软在实现上，却允许任意签名算法，只要客户端指定任意签名算法，KDC服务器就会使用指定的算法进行签名验证。因此伪造的任意内容都可以是合法的，直接加上内容的MD5值作为签名即可（第一个原因）

PAC没有被放在TGT中，放在其它地方。KDC在仍然能够正确解析出没有放在TGT中的PAC信息PAC必须是密文，经过Key加密的KDC会从Authenticator中取出来subkey，把PAC信息解密并利用客户端设定的签名算法验证签名（第二个原因）

KDC验证缺少PAC的TGT成功后，再验证不在TGT中的PAC的合法性。如果2个均验证成功，KDC把PAC中的User SID、Group SID取出来，重新使用进行签名，签名算法和密钥与设置inclue-pac标志位为TRUE时一模一样。将新产生的PAC加入到解密后的TGT中，再重新加密制作全新的TGT发送给Client，不是TGS（第三个原因）

04漏洞利用

在做域渗透测试时，当我们拿到了一个普通域成员的账号后，想继续对该域进行渗透，拿到域控服务器权限。如果域控服务器存在MS14-068漏洞，并且未打补丁，那么我们就可以利用MS14-068快速获得域控服务器权限。

MS14-068编号CVE-2014-6324，补丁为3011780，如果自检可在域控制器上使用命令检测，如返回结果为空则说明服务器存在MS14-068。

存在如下拓补图：

域用户hack在域成员主机A上登陆过，域成员主机A的管理员通过mimikatz得到了域用户hack的用户名，密码，SID等值，而且域控存在MS14-068漏洞，现在域成员主机A想通过MS14-068漏洞访问域控。

1、生成TGT

（1）使用net config workstation命令查看工作域的名称

（2）使用ms14-068.exe生成票据

有关ms14-068工具使用如下：

其中 -u 域成员名@域名

-s 域成员SID

-d 域控制器地址

-p 域成员密码

目前为止唯一不知道的是域成员SID的值，使用whoami -all命令可以查看域成员的SID值：

所以使用如下命令生成票据：

2、注入TGT

（1）在域成员机器上，先使用klist命令查看自己的票据信息

（2）如果存在票据，则使用klist purge命令清理掉，否则可能会导致无法成功

（3）使用mimikatz进行注入

（4）查看票据是否注入成功

（5）尝试访问域服务器

成功读取域服务器C盘文件，获得域控权限。

注意：

1.注入票据时，机器不能是03或xp，因为mimikatz不支持这两个机器注入

2. 当获取到域用户、域用户SID、密码以及可访问到域控制器的机器，并不需要机器一定在域中（如攻击者通过VPN等拨入内网），但需要把dns指向域控制器才能解析

3. 访问域控制器时，需要使用主机名，不能使用IP