您当前的位置:首页 >> 资讯 >  >> 
只读域控制器RODC是难打还是不能打?
来源: 哔哩哔哩      时间:2023-08-31 16:36:27

只读域控制器(RODC)是一种微软 Windows Server操作系统的角色,它提供了一种安全的方式来将Active Directory服务扩展到安全较低的网络边缘。RODC只允许只读访问,不允许对 Active Directory的数据进行修改,这使得它们成为支持远程办公、分布式办公和边缘部署等场景的理想选择。


(资料图片)

然而,与任何安全策略一样,RODC也存在一些潜在的安全风险。在使用RODC 时,需要认真考虑安全因素,并采取适当的措施来缓解这些风险。在本文中,我们将探讨 RODC 的安全风险,并提供一些防范措施,以确保其安全性。

RODC中的管理员

RODC ManagedBy属性值可以用于指定RODC的管理员,这样可以确保只有授权的用户或组才能管理RODC。指定ManagedBy属性值时,可以选择指定一个用户或组。当指定一个组时,该组中的成员都将被授予对RODC的管理权限。这样可以简化管理,避免逐个指定每个管理员。

当获取了RODC ManagedBy属性中列出的账户权限,就可以在RODC上拥有本地管理员权限。如果获取了具有委派权限来修改RODC的ManagedBy属性的账户权限,同样也可以成为管理员。

因此,对于ManagedBy属性值,必须进行适当的管理和保护,以确保只有授权的用户或组才能进行RODC的管理操作。同时,也需要定期审查ManagedBy属性值,以确保其仍然是最新的和正确的。

RODC中的身份验证

在Windows Server 2008中引入RODC时,Microsoft强制规定RODC不得使用 Kerberos TGT加密。这是因为TGT是Active Directory中用于加密用户身份验证凭据的关键密钥之一。如果TGT的密钥被泄露,攻击者就可以使用该密钥解密用户身份验证凭据,从而获取用户的用户名和密码。

为了加强安全性,RODC引入了一种新的加密机制:不可逆转的密码加密。该机制使用一个密码复制策略来控制RODC缓存的用户密码。密码复制策略由域管理员在Active Directory中配置,并指定哪些用户的密码可以被RODC缓存,以及在RODC上缓存的密码是否可被解密。只有在密码复制策略明确允许的情况下,RODC才会缓存用户密码。这可以避免密码被泄露,提高RODC的安全性。

为此,RODC还引入了两个重要的属性:msDS-RevealOnDemandGroup和msDS-NeverRevealGroup。

msDS-RevealOnDemandGroup属性指定了一组可以在RODC上缓存其成员身份的安全组。如果用户是该组的成员,RODC将在需要时向上级域控制器请求其身份信息,并将其缓存在本地。这可以提高身份验证速度和效率。

msDS-NeverRevealGroup属性指定了一组不允许在RODC上缓存其成员身份的安全组。如果用户是该组的成员,则其身份信息将始终从上级域控制器请求,并不会缓存在RODC上。这可以保护敏感信息,避免在RODC上泄露。

其中后者的优先级最高,当某用户或组同时存在于两个属性当中,RODC无法检索其凭据。

进行身份验证时,RODC需要访问用户和计算机的凭据来在本地对它们进行身份验证。每个RODC都有一个特定的主体列表,它被指定为要认证的主体,并因此允许检索其凭据。这个列表存储在RODC的机器账户的msDS-RevealOnDemandGroup属性中。

在认证用户或计算机之后需要生成TGT,而RODC并不能使用域中kertgt密钥来对TGT进行加密和签名,因此当某服务器提升为RODC的时候,AD域会创建一个新的krbtgt账户,此用户被分配一个五位数的密钥版本号,同时此账号的名称为krbtgt_xxxxx,此账号的名称可以在RODC机器账户的msDS-KrbTgtLink属性中找到,而五位数的密钥版本号和机器账户的名称可以在新的KRBTGT帐户的msDS-SecondaryKrbTgtNumber和msDS-KrbTgtLinkBl属性中找到。

PS > Get-ADComputer RODC -Properties msDS-KrbTgtLink

PS > Get-ADUser krbtgt_23165 -Properties msDS-SecondaryKrbTgtNumber,msDS-KrbTGTLinkBl

RODC黄金票据

当获得RODC管理员权限时,可以dump缓存在RODC中的凭据,例如krbtgt凭据,因此可以伪造一个RODC的黄金票据。

使用Rubeus来创建一个黄金票据,rodcNumber代表RODC中krbtgt的密钥版本号,aes256代表RODC krbtgt用户的密钥,id为要制作票据用户的rid,最后还需要域名和域内sid的值。

golden /rodcNumber:23165 /aes256:eacd894dd0d93...7a0ebbfa64c7545 /user:administrator

/id:500 /domain: 

/sid:S-1-5-21-1281121768-1524864103-2976670869

密钥列表攻击

之后将这个黄金票据用于向域控发送kebtgt服务的TGS-REQ,TGS-REQ包含“Key List Request”(KERB-KEY-LIST-REQ),KERB-KEY-LIST-REQ 结构用于请求KDC 可以提供给客户端的密钥类型列表。

如果目标账户在RODC的msDS-RevealOnDemandGroup属性中且不在msDS-NeverRevealGroup属性中,TGS-REP将返回一个包含目标用户凭证的KERB-KEY-LIST-REP结构,解密后,可以获得其hash从而进行hash传递攻击。

下面由rubeus工具和上面制作的票据来完成key list攻击:

asktgs /enctype:aes256 /keyList /service:krbtgt/ /dc: /ticket:doIFgzCCBX+gAwIBBaEDA.....

域内权限提升

经过上面的描述可以看出,当获取到RODC的本地管理员权限时,可以获取到在msDS-RevealOnDemandGroup属性中而不在msDS-NeverRevealGroup属性中的用户,因此,如果我们可以操作这两个属性,就可以加入administrator账户,实现提权。

具体过程:

1.首先将域管理员账户添加到msDS-RevealOnDemandGroup 属性中。

PS > Set-DomainObject -Identity RODC$ -Set @{'msDS-RevealOnDemandGroup'=@('CN=Allowed RODC Password Replication Group,CN=Users,DC=relay,DC=com', ' CN=Administrator,CN=Users,DC=relay,DC=com')}

2.然后将msDS-NeverRevealGroup 属性直接清空。

PS > Set-DomainObject -Identity RODC$ -Clear 'msDS-NeverRevealGroup'

3.通过修改ManagedBy属性,获得RODC的特权访问以获取缓存凭据的访问权限。

4.之后跟前面提到的一样,伪造目标账户的RODC TGT,并请求key list attack攻击,获取到域管理员凭据。

5.最后进行清理痕迹,还原RODC的msDS-RevealOnDemandGroup和msDS-NeverRevealGroup的属性值。

这种方法与key list attack的区别就是此权限提升方式需要具备更改写入RODC msDS-RevealOnDemandGroup等属性的权限,即GenericWrite,GenericAll,WriteDacl,Owns,WriteOwner,WriteProperty等访问权限。

总结

总结来说,RODC虽然具有许多优点,但与可写DC可能存在相同的安全风险等级,因此RODC和可写DC一样需要采取适当的安全措施来保护RODC,以确保它的安全使用。这包括在RODC上实施最小权限原则、定期进行安全审计、强制实施复杂的密码策略等。

另外针对本文讲解的相关攻击手法,可以采用如下措施帮助缓解:

1.审核所有RODC的msDS-RevealOnDemandGroup属性,确保它不包含任何域管理员组账户。

2.将所有管理员组账户添加到Denied RODC密码复制组,并将该组添加到所有RODC的msDS-NeverRevealGroup属性中。

标签:

X 关闭

X 关闭