攻击 EDR 第一部分：EDR 驱动程序简介及安全性分析

这篇博文是分析端点检测和响应 (EDR) 解决方案攻击面系列文章的一部分。第 1-3 部分已链接，第 3 部分将对前文子系列进行总结。

• 第 一 部分（本文）概述了 EDR 软件的攻击面，并从低权限用户的角度描述了分析驱动程序的过程。

• 第二部分描述了 EDR 驱动程序安全性分析的结果。在 Cortex XDR 代理的 Windows 驱动程序中发现了一个小的身份验证问题 (CVE-2024-5905)。此外，还发现了一个 PPL 绕过漏洞以及通过早期启动绕过检测漏洞。此外，还对 Sophos Intercept X Windows Mini-Filter 驱动程序的 Mini-Filter 通信端口进行了快照模糊测试。

• 第三部分描述了一个影响大多数 Windows EDR 代理的 DoS 漏洞。该漏洞允许低权限用户利用代理处理对象管理器命名空间中现有对象的方式存在的问题，永久导致代理崩溃/停止。目前只有部分供应商获得了 CVE（CVE-2023-3280、CVE-2024-5909、CVE-2024-20671）。

• 第四部分描述了 Microsoft Defender 扫描和仿真引擎的模糊测试过程mpengine.dll。通过使用 WTF 和 kAFL/NYX 的快照模糊测试，发现了多个越界读取和空引用漏洞。这些漏洞可在文件扫描后立即导致 Defender 主进程崩溃。这些漏洞似乎均无法利用来执行代码。

1. 简介

在当今的组织中，端点检测与响应 (EDR) 解决方案已成为网络安全领域的重要组成部分。尽管 EDR 解决方案已非常普及，但针对 EDR 应用程序本身的攻击的已发表研究仍然明显不足，即使这些应用程序是权限提升、企业网络入侵或路过式攻击的有力目标。这可能有几个原因：该领域的安全研究有限，为红队优势而未发表的研究，或缺乏卓有成效的研究成果。此外，只有少数供应商提供漏洞赏金计划，即使有，Windows 代理也不在范围之内（卡巴斯基除外）。

近年来，大多数关于 EDR 的安全研究都集中在绕过安全措施的技术上，例如 DLL 解钩。意识到这一缺陷，IG 实验室开展了一项研究项目，旨在分析 Windows 上广泛使用的 EDR 驱动程序的攻击面。然而，在开始这项工作之后和发表这篇文章之前，已经出现了一些直接攻击EDR的研究（1、2、3、4、5、…… ）。

由于 EDR 的攻击面非常广泛，我们决定将调查范围限制在低权限用户可访问的驱动程序接口作为入口点。EDR

通常包含自我保护机制，甚至可以阻止本地管理员禁用或卸载产品。然而，虽然受安全功能的限制，但从本地管理员到 SYSTEM 再到 Windows 内核的权限转换并不代表绝对的安全边界。已知的方法可以停用或绕过 EDR，包括自带漏洞驱动程序 (BYOVD) 攻击、Windows Defender 应用程序控制 (WDAC)、WPF 过滤和其他技术。因此，本研究主要关注低权限用户，尽管来自本地管理员的攻击也可能很有价值。

此外，重点关注的是市场上最常用的 EDR。

然而，获取这些 EDR 解决方案用于研究却颇具挑战性。只有极少数供应商未经事先审查就提供试用产品，这进一步缩小了可供分析的 EDR 范围。

典型的“试用”（如果没有合适的业务，您将永远不会获得试用）

尽管一些 EDR 驱动程序允许低权限用户访问某些功能，但未能检测到任何严重的安全问题。尽管如此，这篇博客文章描述了分析过程，包括一些研究路径，但这些路径并未提供任何发现来帮助其他安全研究人员。然而，一段时间后，一条路径指向了 PaloAlto Cortex 中的 ALPC 通信，而这并非最初的重点。这揭示了一个 DoS 漏洞，该漏洞将在第三部分中进行描述。

最初对以下产品进行了驱动因素分析检查：

• Palo Alto Cortex XDR

• Sophos Intercept X

• Microsoft Defender for Endpoint

• Cynet 360

• Tanium（实际上不是 EDR，但功能和架构类似）

1.1 EDR 解决方案的攻击面

EDR 解决方案对于应用程序而言，攻击面相对较大。这些解决方案通常由代理本身和云服务上的多个组件组成，而一些供应商也提供本地服务器。EDR 旨在检测和响应端点级别的威胁，但它们本身也创建了新的攻击面，可能被恶意行为者利用。代理是一个复杂的部分，因此更容易受到漏洞攻击。相比之下，服务器端的前端（至少是用户可直接访问的部分，例如 Web 界面）的攻击面较小，通常也更容易被探索。即使是后端 Web API 也存在一些基本缺陷，例如缺少身份验证，如下图所示。一些产品还使用自定义协议进行代理与云之间的通信，这也值得关注。此外，某些产品还在代理之间实现了 P2P 通信（例如 Tanium），从攻击者的角度来看，这也很值得关注。

这些博客文章仅关注代理方面。

代理通常由用户空间和内核空间（驱动程序）组件组成：

• 过滤驱动程序

• 网络驱动程序

• 软件驱动程序

• 用户空间应用程序

这些组件主要使用以下协议和方法相互通信：

• 内核到内核：

• 导出函数

• IOCTL

• 用户到内核：

• IOCTL

• 过滤连接端口

• 专门用于微过滤驱动

• 底层也使用 IOCTL

• ALPC

• 用户对用户

• ALPC

• 命名管道

• 文件

• 注册表

• 更多的…

以下列表概述了这些组件及其通信中的潜在漏洞。请注意，此列表并不详尽，并且不包含所有服务器端攻击面：

• 文件扫描和仿真中的内存损坏（野外 0day CVE-2021-1647）

• 删除任意文件（SymLink-Vulns）

• 过去存在大量漏洞：删除文件“擦除器”（50% 的测试 EDR 存在漏洞）

• 用户模式 IPC（进程间通信）：授权问题或内存损坏

• 用户到驾驶员：授权问题

• 经典驱动程序漏洞：

• WDM：Ilja van Sprundel：Windows 驱动程序攻击面

• KMDF：对 KMDF 驱动程序进行逆向工程和漏洞挖掘 - Enrique Nissim 出席 44CON 2018

• Mini-Filter：Google Project Zero：寻找 Windows Mini-Filter 驱动程序中的错误

• 服务器到代理

• 缺少服务器身份验证

• 解析服务器响应中的错误

• 经典 Windows 应用程序漏洞（DLL 劫持、文件权限等）

• 模拟/沙盒逃逸

• 其他逻辑错误

本文重点关注用户到驱动程序的授权问题，以及某种程度上的经典驱动程序漏洞。第三部分将讨论用户模式进程间通信 (IPC)。

影响

客户端潜在漏洞的主要影响是本地权限提升或隐藏恶意软件的执行。另一种可能性是伪造发送到后端的代理数据。某些漏洞（例如扫描引擎中的漏洞）也可能导致远程代码执行。此外，代理被攻陷还会扩大后端的攻击面，因为攻击者可以滥用代理的已验证会话。

在基于 P2P 的通信中，严重的设计缺陷可能会导致其他代理被攻陷。

2. 低权限用户的驱动程序攻击

本节概述了如何对 EDR 驱动程序进行安全分析。它主要侧重于识别可能构成低权限用户攻击面的暴露驱动程序功能。本节不会深入探讨驱动程序相关漏洞的具体细节及其利用方式。

对于测试环境，我们建议使用附加了 WinDBG 内核调试器的虚拟机。最简单的设置方法是使用 KDNET（请参阅以下文档）。

2.1 加载了哪些驱动程序？

查看已加载驱动程序的一种方法是使用DriverView，该方法还可以借助从 Microsoft 过滤驱动程序的功能。

安装了 Cortex 的 DriverView

2.2 每个驱动程序向用户空间暴露什么接口

有两种方法可以检查这一点：静态分析和动态分析。我们建议结合使用这两种方法来捕获所有情况。例如，EDR 驱动程序在启动期间可能只初始化一个设备对象，但在 EDR 执行过程中可能会创建更多设备对象。

Windows 驱动模型 (WDM) 或内核模式驱动程序框架 (KMDF) 驱动程序可以公开设备接口。该接口可以从用户空间打开，以便与驱动程序进行交互。

微过滤器驱动程序可以公开一个 FilterCommunicationPort，可以从用户模式使用它来与驱动程序交互。

2.2.1 静态分析

要建立通信接口，驱动程序必须调用特定的 Windows API。这些调用可以使用 IDA 等逆向工程软件进行静态分析。Microsoft 文档中列出的常用函数如下：

• WDM设备驱动程序：

NTSTATUS IoCreateDevice(  [in] PDRIVER_OBJECT DriverObject,  [in] ULONG DeviceExtensionSize,  [in, optional] PUNICODE_STRING DeviceName,  [in] DEVICE_TYPE DeviceType,  [in] ULONG DeviceCharacteristics,  [in] BOOLEAN Exclusive,  [out] PDEVICE_OBJECT *DeviceObject);

或者，可以使用应用默认 SDDL 字符串的 IoCreateDeviceSecure。

• KMDF 设备驱动程序：

NTSTATUS WdfDeviceCreateDeviceInterface(  [in] WDFDEVICE Device,  [in] const GUID *InterfaceClassGUID,  [in, optional] PCUNICODE_STRING ReferenceString);

• 微型过滤器驱动程序：

NTSTATUS FLTAPI FltCreateCommunicationPort([in]           PFLT_FILTER Filter,[out]          PFLT_PORT *ServerPort,[in]           POBJECT_ATTRIBUTES ObjectAttributes,[in, optional] PVOID ServerPortCookie,[in]           PFLT_CONNECT_NOTIFY ConnectNotifyCallback,[in]           PFLT_DISCONNECT_NOTIFY DisconnectNotifyCallback,[in, optional] PFLT_MESSAGE_NOTIFY MessageNotifyCallback,[in]           LONG MaxConnections);

2.2.2 动态分析

可以使用 Sysinternals 的 WinObj（尽管名称并不总是很明显）或通过在内核调试器中设置断点来识别已注册的设备和端口名称。

设备驱动程序：它们在 WinObj 的“GLOBAL??”下以指向设备对象的符号链接形式列出。这使得\.NAME当其他应用程序尝试与驱动程序交互时，可以通过该设备访问设备。另一个选择是使用 OSR 已停用的工具 DeviceTree，该工具以层次结构显示每个驱动程序的设备以及其他信息。

WinObj 与 Cortex 设备

带有 Cortex 设备的 DeviceTree

微过滤驱动：它们在 WinObj 文件中被列为“FilterConnectionPort”

WinObj 中的 FilterConnectionPorts（Cortex）

2.3 各个接口的访问权限是什么？

此步骤更容易动态地完成。

设备驱动程序：据我们所知，目前没有现代工具可以查看设备接口的正确访问权限。请尝试获取 OSR DeviceTree 的副本，它可以直接显示 ACL 和其他标志。另一种方法是使用内核调试器。

迷你过滤驱动程序：测试某个用户是否可以访问 FilterConnectionPort 的一种方法是使用James Forshaw 的NtObjectManager工具https://www.powershellgallery.com/packages/NtObjectManager/1.1.29。

Get-FilterConnectionPort -Path "CyvrFsfd"Exception: "(0x80070005) - Access is denied."

要检索安全描述符，请使用 WinDbg 作为内核调试器：

0: kd> !object CyvrFsfdObject: ffffc2861e32f550 Type: (ffffc2861bc7b220) FilterConnectionPortObjectHeader: ffffc2861e32f520 (new version)HandleCount: 1PointerCount: 6    Directory Object: ffffd9099503e9f0 Name: CyvrFsfd0: kd> dx (((nt!_OBJECT_HEADER*)0xffffc2861e32f520)->SecurityDescriptor & ~0xa)(((nt!_OBJECT_HEADER*)0xffffc2861e32f520)->SecurityDescriptor & ~0xa) :0xffffd909950257a00: kd> !sd 0xffffd909950257a0 1->Revision: 0x1->Sbz1 : 0x0->Control : 0x8004            SE_DACL_PRESENT            SE_SELF_RELATIVE->Owner : S-1-5-32-544 (Alias: BUILTINAdministrators)->Group : S-1-5-18 (Well Known Group: NT AUTHORITYSYSTEM)->Dacl :->Dacl : ->AclRevision: 0x2->Dacl : ->Sbz1 : 0x0->Dacl : ->AclSize : 0x1c->Dacl : ->AceCount : 0x1->Dacl : ->Sbz2 : 0x0->Dacl : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE->Dacl : ->Ace[0]: ->AceFlags: 0x0->Dacl : ->Ace[0]: ->AceSize: 0x14->Dacl : ->Ace[0]: ->Mask : 0x001f0001->Dacl : ->Ace[0]: ->SID: S-1-5-18 (Well Known Group: NT AUTHORITYSYSTEM)->Sacl : is NULL

原文始发于微信公众号（Ots安全）：攻击 EDR 第一部分：EDR 驱动程序简介及安全性分析