如何利用Active Directory中的ACL提升权限

阅读量    38278 |   稿费 200

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

一、前言

在内部渗透测试中,我们经常可以在几个小时以内获取域管访问权限,原因在于相关系统并没有经过足够的安全加固,运维人员使用了默认的不安全的Active Directory(活动目录)设置。在这种场景中,许多公开工具可以帮助我们查找并利用这些缺陷,最终获得域管理员访问权限。在本文中我们描述了一种渗透场景,其中我们无法使用标准的攻击方法,只能深入挖掘才能获得目标域中的高等级权限。我们介绍了如何使用访问控制列表(Acccess Control Lists)来提升权限,也发布了Invoke-Aclpwn这款新型工具,该工具是ntlmrelayx的扩充,可以自动执行这种高级的攻击步骤。

 

二、AD、ACL以及ACE

随着大家对网络安全方面的理解变得更加成熟也更加深刻,我们不得不深入研究才能在Active Directory(AD)中提升权限。在这类场景中,枚举是一项非常关键的技术。AD目录中的ACL(访问控制列表)经常容易被人忽视。ACL指的就是一组规则,定义了哪些实体在特定的AD对象上具备哪些权限。这些对象可以是用户账户、组、计算机账户、域本身等等。ACL可以在某个对象(比如用户账户)上进行配置,也可以在Organizational Unit(OU,类似于AD内的一个目录)上配置。在OU上配置ACL的主要优点在于,如果配置得当,所有的后继对象都将继承ACL。对象所属的OU对应的ACL中包含一个ACE(Access Control Entry,访问控制项),定义了OU以及/或者子对象上对应的标识以及权限。ACE中的标识不一定是用户账户本身;将权限应用于AD的安全组(security groups)是一种常见的做法。将用户账户添加为该安全组的成员后,该用户账户就可以被赋予ACE中配置的权限,因为用户账户与安全组为隶属关系。

AD中的组成员关系属于递归从属关系,举个例子,假设我们有3个组:

  • Group_A
    • Group_B
      • Group_C

Group_C为Group_B的成员,而Group_B自己又是Group_A的成员。当我们将Bob添加为Group_C的成员,Bob不仅是Group_C的成员,也是Group_B以及Group_A的间接成员。这意味着当Group_A具备某个对象或者资源的访问权限时,Bob也同样具备该资源的访问权限。被访问的资源可以是NTFS文件共享、打印机或者某个AD对象(比如用户、计算机、组或者域本身)。

为AD安全组提供权限以及访问控制权是维护和管理(访问)IT基础架构的好方法。然而,如果嵌套关系过于复杂,可能就会存在一些安全隐患。前面提到过,如果某个用户是某个组的直接或者间接成员,那么该用户就会继承该组对某个资源的所有权限。如果Group_A被赋予修改AD中域对象的权限,那么Bob自然就会继承这些权限。然而,如果某个用户仅属于某个组,是该组的直接成员,但这个组又是其他50个组的间接成员,那么想理清这种权限继承关系显然要花费不少精力。

 

三、利用Exchange在AD中提升权限

在最近的渗透测试中,我们成功获取了某个用户账户权限,该用户为Organization Management组的成员。当安装Exhcange时会创建这个组,赋予其访问Exchange相关活动的访问权限。除了能访问这些Exchange设置选项以外,该组的成员还可以修改其他Exchange安全组的组成员关系,比如Exchange Trusted Subsystem安全组。这个组是Exchange Windows Permissions安全组的成员之一。

默认情况下,如果某个域安装了Exchange,那么Exchange Windows Permissions安全组就具备该域对象的writeDACL权限[1]。

writeDACL权限可以允许持有者修改特定对象的权限(换句话说就是修改ACL),这意味着只要成为Organization Management组的成员,我们就可以提升成为域管理员权限。

为了利用这一点,我们将之前已获得的用户账户添加至Exchange Trusted Subsystem组中。再次登录后(因为只有在登录时才会加载安全组成员关系),现在我们已成为Exchange Trusted Subsystem以及Exchange Windows Permission组的成员,这样我们就可以修改域的ACL。

如果我们可以修改某个AD对象的ACL,我们就可以给某个账户分配权限,使其可以向某个属性(比如包含电话号码的属性)中写入数据。除了为这些属性分配读写权限之外,我们还可以进一步分配,使其具备更多的权限。这些权限为预定义的任务,包括修改密码的权限、往邮箱发送电子邮件等等[2]。我们还可以为任意账户添加如下扩展权限,使其成为当前域的复制(replication)同伴:

Replicating Directory Changes
Replicating Directory Changes All

当我们给这个用户账户设置这些权限后,我们就可以请求域中任何用户的密码散列,其中也包括域的krbtgt账户。大家可以参考GitHub深入了解这种权限提升技术。

当然,成功控制Organization Management组下某个用户账户并不是经常出现的事情。尽管如此,我们还是可以在更广泛的层面上使用这种技术。Organization Management组很有可能受另一个小组管理,而这个组又有可能被其他组管理,以此类推。这意味着域环境中存在一条难以发现的关系链,如果某一环出问题,整个域就可能沦陷。

为了帮助大家利用关系链存在的这种安全风险,Fox-IT编写了两款工具。第一款工具使用PowerShell编写,可以在AD环境内部或者外部运行。第二款工具是ntlmrelayx工具的扩展,这个扩展可以让攻击者将身份标识(用户账户以及计算机账户)转发至活动目录,修改域对象的ACL。

 

四、Invoke-ACLPwn

Invoke-ACLPwn是一个Powershell脚本,可以使用集成的凭据或者指定的凭据来运行。这款工具的工作原理是使用SharpHound导出域内所有ACL以及当前用户账户下的组成员关系。如果用户不具备域对象的writeDACL权限,该工具会枚举域内ACL的所有ACE。ACE中的每个标识都拥有自己的ACL,也会被添加到枚举队列中进行处理。为了枚举所有信息,整个过程需要一点时间,但最终很有可能理出一条关系链,获得域对象的writeDACL权限。

当算出关系链后,脚本就会开始处理链中可能被利用的每一环:

1、将用户加入必要的组中;

2、将两个ACE(Replicating Directory ChangesReplicating Directory Changes All)添加到域对象的ACL中:

3、如果有必要,则使用Mimikatz的DCSync功能请求给定用户账户的哈希值。默认情况下会使用krbtgt账户。

利用过程结束后,该脚本会移除利用过程中添加的组成员关系,也会删掉域对象ACL中的ACE。

为了测试脚本是否能正常工作,我们创建了26个安全组。每个组都是另一个组的成员(即testgroup_atestgroup_b,而testgroup_b又是testgroup_c的成员,以此类推,直到testgroup_z为止)。

testgroup_z安全组具备修改Organization Management安全组的成员关系权限。前面提到过,这个组有权修改Exchange Trusted Subsystem安全组的组成员关系。只要我们成为该组的成员,就有权修改活动目录中域对象的ACL。

现在我们拥有包含31条链接的一条关系链:

1、26个安全组的间接成员关系;

2、具备修改Organization Management安全组成员关系的权限;

3、已成为Organization Management组的成员;

4、具备修改Exchange Trusted Subsystem安全组成员关系的权限;

5、已成为Exchange Trusted Subsystem以及Exchange Windows Permission安全组的成员。

工具的输出结果如下图所示:

需要注意的是,虽然这个例子中我们使用了ACL配置信息(Exchange安装过程中会进行配置),然而这款工具并不需要依赖Exchange或者其他产品来查找或者利用关系链。

目前该工具只能枚举并利用域对象上的writeDACL权限,我们还可以利用其他对象上的其他类型的访问权限,比如ownerwriteOwnergenericAll等。

BloodHound团队在一篇白皮书中详细解释了这些访问权限,我们将在未来更新这款工具时将这些权限的利用方法包含在内。大家可以从我们的GitHub上下载Invoke-ACLPwn工具。

 

五、NTLMRelayx

去年我们为ntlmrelay编写了新的扩充,使其支持中继至LDAP功能,这样就能将新用户添加到活动目录中,实现域枚举并提升至域管权限。之前ntlmrelayx中的LDAP攻击会检查中继账户是否为域管(Domain Admins)或者企业管理员(Enterprise Admins)组,如果是则会提升权限。

虽然这种方法的确有效,但并没有考虑中继账户可能拥有的任何特殊权限。根据本文介绍的研究成果,我们在ntlmrelayx中引入了新的攻击方法。这种攻击首先会请求重要域对象的ACL,然后将二进制格式解析成工具能够理解的格式,接着枚举中继账户的权限。

这样就能将中继账户所属的所有组(包括递归的组成员关系)考虑在内。一旦枚举完权限,ntlmrelayx就会检查用户是否具备足够高的权限,以便新用户或者现有用户提升权限。

为了提升权限,我们可以使用两种不同的攻击方法。第一种攻击称为“ACL攻击”,其中域对象的ACL被修改,攻击者可控的某个账户被赋予域中的Replication-Get-Changes-All权限,这样就可以使用前面提到过的DCSync方法。如果无法修改ACL,则使用“Group攻击”将成员添加到域的高权限组中,这些高权限组包括:

Enterprise Admins
Domain Admins
Backup Operators(可以备份域控制器上的关键文件)
Account Operators(可以控制域中几乎所有的组)

如果使用--escalate-user标志指定已有的某个用户,那么在可以执行ACL攻击的前提下,该用户将被赋予Replication权限。如果使用的是“Group攻击”,则会将该用户添加到高权限组中。如果没有指定已有的用户,则可以考虑创建新的用户。用户可以创建在User容器中(用户账户的默认位置),或者在OrganizationalUnit中(类似IT部门等成员具备该容器的管理权限)。

可能会有人注意到我们提到的是中继账户,而不是中继用户。这是因为这种攻击对具备高权限的计算机账户来说同样适用。比如Exchange服务器的计算机账户就属于这类账户,在默认配置下该账户属于Exchange Windows Permissions组的成员。如果攻击者能够让Exchange服务器向攻击者的主机发起身份认证请求(比如使用mitm6这种网络层的攻击技术),那么攻击者就能立即将权限提升为域管理员权限。

现在我们可以使用impacket的secretsdump.py或者Mimikatz导出NTDS.dit的哈希值。

同样,如果攻击者具备Exchange服务器的管理员权限,也有可能不需要导出任何密码或者机器账户哈希,就能实现域权限的提升。如果以NT AuthoritySYSTEM身份连接到攻击者的主机并使用NTLM进行身份认证,这样就足以向LDAP进行身份认证。如下图中,我们以SYSTEM权限使用psexec.py调用Invoke-Webrequest这个PowerShell函数,使用-UseDefaultCredentials启动NTLM的自动身份验证:

备注:这里出现404错误非常正常,因为如果中继攻击完成后,ntlmrelayx.py会提供一个404页面。

需要注意的是,在默认配置的Active Directory中,针对LDAP的中继攻击有可能顺利完成。如果启用LDAP签名就能在一定程度上缓解这种攻击,然而LDAP签名默认处于禁用状态。即便启用了LDAP签名,攻击者还是有可能中继至LDAPS(基于SSL/TLS的LDAP),因为LDAPS可以当成一个签名通道。针对此类攻击的唯一缓解方法是在注册表中为LDAP绑定通道。

如果想获取ntlmrelayx中的新功能,只需更新到GitHub上最新版本的impacket即可。

 

六、安全建议

为了缓解这类安全风险,Fox-IT有如下几点建议:

1、移除危险的ACL。

使用Bloodhound之类的工具来检查危险的ACL[3]。Bloodhound可以导出域内的所有ACL,帮助我们识别危险的ACL。

2、移除Exchange Exterprise Servers的writeDACL权限。

移除Exchange Exterprise Servers的writeDACL权限。更多信息请参考这篇.aspx)技术文档。

3、监控安全组。

监控可能对域产生重大影响的安全组(的成员关系),比如Exchange Trusted Subsystem以及Exchange Windows Permissions

4、审核并监控对ACL的修改操作。

审核域内ACL的修改操作。如果尚未部署这种机制,那么我们需要修改域控制器的策略。大家可以参考TechNet上的这篇文章了解更多细节。

当域对象的ACL被修改后,就会出现ID为5136的一条事件日志。我们可以使用PowerShell查询Windows事件日志,比如我们可以使用如下一行语句查询Security事件日志中ID为5136的事件:

Get-WinEvent -FilterHashtable @{logname='security'; id=5136}

该事件中包含帐户名以及以SDDL(Security Descriptor Definition Language)格式表示ACL。

我们无法直接查看这个数据,但在Windows 10中有一个PowerShell cmdlet:ConvertFrom-SDDL[4],这个cmdlet可以将SDDL字符串转化为可读性较好的ACL对象。

如果服务器运行的是Windows Server 2016操作系统,我们还可能看到原始的以及修改后的描述符。大家可以参考此链接了解更多信息。

获得这个信息后,我们就可以开始着手调查,发现哪些条目被修改过,研究背后的真实原因。

 

七、参考资料

[1] https://technet.microsoft.com/en-us/library/ee681663.aspx
[2] https://technet.microsoft.com/en-us/library/ff405676.aspx
[3] https://github.com/BloodHoundAD/SharpHound
[4] https://docs.microsoft.com/en-us/powershell/module/Microsoft.powershell.utility/convertfrom-sddlstring

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多