CVE-2018-0952：Windows Standard Collector服务中的特权提升漏
如果你对寻找bug的过程不感兴趣，或者是“太长不看”那种，那么ATREDIS-2018-0004是个不错的选择，而且这里还有一个概念性证明（PoC）。
Process Monitor已经是我研究和开发时最喜欢的一个工具。在开发安全工具时，我频繁地用它来监视工具如何与Windows交互，以及它们是如何被检测到的。今年早些时候，我在Visual Studio中调试一段代码并用Procmon监视时注意到一些有趣的行为。一般来说，我会为Visual Studio设置过滤以减少干扰。但在设置过滤之前，我注意到一个SYSTEM进程写入用户拥有的目录：
StandardCollector.Service.exe 写入用户临时文件夹
当拥有权限的服务写入用户拥有的资源时，可能会产生符号链接（symlink）攻击向量的可能性，为了确定如何直接影响服务的行为，我通过查看服务加载的库开始研究Standard Collector服务：
Visual Studio DLLs被StandardCollector.Service.exe加载
库的路径显示Standard Collector服务是Visual Studio诊断工具的一部分，在浏览了相关文件夹的一些库和可执行文件之后，我发现有几个二进制文件是用.NET写的，其中包括一个叫VSDiagnostics.exe的独立命令行工具，下图为控制台的输出：
VSDiagnostics命令行工具的输出
将VSDiagnostics加载到dnSpy中会发现很多关于该工具以及它如何与Standard Collector服务服务交互的内容。首先，获取IStandardCollectorService的实例，并使用会话配置创建ICollectionSession：
初始配置诊断收集会话的步骤
接下来，用CLSID和DLL名称将代理添加到ICollectionSession，这也是一个比较有趣的用户控制行为。它也让我记得以前的研究就是利用了这种DLL加载行为。此时，看起来Visual Studio Standard Collector服务与Windows 10中包含的诊断中心Standard Collector服务非常相似甚至相同。我开始使用OleViewDotNet查询服务来查询其支持的接口：
OleViewDotNet中的Windows诊断中心Standard Collector服务
查看IStandardCollectorService的proxy definition会显示其他熟悉的接口，特别是VSDiagnostics源中的ICollectionSession接口：
OleViewDotNet中的ICollectionSession接口定义
记下接口ID（“IID”）后，我返回到.NET操作库来比较IID，然而发现它们不同：
具有不同IID的Visual Studio ICollectionSession定义
深入研究.NET代码，我发现这些Visual Studio特定的接口是通过代理DLL加载的：
VSDiagnostics.exe函数加载DLL
对DiagnosticsHub.StandardCollector.Proxy.dll中的ManualRegisterInterfaces函数的预览显示了一个迭代IID数组的简单循环。包含在IID数组中的是属于ICollectionSession的数组：
ManualRegisterInterfaces DLL的函数
要注册的IID数组中的Visual Studio ICollectionSession IID
在更好地理解Visual Studio Collector服务之后，我想看看是否可以重用相同的.NET代码来控制WindowsCollector服务。为了与正确的服务进行交互，我需要用正确的Windows Collector服务CLSID和IID替换Visual Studio CLSID和IID。接下来，我使用修改后的代码构建一个客户端，该客户端只是创建并启动了Collector服务的诊断会话：
用于与Collector服务交互的客户端的代码片段
启动Procmon并运行客户端会在指定的C:\Temp临时目录中创建多个文件和文件夹。在Procmon中分析这些事件表明，初始目录创建是在客户端模拟的情况下执行的：
如果你对寻找bug的过程不感兴趣，或者是“太长不看”那种，那么ATREDIS-2018-0004是个不错的选择，而且这里还有一个概念性证明（PoC）。
Process Monitor已经是我研究和开发时最喜欢的一个工具。在开发安全工具时，我频繁地用它来监视工具如何与Windows交互，以及它们是如何被检测到的。今年早些时候，我在Visual Studio中调试一段代码并用Procmon监视时注意到一些有趣的行为。一般来说，我会为Visual Studio设置过滤以减少干扰。但在设置过滤之前，我注意到一个SYSTEM进程写入用户拥有的目录：
StandardCollector.Service.exe 写入用户临时文件夹
当拥有权限的服务写入用户拥有的资源时，可能会产生符号链接（symlink）攻击向量的可能性，为了确定如何直接影响服务的行为，我通过查看服务加载的库开始研究Standard Collector服务：
无奈人生安全网
Visual Studio DLLs被StandardCollector.Service.exe加载
库的路径显示Standard Collector服务是Visual Studio诊断工具的一部分，在浏览了相关文件夹的一些库和可执行文件之后，我发现有几个二进制文件是用.NET写的，其中包括一个叫VSDiagnostics.exe的独立命令行工具，下图为控制台的输出：
VSDiagnostics命令行工具的输出
将VSDiagnostics加载到dnSpy中会发现很多关于该工具以及它如何与Standard Collector服务服务交互的内容。首先，获取IStandardCollectorService的实例，并使用会话配置创建ICollectionSession：
初始配置诊断收集会话的步骤
接下来，用CLSID和DLL名称将代理添加到ICollectionSession，这也是一个比较有趣的用户控制行为。它也让我记得以前的研究就是利用了这种DLL加载行为。此时，看起来Visual Studio Standard Collector服务与Windows 10中包含的诊断中心Standard Collector服务非常相似甚至相同。我开始使用OleViewDotNet查询服务来查询其支持的接口：
copyright 无奈人生
OleViewDotNet中的Windows诊断中心Standard Collector服务
查看IStandardCollectorService的proxy definition会显示其他熟悉的接口，特别是VSDiagnostics源中的ICollectionSession接口：
OleViewDotNet中的ICollectionSession接口定义
记下接口ID（“IID”）后，我返回到.NET操作库来比较IID，然而发现它们不同：
具有不同IID的Visual Studio ICollectionSession定义
深入研究.NET代码，我发现这些Visual Studio特定的接口是通过代理DLL加载的：
copyright 无奈人生 VSDiagnostics.exe函数加载DLL
对DiagnosticsHub.StandardCollector.Proxy.dll中的ManualRegisterInterfaces函数的预览显示了一个迭代IID数组的简单循环。包含在IID数组中的是属于ICollectionSession的数组：
ManualRegisterInterfaces DLL的函数
要注册的IID数组中的Visual Studio ICollectionSession IID
在更好地理解Visual Studio Collector服务之后，我想看看是否可以重用相同的.NET代码来控制WindowsCollector服务。为了与正确的服务进行交互，我需要用正确的Windows Collector服务CLSID和IID替换Visual Studio CLSID和IID。接下来，我使用修改后的代码构建一个客户端，该客户端只是创建并启动了Collector服务的诊断会话：
本文来自无奈人生安全网
用于与Collector服务交互的客户端的代码片段
启动Procmon并运行客户端会在指定的C:\Temp临时目录中创建多个文件和文件夹。在Procmon中分析这些事件表明，初始目录创建是在客户端模拟的情况下执行的：
无奈人生安全网 www.wnhack.com