绕过Windows 10的CFG机制

0x00 前言

本文是2016年7月一些研究的结果，但是直到现在才能发布。在6月，Theori发布了一篇博文关于IE的漏洞MS16-063，他们写的利用是针对Windows7上IE 11版本，并且他们认为因为Windows 10 的CFG机制无法在Windows 10利用。本文描述了我如何在Windows 10利用，并绕过CFG，事实我还发现了另一种方法，会在将来发布。

0x01 理解CFG

控制流保护(CFG)是微软在Windows 8.1 update 3和Windows 10中实现的缓解措施，用来保护汇编级别的非直接调用。趋势已经公布了Windows 10上面关于CFG的很好的分析文章。已经有集中公布的绕过CFG的方法，但是这些方法主要的目标是CFG实现算法，但是我想从这个功能的弱点入手。因为Theori在他们博文中写的Windows 7上面的利用因为CFG的存在无法有效工作，让我们看下为什么并试图绕过它。

来自Theori的利用代码在Windows 10的IE中直接覆盖了虚函数表。因此问题是我们如何利用任意读写来绕过CFG。根据趋势的研究，CFG被函数LdrValidateUserCallTarget调用来验证一个函数的调用是否用了非直接调用：

加载到EDX中的指针是验证位图的基本指针，在这种情况下是：

然后，被验证的函数将其地址加载到ECX中，如果kernel32!VirtualProtectStub作为示例，则在这种情况下的地址是：

然后地址右移8位，用于装入保存该地址有效位的DWORD值，在这种情况下：

然后函数地址右移3位，并执行位测试，这本质上对位移地址进行模数0x20操作，然后是验证位图的DWORD中检查的位，因此在这种情况下：

因此相关位在偏移0x14处：

这意味着它是可靠的。因此VirtualProtect的调用地址是可靠的，然而这没有真的解决问题，它的参数也必须由攻击者提供。正常情况应该是用ROP链，但是任何不是从函数开始的字节都是无效的。因此解决方案是找到一个函数在被调用的地方的参数是可以控制的，并且函数的功能可以给攻击者利用。这需要在利用中非常仔细。

0x02 在Windows 10中利用

在Theori提供的利用，代码是通过stack pivot小配件覆盖TypedArray的虚函数表，因此这个没有其他可能了，研究TypedArray提供的函数是值得的，发现下面两个函数比较有用：

他们的偏移是0x7c和0x188，他们能从javascript代码中直接调用，并且HasItem有个可以控制的参数，同时Subarray有两个用户可控制的参数。然而问题是它们都不返回除布尔值之外的任何数据。此外，所选择的函数必须采用相同数量的参数，否则堆栈不平衡将会引发异常。我搜索的API应该暴露一个指针能用来覆盖返回地址，以便可以绕过CFG。

我定位的可用的API是RtlCaptureContext，由kernel32.dll、kernelbase.dll和ntdll.dll导出，这个API有一个指向CONTEXT结构的参数：

CONTEXT结构储存了转储的所有的寄存器(包括ESP)，而且输入值仅仅是一个缓冲区的指针。看一下TypedArray对象的内存布局：

第一个DWORD值是虚函数表指针，能够被覆盖创建一个假的虚函数表，在偏移0x7c处存储API RtlCaptureContext的地址，同时偏移0x20是TypedArray指向的真实数据的指针：

因为泄漏这个缓冲区的地址也是可能的，它能提供RtlCaptureContext的参数。为了完成夹的虚函数表，不得不创建一个指针指向偏移0x7c处的ntdll!RtlCaptureContext，这意味着泄露了RtlCaptureContext的地址，继而意味这泄露了ntdll.dll的地址。执行此操作的默认路径是使用vtable的地址，它是一个指向jscript9.dll的指针：

从这个指针往回0x1000个字节，搜索MZ头，继而查找到指向kernelbase.dll的导入表。做同样的操作能偶获得kernelbase.dll的基址，然后再获得ntdll.dll的导入表指针并再次获得其基址，然后从导出函数中找到RtlCaptureContext。尽管这个方法是可靠的但是有个缺陷，如果在系统中装了EMET，将触发来自jscript9.dll的代码的崩溃，因为从PE头或导出表读取数据不被允许，为了绕过EMET我使用了一个不同的技术。记住每一个非直接调用都被CFG保护，因为jscript9.dll的函数被CFG保护了，所以不能调用直接指向ntdll的函数。一个在虚表中偏移0x10的函数如下：

用原始读操作，指向ntdll.dll的指针能通过以下函数找到：

通过ntdll.dll的指针得到RtlCaptureContext的地址，不通过读取导出表而是使用搜索特征和哈希找到并读取。RtlCaptureContext看起来如下：

前0x30字节总是相同的并且很特殊，因此可以用哈希碰撞找到函数地址：

函数可以使用指向ntdll.dll的指针作为参数。

把上面的都整合到一起：

从这偏移0x200包含了RtlCaptureContext的结果，看起来如下：

从上面可以清楚地看出堆栈指针已经泄漏，现在找到一个能控制执行的地址是个问题。看下栈顶显示：

那就是当前函数的返回地址，这个地址位于与RtlCaptureContext信息中的偏移0x9C处的泄漏指针相距0x40字节的偏移处。运气好，这个偏移对于其他简单函数将是相同的，所以应该可以写入并使其覆盖其自己的返回地址，从而绕过CFG。

利用补充如下：

运行时显示EIP控制：

而且，在偏移0x40和0x44的写入现在位于栈顶，允许创建一个stack pivot和ROP链，一种方法是用POP EAX接着XCHG EAX，ESP。

0x03 微软缓解措施

Microsoft已经声明，堆栈上的损坏返回地来绕过CFG是一个已知的设计限制，因此无法修复或领取任何种类的赏金，如下所示：

正如那个所说，微软做了两个事情来缓解这个技术，首先在未来的Windows 10版本中，RFG将被实现，阻止堆栈损坏以给予执行控制的方式。另一个是在Windows 10的周年版发布中引入敏感的API的介绍，它仅保护微软Edge，但是上述情况无法保护，但是他能阻止微软Edge中的RtlCaptureContext。Poc代码可以在这找到：https://github.com/MortenSchenk/RtlCaptureContext-CFG-Bypass。