原文：4a3K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2X3L8%4u0@1K9h3&6W2N6q4)9J5k6h3y4G2L8g2)9J5c8X3u0D9L8$3N6Q4x3V1k6@1K9s2u0W2j5i4c8Q4x3X3c8J5k6i4y4W2j5i4u0U0K9q4)9J5c8Y4c8Z5k6g2)9J5k6r3y4S2M7$3g2Q4x3X3c8K6N6s2g2V1K9h3g2K6i4K6u0V1L8$3k6Q4x3X3c8E0K9h3y4J5L8%4y4G2k6Y4c8Q4x3X3c8%4K9h3&6V1L8%4N6K6i4K6u0V1M7X3g2E0L8%4c8W2i4K6u0V1M7s2u0G2j5$3g2V1N6i4u0W2i4K6u0V1j5$3q4D9L8q4)9J5k6s2y4W2M7Y4k6Q4x3X3g2Z5N6r3#2D9

翻译：玉林小学生                   校对：Nxe

        2018年8月，一个网名为SandboxEscaper的研究者公开了一个Windows本地提权0-day。在0-day被公开在网上的几周内，该漏洞的利用工具就被恶意软件作者大量使用。如ESET所说，这件事在InfoSec社区引起了一些混乱。这件事也引起了FortiGuard实验室的注意。

        FortiGuard实验室相信理解这个攻击的原理有助于其它研究者找到与SandboxEscaper发现的Windows Task Scheduler中类似的漏洞。本文我们将介绍找到滥用RPC服务的一个符号链接进行提权的漏洞的方法。

        该漏洞表明Windows Task Scheduler在一个RPC(Remote Procedure Calls) 服务提供的RPC API中有缺陷。事实上，大多数RPC服务由system权限的系统进程提供，准许低权限的RPC客户端与其进行交互。和其它软件一样，这些RPC服务易被拒绝服务、内存破坏和逻辑错误一类的问题影响。也就是说攻击者能够利用RPC服务中存在的脆弱性。

        这个0-day被如此迅速如此大范围利用的一个原因是其基于的攻击点很容易被利用。它由一个程序的逻辑错误引起，使用正确的工具和技术很容易地发现这个问题。这类特殊的提权脆弱性只需一个链接到特权文件或目录的符号链接就可以进行利用，将最终导致一个普通用户进行特权提升。如果感兴趣，Google Project Zero的James Forshaw分享了许多关于符号链接攻击的资源。

        当开始一个新研究时，在动手自己写工具前通常先从scratch找找看是否有可以利用的开源工具。幸运的是，微软RPC是一个著名的协议，研究者在过去许多年间对其进行了大量的逆向研究。研究者开源了一款叫RpcView的工具，这是一个识别Windows操作系统上运行的RPC服务的很好的工具。这是我最爱的RPC工具之一，有许多有用的功能，如：搜索RPC接口全局统一标识符（UUID）、搜索RPC接口名。

        然而，在一个文章中反编译并介绍所有RPC信息与我们的目标无关。幸运的是，通过阅读源代码，我们发现作者已经在工具中包含了我们需要的功能，但默认没有开启且只能通过一个特殊的命令行参数在调试模式下触发。由于这个限制，我们在RpcView GUI开启并修改原来的DecompileAllInterfaces函数。如果你对使用这个功能感兴趣，可以在我们的Github中找到我们订制的RpcView工具。我们现在可以在下一节介绍Decompile All Interfaces (反编译所有接口)功能的好处了。

图一：使用RpcView反编译所有接口功能

        分析一个RPC服务器的行为时，我们通常调用RPC接口导出的API。我们感兴趣的那些与RPC服务器的交互，可以通过利用RPC客户端向服务器发送RPC请求来实现，然后使用SysInternals里的Process Monitor工具来观察行为。我认为，使用脚本比使用C/C++写一个需要编译的RPC客户端更方便，后者很消耗时间。

        我们选择使用PythonForWindows。它以python方式对一些Windows功能提供了抽象，这个功能依赖于python的ctypes。它里面也包含一个RPC库，提供了一些很方便的函数节约了写RPC客户端的时间。例如，一个传统的RPC客户端需要定义接口定义语言，并且需要人工实现绑定操作，这些通常涉及C++代码。看下面的代码列表一和代码列表二，里面列出了使用脚本和以最小的错误处理代码编程实现RPC客户端的不同。

代码列表1: 使用PythonForWindows的RPC客户端SvcSetStorageSettings

代码列表2: 使用C++的RPC客户端SvcSetStorageSettings

        RPC客户端成功执行相应的RPC API后，我们使用Process Monitor监控它们行为。Process Monitor对动态分析很有帮助，它提供了基于事件的API运行时信息。需要提一下，Process Monitor有一个很少被人知道的功能，调用栈信息，如图2所示，使用它可以追踪事件的API调用信息。

图2：Process Monitor 的API 调用栈

        例如，在使用类似IDA的反汇编工具进行静态分析时，可以使用这里的地址和路径信息来精确定位对应的模块和函数。这样进行研究很有用，因为有时只使用Process Monitor的输出信息无法确定潜在的符号链接攻击模式。这是基于反汇编的静态分析能帮助我们发现条件竞争问题的原因，在本文第二部分会讨论这个问题。

        你听说过微软在Windows10中搜集客户信息、数据和文件访问详细信息么？你有考虑过这是如何实现的么？如果你感兴趣，可以读读这篇关于UTC背后机制的文章。

        开始下一阶段的分析前，我们先从RpcView GUI将所有RPC接口导出到一个文本文件。这个文件中包含所有可以从RPC服务器调用的RPC API。在输出的文件中，我们寻找可以接受宽字符作为输入的API，最终我们在diagtrack.dll中遇到了一个有趣的RPC接口。随后我们从RpcView GUI显示的描述信息中确定了，这个DLL组件负责实现UTC功能，特别是从名称Microsoft Windows Diagnostic Tracking中判断。

图3：RpcView揭示了UTC的DLL组件，并且其中的一个RPC接口接受宽字符作为输入

        记住我们的目标是找到一个API，接收一个文件路径作为输入并最终导致提权，正如Windows Task Scheduler的bug一样。但是满足这个条件的API有16个，如图3所示。显然，我们需要从这些API中过滤掉不感兴趣的。所以我们需要使用IDA进行静态分析以确定进一步分析的API。

我通常先定位到RpcServerRegisterIf函数，它用于在RPC服务器注册一个接口描述。接口描述包含指定RPC服务所拥有的RPC接口的定义。根据MSDN的文档所说，接口描述是该函数的第一个参数，由下面的RPC_SERVER_INTERFACE数据结构表示：

图4：在IDA中追踪导入表来判断DispatchTable 的动态图

        我们判定目标是以UtcApi为前缀的UTC接口API之后，如图4所示，我们尝试判断是否这些接口API里的每一个都会调用Access Control List (ACL) API，如SetNamedSecurityInfo和SetSecurityInfo。我们对这些ACL API感兴趣，因为它们用于修改对象的自主访问控制（DACL）安全描述符，无论对于文件、目录还是注册表对象。IDA里的另一个有用的功能是它的proximity视图，它以图形形式呈现一个函数调用图。我们使用proximity视图来寻找被上面提到的ACL API引用或调用的函数。

图5：IDA的Proximity视图显示diagtrack.dll中SetSecurityInfo与其它函数的调用关系

        然而，当我们试图寻找SetSecurityInfo和UtcApi之间的调用关联时，IDA没有产生有用的结果。经过深入分析，我们发现UtcApi将客户端的RPC请求放置到workitem队列中，之后会被异步线程处理。如图5所示，触发Microsoft::Diagnostic::EscalationWorkItem::Execute时将执行SetSecurityInfo。本质上，这是一个负责执行RPC客户端提交的权限提升请求的回调函数。

        从这点上说，我们需要弄明白如何提交一个权限提升请求。在尝试各种应用之后，我们偶然发现了Microsoft Feedback Hub，这是一个Windows默认自带的Universal Windows Platform (UWP)应用。在研究过程中，你会发现调试UWP应用很有用。不幸的是，你不能使用windbg直接打开或附加一个UWP应用。然而，可以通过PLMDebug工具开启UWP应用调试功能，这个工具来自Windows10 SDK调试工具集。你可以先通过Powershell内建cmdlet确定Feedback Hub的完整包家族名：

        获得完整包名后，我们再次使用PLMDebug开启Feedback Hub的UWP调试：

        下一次启动Feedback Hub时，应用将执行并自动附加到WinDbg。

图6：从Process Monitor的事件属性中确定API调用的偏移

        启动Feedback Hub后，我们一步步按照应用在屏幕上的指令向下执行，并开始在Process Monitor中看活动记录。这是一个好信号，这表明我们已经在追踪了。当我们查看图6中高亮的SetSecurityFile事件的调用栈时，在偏移0x15A091（diagtrack.dll的基地址可以在事件属性(Event Properties)的Process标签页找到）处发现了ACL API SetSecurityInfo的返回地址。正如你所看到的，这个偏移属于函数Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile，如图6中反汇编所示，它也出现在图5的proximity视图中。这证明了我们可以利用Feedback Hub到达我们期望的代码路径。

        而且，Process Monitor的输出还告诉我们这个事件尝试设置文件对象的DACL，但是通过静态分析来找文件对象是如何产生的太耗时了。幸运的是，这个进程没有被Protected Process Light (PPL)机制保护，我们可以对svchost.exe附加一个有管理员权限的本地调试器，这个程序负责托管UTC服务。这就给了我们灵活性，可以通过动态调试UTC服务来了解文件路径产生的过程。

        在表象之下，通过Feedback Hub提交请求之后，所有feedback细节信息和附件将存在名字格式为%DOCUMENTS%\FeedbackHub\<guid>\diagtracktempdir<random_decimals>的临时目录。附加在diagtracktempdir之后的十进制随机数由BCryptGenRandom API产生，这意味着产生的数理论上不可预测。然而符号链接攻击有一个重要的限制，需要有预测文件或目录名的能力，所以diagtracktempdir目录名的随机性增加了符号链接脆弱性利用的困难。因此，我们转到其它过程中寻找其它潜在的问题。

        当我们尝试弄清楚diagtracktempdir的安全描述符如何设置时，我们发现将以固定的安全描述符串O:BAD:P(A;OICI;GA;;;BA)(A;OICI;GA;;;SY)来创建目录，这表明对象的DACL只能被管理员和本地的system用户访问。但是，如果设置了下面的注册表键，安全描述符检查将被忽略：

        梳理一下，如果注册表键不存在，diagtracktempdir将被强制执行一个固定的安全描述符，否则将对目录使用默认的DACL并引起潜在的安全问题，并且创建目录时没有使用模拟令牌。也就是，如果你有一个任意注册表写脆弱性，你就可以跳过对该目录设置固定安全描述符。但这不是我们期望的，所以只好再看看Process Monitor：

图7：设置DACL并重命名diagtracktempdir目录

        基本上，我们可以总结图7中的操作如下：

1.         在本地system特权下授权当前登录用户对diagtracktempdir的访问

2.         在模拟令牌下，重命名diagtracktempdir到GUID格式的目录

3.         在模拟令牌下，收回当前登录用户对diagtracktempdir目录的访问权限

        下面的代码片段对于图7所示的操作：

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课