缓解Active Directory中Exchange权限路径提升至域管理员

作者：Sean Metcalf
原文发布：TrimarcSecurity.com
原文链接：https://www.trimarcsecurity.com/single-post/2019/02/12/Mitigating-Exchange-Permission-Paths-to-Domain-Admins-in-Active-Directory

问题背景

近期，Dirk-jan Mollema发布了一篇博客文章《滥用Exchange：一步之遥成为域管理员》（https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/），重点指出了Exchange权限的几个问题，以及一个链式攻击可能导致普通邮箱用户提升为AD林中的域管理员。相关利用工具也已发布。

他在博客引言中强调了问题的关键组成部分：

Exchange服务器默认具有（过高的）权限。
NTLM认证易受中继攻击。
Exchange有一个特性使其以Exchange服务器计算机账户向攻击者认证。

核心漏洞在于Exchange在Active Directory域中拥有高权限。Exchange Windows Permissions组在Active Directory域对象上具有WriteDacl权限，允许任何成员修改域权限，包括执行DCSync操作的权限。拥有此权限的用户或计算机可以执行通常由域控制器用于复制的同步操作，从而使攻击者能够同步AD中所有用户的哈希密码。

Active Directory中的Exchange权限

在2017年微软Blue Hat会议上，Trimarc创始人兼Active Directory主题专家Sean Metcalf强调了Exchange权限问题。Andy Robbins（@_wald0）和Will（@Harmj0y）在包括Black Hat USA 2017在内的演示中也进一步阐述了此问题。

Andy Robbins、Rohan Vazarkar和Will编写的Bloodhound工具可以识别涉及AD中配置的Exchange权限的攻击路径。

微软最近发布了一篇文章（https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190007），关于如何配置EWS限制以缓解Dirk-jan Mollema提出的问题。但EWS限制可能对Outlook for Mac等应用产生负面影响，且无法解决AD中配置的Exchange权限提升路径。

Trimarc在执行Active Directory安全评估（ADSAs）时，在许多客户环境中发现Exchange具有提升的AD权限。

在Trimarc ADSAs期间发现的一些Exchange权限：

Organization Management在域根具有完全控制（“GenericAll”）权限。
Exchange Trusted Subsystem在域根具有完全控制（“GenericAll”）权限。
Exchange Recipient Administrators在域根具有完全控制（“GenericAll”）权限。
Exchange Windows Permissions在域根具有修改权限（“WriteDACL”）权限。

列表中的最后一项权限如果存在于AD林中，很可能导致AD泄露。此权限不应被需要，因此从域根移除它应对日常操作无负面影响。我们建议创建一个新的AD组（如“Privileged Modify Domain Permissions”），并将此权限授予该组。当需要此权限时（应很少见），将Exchange Windows Permissions组添加到此新组。

检测AD域权限的PowerShell脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# This is a sample script provided by Trimarc. 
# No warranty or suitability of use is stated or implied.
# This script requires the Active Directory PowerShell module be installed and should be run by a user in the AD forest containing the target domain(s)

$ADDomain = ‘DOMAIN.COM’
$DomainRootPermissionsReportDir = ‘c:\temp’
$DomainRootPermissionsReportName = ‘DomainRootPermissionsReport.csv’

IF (!(Test-Path $DomainRootPermissionsReportDir))
  { new-item -type Directory -path $DomainRootPermissionsReportDir }  
$DomainRootPermissionsReportPath = $DomainRootPermissionsReportDir + ‘\’ + $ADDomain + ‘-‘ +$DomainRootPermissionsReportName

$DomainTopLevelObjectDN = (Get-ADDomain $ADDomain).DistinguishedName

$DomainRootPermissions = Get-ADObject -Identity $DomainTopLevelObjectDN -Properties * | select -ExpandProperty nTSecurityDescriptor | select -ExpandProperty Access

$DomainRootPermissions | select IdentityReference,ActiveDirectoryRights,AccessControlType,IsInherited,InheritanceType,ObjectType,InheritedObjectType,ObjectFlags,InheritanceFlags,PropagationFlags `
  | export-csv $DomainRootPermissionsReportPath -NoTypeInfo
$DomainRootPermissions | select IdentityReference,ActiveDirectoryRights,AccessControlType,IsInherited | sort ActiveDirectoryRights,IdentityReference

Write-Output ” ”
Write-Output “———————————————————————————————————————————— ”
Write-Output “|  $ADDomain Domain Permission Report saved to $DomainRootPermissionsReportPath      | ”
Write-Output “———————————————————————————————————————————— ”

注意：此脚本作为示例提供，需要更改域名以正确收集数据。

在较新版本的Exchange中，通常不需要域级别的广泛权限。此外，即使仅剩的本地Exchange服务器用于管理Office 365，Exchange权限仍然存在。

缓解Microsoft Exchange权限的Active Directory安全问题

上述参考文献突出了与Exchange权限相关的问题，且缓解措施通常复杂且难以实施。

本文的目标是提供一个临时选项，以最小化日常操作影响的方式缓解Exchange在AD中的广泛权限，同时组织可以实施更永久的修复。

对于在默认共享权限模型中运行本地Exchange且未隔离在专用资源林中的组织，需要紧急决定如何处理Exchange Windows Permission组的权限问题。

缓解Exchange具有提升AD权限问题的最佳方法（也是不会从微软得到“我们不支持”答案的方法）是切换到Active Directory（AD）拆分权限（Exchange）或将Exchange隔离在其自己的资源林中（或两者兼施）。拆分权限模型（https://docs.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help）要求使用AD管理工具在AD中创建安全主体（如用户和安全组）。一旦Exchange部署后，实施拆分权限模型并非易事，但能有效限制Exchange在AD中的权限。

微软指出启用Active Directory拆分权限时的以下功能变化：

从Exchange管理工具中移除创建邮箱、邮件启用用户、分发组和其他安全主体的功能。
从Exchange管理工具中添加和移除分发组成员无法完成。
移除授予Exchange Trusted Subsystem和Exchange服务器创建安全主体的所有权限。
Exchange服务器和Exchange管理工具只能修改AD中现有安全主体的Exchange属性。

此临时选项实施的关键变化是将Exchange Trusted Subsystem组从Exchange Windows Permissions组中移除，并通过临时恢复默认成员资格来规避任何未预见的问题。

以下是大致概述，此前提需要根据您的AD和Exchange环境的细微差别进行定制：

保存此链接作为参考，了解Exchange部署时对AD环境所做的权限更改：https://docs.microsoft.com/en-us/exchange/exchange-2013-deployment-permissions-reference-exchange-2013-help
创建一个自定义RBAC组，具有与Organization Management组相同的角色，移除管理员需要永久成员资格的要求。将此组命名为“<DOMAIN/FOREST_NAME> Exchange Organization Management”。
使用Exchange Management Shell中的RBAC cmdlets可以轻松完成。
默认情况下，Organization Management组可以修改AD中Exchange Trusted Subsystem、Exchange Windows Permissions和其他Exchange特权组的成员资格。
微软的此文章引导您完成复制Exchange角色组的过程：https://docs.microsoft.com/en-us/exchange/permissions/role-groups?view=exchserver-2019
根据您的AD OU设计，在适当的OU级别将更合适的AD权限委托给步骤2中创建的组（“<DOMAIN/FOREST_NAME> Exchange Organization Management”）。参考步骤1中提供的链接。
从Exchange Windows Permissions组中移除Exchange Trusted Subsystem组以及任何其他成员。
确保只有Exchange服务器是Exchange Trusted Subsystem组的成员。
使用步骤1中的参考，将默认委托给Exchange Windows Permission组的权限应用于Exchange Trusted Subsystem组，但此次在适当的OU级别而非域根。
从Organization Management组中移除任何成员资格。
确保为以下组的成员资格更改配置监控和警报：
- Exchange Windows Permission
- Exchange Trusted Subsystem
- Organization Management
当需要被移除的权限时，临时将Exchange Trusted Subsystem组添加到Exchange Windows Permissions组。确保在所需任务完成后移除该组。

确保使用组而不是直接在这些权限组中添加单个用户或计算机账户，这应减少需要重新启动计算机和注销再重新登录的需求。

注意：此配置会破坏某些功能并增加Exchange管理的额外负担，但希望对最终用户的日常使用影响很小或无影响。

例如，如果您尝试在环境中安装新的Exchange服务器，可能会收到错误，但可以通过将安装新Exchange服务器的管理员账户临时添加到默认Organization Management组，并临时将Exchange Trusted Subsystem组添加到Exchange Windows Permission组来规避。这是针对此新配置可能破坏的任何事情的解决方法，应主要与AD中域分区的对象创建相关。

另外，如果使用AD拆分权限模型作为此前提可能破坏的其他事情的示例，使用Add-ADpermission cmdlet为邮箱添加权限可能也会破坏，但对于接收连接器应仍然有效，因为邮箱对象存储在域分区，而接收连接器存储在配置分区。

如果您需要联系微软支持，通过简单地将Exchange Trusted Subsystem组临时添加到Exchange Windows Permission组，很容易将自已恢复到“受支持”配置。

此前提尚未经过全面测试以查看在所有环境中可能的所有意外后果，但当某些东西破坏时，可以临时切换回受支持配置作为解决方法。

必须再次强调，这只是一个临时措施，旨在为组织提供一个可能的短期选项，可以快速实施，同时为该组织实施正确的修复或路径。

更新

2019年2月12日，微软发布了修补程序，修改Exchange Web Services推送通知以保护 against Dirk-jan Mollema博客文章中识别的问题，并且微软还减少了Exchange对Active Directory的权限。这要求运行新版本的setup.exe /PrepareAD。

参考文献：

结论

当Exchange最初安装时，它会配置并授予自己广泛的Active Directory权限。这些权限提供了Exchange可能需要的必要访问。问题在于这些权限过于宽松，尤其是在部署早期版本的Exchange时（因为与当前版本相比，Exchange 2000/2003添加了广泛的权限）。

Microsoft Exchange拆分权限模型或部署Exchange资源林是通过Exchange权限缓解AD攻击的最佳方法，尽管这些方法不易部署或配置（或改造）。

Trimarc识别了一种方法，将配置从永久的Exchange权限模型切换为可以在“需要时”（或即时）提供所需权限的模型。

此帖子最初由Trimarc的Exchange & Office 365主题专家Jason Crawford撰写，并由Trimarc团队的其他成员贡献，发布在Trimarc的网站上：https://www.trimarcsecurity.com/single-post/2019/02/12/Mitigating-Exchange-Permission-Paths-to-Domain-Admins-in-Active-Directory

（访问45,089次，今日1次访问）