大数据&云计算利用Symantec Endpoint Protection中的任意文件移动( 二 )


大数据&云计算利用Symantec Endpoint Protection中的任意文件移动
本文插图
如果可以到达此处理程序 , 则可以滥用第一种情况来控制MoveFileExA的源和目标 , 从而以SYSTEM用户身份移动任意文件 。
为了达到这个处理程序 , 我们需要返回到RPC函数 。 一旦从Proc0检索到客户端上下文句柄 , 就需要使用Proc6 。 这个函数处理解析请求并将其发送到适当的通道其原型如下:
大数据&云计算利用Symantec Endpoint Protection中的任意文件移动
本文插图
简单地说 , lpInputBuf是包含路由请求所需的所有必要信息的请求缓冲区 , 而lpInputBuf2是发送到命令处理程序进行处理的缓冲区(尽管它由ccIPC进行了部分处理) 。
请求缓冲区采用以下形式:
大数据&云计算利用Symantec Endpoint Protection中的任意文件移动
本文插图
第一个字符串是我们请求的通道 , 第二个是注册到插件的处理程序的GUID , 最后一个字符串传递给通道来执行GUID绑定的任何函数 。
第二缓冲区由序言和嵌入式有效载荷缓冲区组成 , 这个序言包含协议版本(总是0x1)、参数类型和有效载荷长度 。 在序言和主要用于路由请求的有效载荷之间有一些字节 。
内嵌的有效载荷包含到达目的地所需的所有信息这包括子命令(64)、客户端PID、源文件名和目标文件名 , 每个文件名都以长度作为前缀 。 两个字符串都应该是ANSI 。 结果如下:
大数据&云计算利用Symantec Endpoint Protection中的任意文件移动
本文插图
在这里 , 我们可以看到 , 我们正在移动文件c:users“users”“setup.dll”到c:windows“sysnative”“setup. dll“ 。 Sysnative是一个虚拟文件夹 , 它允许我们访问64位的System32文件夹 , 而不是SysWOW64 。 因为SEP是一个32位应用程序 , 所以到System32的任何路径都将映射到SysWOW64 , 这是我们不想做的 。
漏洞利用
文件移动过程很简单 , 在Windows 10 1903年之前 , James Forshaw的DiagHub策略是我们的首选策略 。 简单地说 , Microsoft Diagnostics Hub标准收集器服务(DiagHub)是一个收集跟踪信息的服务 , 并通过DCOM编程公开 。 该DCOM对象可用于将DLL加载到系统进程中 , 前提是该DLL存在于c:windows模块system32目录中 。 这非常适合于利用任意文件移动 , 因为我们可以简单地调用此服务 , 并在非必要的特权系统进程中安全执行代码 。
从1903版及更高版本开始 , DiagHub无法再用于加载任意DLL 。 可以使用更新的策略UsoLoader 。 这类似于DiagHub , 但使用Update Session Orchestrator将DLL加载到System32之外的特权进程中 。 当然这里也存在其他选择 。 由于我们完全控制了写入的目的地 , 因此我们可以将DLL劫持到Windows本身和SEP本身的任何数量的系统服务中 。
最终 , 在14.0和14.2版本之间的某个时间 , Symantec确认此插件特别敏感 , 并进行了验证检查 。 一旦请求到达AVHostPlugin , SEP将验证该请求是否来自Symantec签名的进程 。 以下是相关部分:
大数据&云计算利用Symantec Endpoint Protection中的任意文件移动
本文插图
它使用RpcServerInqCallAttributesA获取发送请求的RPC客户端的进程ID 。 然后使用另一个库ccSvrTrst验证请求进程的签名 。 但是 , 这很容易绕开 。 不会对正在运行的进程的令牌进行任何检查 , 只需检查它是否由Symantec签名即可 。 通过生成Symantec二进制文件并通过某种形式的代码注入或DLL劫持将其注入其中 , 我们可以从该托管进程发出所有RPC请求并通过检查 。
我们的概念证明是作为标准DLL实施的 , 期望用户将滥用DLL加载路径来获取Symantec签名二进制文件中的代码执行 。 一个示例DevViewer.exe可用于加载DLL 。 通过将可执行文件复制到用户控制的位置 , 我们的利用DLL可以放在同一路径中 , 并重命名为TextInputFramework.dll 。 这将在启动时加载到DevViewer进程中 , 并允许我们将有效请求发送到AVHostPlugin接口 。


推荐阅读