windows中关于委派(delegation)的理解

1.前言

委派一般出现在域环境中。它是一种机制,在kerberos认证的时候会涉及到。不正确的委派的配置,可能使攻击者达到提权的目的。

2.什么是委派

假设有三个对象:

服务/用户主机名
用户AhostA
服务BhostB
服务ChostC

假设用户A在使用主机hostB上的服务B,这时候用户A使用了服务B的一个功能,这个功能需要让主机hostB上的服务B访问主机HostC上的服务C中专属于用户A的部分才能完成,这时候主机hostB上的服务B就需要代表用户A去访问hostC上的服务C。这整个过程就是委派。

简而言之,上述过程就是用户A委派主机hostB上的服务代表自己去访问了主机hostC上的服务C,委派需要提前在域控上进行配置,它可以理解成是一种权限。

三种委派:

  1. 非约束性委派

    直接在域控上配置主机hostB的委派属性,配置成如下图所示:
    在这里插入图片描述
    这样子的话,任何用户都可以委派主机hostB代替自己去访问任何服务。

  2. 约束性委派

    选择“仅信任此计算机来委派指定的服务”如下图:
    在这里插入图片描述
    如果hostB被配置了如上图所示的约束性委派,那么这时候主机hostB就可以被任意用户委派去访问LISI计算机上的cifs服务,与非约束性委派的区别是,限制了访问的服务类型与主机,但不能限制谁能对主机hostB进行委派。

  3. 基于资源的约束性委派

    需要在拥有资源的机器上去设置,如第二步中想限制只有指定主机才能被委派来访问主机lisi上面的cifs服务,就需要在域控上对主机lisi上进行基于资源的约束性委派的配置。

2.1 前置知识

KDC可以确定A是否有访问服务B的权限,这时候就得有一个方法来让KDC知道A允许B代表自己来“做事情”,这句话可能有点绕,可以多看几遍。这时候S4U2SELF与S4U2PROXY这两个东西就出现了。这两种协议在非约束性委派的机器上不会使用,只会影响约束性与基于资源的约束性这两种委派方式

2.1.1 S4U2SELF

2.1.1.1 用途

S4U2SELF的作用是使得服务可以代表某个用户获得一个用来访问服务自身的票据。

2.1.1.2 细节

这个东西在TGS_REQ这个阶段中,S4U2SELF是这个数据包的一部分内容。
S4U2SELF一般是一个值,例如Administrator等。当配置了这个值并且服务器B获得了可转发的TICKET票据后,服务器B就可以代表Administrator进行操作。配置这个值可以自己配置,那么获得可转发的TICKET票据有什么条件呢?
1.一个可转发的服务器B的TGT。
2.当前服务器B配置了约束委派,如下图所示:
在这里插入图片描述
3.服务B在TGS_REQ阶段设置了forwardable选项
在这里插入图片描述
这些都能自己设置,那岂不是可以伪造任意用户对当前服务B进行操作了?其实不是的,倘若目标用户被设置成敏感账户,不能被委派,则TICKET的FLAG字段肯定没有forwardable,也就是说条件3是无法满足的,于是不能伪装成此用户。

2.1.1.3 延伸

如果我们能伪装成任意用户,那么就能以任意用户的权限来操作当前服务器B。

2.1.2 S4U2PROXY

2.1.2.1 用途

S4U2PROXY也是在TGS_REQ阶段的一个参数。
S4U2PROXY可以使当前主机代表其他用户来访问其他主机,相比较于S4U2SELF,范围大了很多,当然“代表”肯定也是有限制条件的。

2.1.2.2 细节

大概过程如下:
在这里插入图片描述
要想使用S4U2PROXY必须得经过S4U2SELF阶段,需要获得那个可转发的TICKET,这个TICEKT会放在TGS_REQ中的additionTicket中。
假设当前主机为b,接受了administrator的委派。主机B将这个TGS_REQ请求发送给KDC并获得访问其他主机例如主机C的权限。
上面这些是大概流程,具体需要达成的条件为:
1.S4U2SELF阶段生成的可转发的TICKET
2.在TGS_REQ阶段设置CNAME-IN-ADDL-TKT标志
3.在TGS_REQ阶段设置forwardable标志
4.如果服务1 有到服务2的非约束委派,将服务2的SPN放在sname里面。
在这里插入图片描述

S4U2proxy 必须扩展PAFORUSER结构。

PA-PAC-OPTION

在这里插入图片描述

类型是 PAPACOPTIONS

值是以下flag的组合

— Claims(0)

— Branch Aware(1)

— Forward to Full DC(2)

— Resource-based Constrained Delegation (3)
如果是基于资源的约束委派,就需要指定Resource-based Constrained Delegation位。

2.2 非约束性委派

当前主机可以模仿某个用户去访问任意服务。需要配置如下:
在这里插入图片描述

如果admin委派服务器B来代替自己访问其他服务,则admin会先将自己的TGT发送给服务器B存储在lsass中。非约束性委派不会走S4U2Self和S4U2proxy这两个协议。

2.2.1 细节补充

这里给大家一张微软官方的图片方便大家理解:
在这里插入图片描述
现在假设这么一种情形,service1配置了非约束性委派,用户A需要委派service1来访问service2。这个service1可以是主机账户。

那么非约束性委派的过程可以大概理解为:

  1. 用户A向KDC申请一张可转发的用户A自己的TGT与访问service1需要的ticket。
  2. 用户A将第一步得到的ticket与可转发的tgt与tgt中的session key一起发送给了service1.
  3. service1使用那张tgt与session key来代表用户A行使后续操作例如访问service2.

2.3 约束性委派

约束委派就是限制了当前服务器可以被委派去访问哪些服务,非约束性委派是不会限制当前服务器被委派时可访问的服务的。
换句话说,约束性委派被配置后,被委派的主机只能访问之前限制的服务。具体配置如下:
在这里插入图片描述
若服务器B被配置了约束性委派,则它可以接受任何用户对于某些特定服务的委派例如上图中就是可以接受任何用户对于WIN-JQO4OSM主机上CIFS服务的委派。先经过S4U2SELF阶段拿到一个可转发的TICKET,然后再经过S4U2PROXY阶段,这时候就能代表用户访问特定服务了,这个特定的服务是windows提前定义好的,不像非约束性委派那么自由。配置了约束委派的用户的userAccountControl 属性有个FLAG位 TrustedToAuthForDelegation 。
确定哪些服务可以通过委派访问一般是域管决定的,具体是拥有SeEnableDelegation权限的人决定,这个人一般是域管。

2.3.1 细节补充

非约束性委派被委派的机器会直接得到发布委派的用户的TGT,是十分不安全的,因此微软推出了约束性委派,还扩充kerberos协议,添加了s4u2self与s4u2proxy协议,以增加安全性。这两个协议的具体细节可以查看:windows中关于委派(delegation)的理解这篇文章。下面我简述一下约束性委派的过程,假设有这么一种情况,用户A委派service1去访问service2,那么大概的访问过程如下:

  1. 用户A访问service1。
  2. service1通过s4u2self协议代表用户A去请求一个可以访问service1自身的可转发的ticket,这个ticket代表域控授权service1可以以用户A的身份进行操作。
  3. service1以用户A的身份访问KDC请求一个访问service2的可转发的ticket
  4. service1获取到ticket并以用户A的名义访问service2。

第一个ticket表示域控授权service1代表用户A来访问service1,第二个ticket代表域控授权service1代表用户来访问service2。总的来说s4u2self解决的问题就是,确定了某台主机可以代表某用户来对自己进行操作。s4u2proxy解决的问题是确定了某台主机可以代表某用户对其他主机进行操作。

2.4 基于资源的约束性委派

基于资源的约束委派将委派的控制权交给拥有被访问资源的管理员。比如约束性委派中,域管能限制主机A可代表他人访问哪些主机。而基于资源的约束性委派实现跟他相反,假如我是当前主机的管理员,我就可以设定,谁可以被委派访问我的主机。
举个例子如果是服务器C配置了服务器B可以访问其资源。那么如果我们站在服务器B的角度,整个流程如下:
服务器B进行S4U2SELF,但与传统但委派不同,它最终会获得一个无法转发但TICKET,这时候进行S4U2PROXY阶段,需要将PA-PAC-OPTION里面但RBCD标识为设为1即可。
在这里插入图片描述

2.4.1 细节补充

它的过程跟约束性委派的过程几乎一样,区别比较大的地方在于:

  1. 有权利配置约束性委派的人的账号是服务所在的主机的主机账号与将这台主机加入到域内的那个账号
  2. 请求过程中s4u2self得到的ticket即使是不能转发的,也不会影响整个请求的结果。

3. 基于委派的攻击

3.1 非约束委派攻击

因为如果一个主机可以接受非约束性委派,所有委派这个主机来代替自己的用户都会将自己的TGT传送给此主机。如果我们找到配置了非约束的委派的账户,并且通过一定手段拿下该账户的权限,然后诱导域管访问该主机,这个时候域管会将自己TGT发送到主机并缓存到LSASS中,那我们就可以从LSASS中导出域管的TGT票据,然后通过PTT,从而拥有域管的权限。

3.2 约束委派攻击

如果我们找到配置了约束委派的主机账号,并且通过一定手段拿下该账号所在的主机。我们就可以利用这个主机账号代表任意用户进行s4u2self获得一个可转发的TICKET,然后把获取到的票据用于s4u2proxy(作为AddtionTicket),从而获得另一个可转发的TICKET,服务利用这个TICKET就可以代替任意用户访问那个被配置为约束委派的服务。

3.3 基于资源的约束委派攻击

普通的约束委派的配置需要SeEnableDelegation权限,而这个权限通常仅授予Domain Admins。因此我们对普通的约束委派的利用,往往在于寻找域内已有的约束委派,再利用。但是对于基于资源的约束委派,假如我们已经拥有主机账号1,那么只要我们具备用户2的LDAP权限,这样就可以配置服务1对服务2的约束委派(在主机账户2的用户属性上配置msDS-AllowedToActOnBehalfOfOtherIdentity为1的sid),服务1就可以控制服务2。
所以基于资源的约束委派的利用,就有一种新的攻击思路

1.我们拥有一个任意的主机账户1或者计算机账户1

这一步不难,我们我们拥有域内机器,提升到system权限,该计算机用户,用户名为计算机账号$就是服务账号。如果我们只有普通的域内用户,可以滥用MachineAccountQuota,工具Powermad可以实现。

2.我们获得主机账户2 的LDAP权限

这一步可以结合ntlm relay,从其他协议relay 而来,关于这一步,更多的是ntlm relay的过程,限于篇幅原因,这里面会在ntlm篇的relay详细介绍。典型案例就是CVE2019-1040。

3.配置服务1对服务2的约束委派

在主机账户2的用户属性上配置msDS-AllowedToActOnBehalfOfOtherIdentity为主机账户1的sid。

4.发起一个从服务1到服务2的正常的约束委派的流程,从而访问服务2。

这个流程见上面的约束委派,使用rubeus也可以很方便得进行一键访问。

参考文章:
Windows内网协议学习Kerberos篇之TGSREQ& TGSREP
域渗透——Kerberos委派攻击
域渗透——基于资源的约束委派利用

相关推荐
©️2020 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页