通过结构化异常处理绕过CFG Secer's Blog - 记录互联网安全历程与个人成长经历

导语：本文将讲述如何通过结构化异常处理绕过CFG。

我们原来发布了一个基于泄漏堆栈地址并覆盖结构化异常处理程序的技术，从而将一个使用Use-After-Free(UAF)类型的漏洞转换为结构化异常处理的程序。

在本文中为了方便CFG的绕过，我们再次选择使用Internet Explorer 11的Microsoft Windows WPAD权限提升漏洞 (MS16-063)，2016年6月，Theori曾发表了一篇关于MS16-063中修补了的IE漏洞分析，文中发布的漏洞攻击仅是针对Windows7上的IE 11版本，此外由于Windows 10采用了CFG机制所以无法对Windows 10设备进行攻击。

但我们之前已经发布过两篇文章讨论过如何绕过Windows 10环境下的CFG,第一篇请点击这里，另一篇请点击这里。

堆栈的泄漏

在以前的文章中我们已经获得了Clean_Poc.html的POC文件，并利用MS16-063漏洞获得了序列化执行权限（ read/write primitive），但没有再往下进一步分析。在Leaking_Stack.html的 POC文件中，当前线程的堆栈限制被泄露，这是使用kernelbase.dll中的GetCurrentThreadStackLimits API完成的，具体的执行方法是，GetCurrentThreadStackLimits API通过TypedArray对象调用虚拟函数表（vtable），具体的调用过程如下：

2.1.png

我们可以看出，调用发生在虚拟函数表中的偏移0x188处，因为虚拟函数表可以直接从Javascript代码调用并具有两个参数，这对调用非常重要，因为必须确保函数必须具有同等数量的参数，否则堆栈将在返回时引起调用异常。

我们在本文中使用的API是GetCurrentThreadStackLimits，它很容易从MSDN中获取可用的JavaScript调用，如下所示。

2.2.png

GetCurrentThreadStackLimits需要两个参数，并返回堆栈基地址和堆栈的最大保留地址，我们可以通过两个步骤找到GetCurrentThreadStackLimits的地址。

首先将指针泄漏到kernelbase.dll中，然后在DLL中对该函数进行定位。第一部分是通过首先定位jscript9中的Segment :: Initialize函数来完成的，因为它使用了kernel32！VirtualAllocStub及kernelbase！VirtualAlloc。我们是通过在虚拟函数表的地址中扫描jscript9并计算哈希值来找到这个方法的，这是使用序列化执行权限完成的，算法如下图所示。

2.3.png

通过添加5个双字，我们可以每次向前遍历一个字节，直到找到正确的哈希值。非常简单的哈希函数实际上是无冲突的。在Segment :: Initialize函数中的偏移量0x37处，kernel32！VirtualAlloc的解引用调用发生，如下所示。

2.4.png

通过这个指针可以获取以下内容：

2.5.png

然后在kernelbase!VirtualAlloc的偏移0x6处，内核发生跳转。

2.6.png

现在我们就获得了一个指向kernelbase.dll的指针了，然后我们使用与Segment :: Initialize相同的方法找到GetCurrentThreadStackLimits的地址，如下所示。

2.7.png

我们现在可以创建一个假的虚拟函数表，就像Theori在MS16-063中所做的那样，并用这个函数指针修改偏移量0x188处的的虚拟函数表条目，不过要记住增加TypedArray的size参数，然后代码变成。

2.8.png

并且在运行它时触发GetCurrentThreadStackLimits得出以下内容：

2.9.png

上图显示了堆栈的下限和上限，要从这里获取指令指针控件，我们就必须在堆栈中找到结构化的异常处理程序链，并修改一个条目，然后引发异常。在执行此操作时，请务必记住，由于Windows 10启用了SEHOP。因为SEH指针不受CFG保护，这些操作会绕过CFG和RFG，这一切都在文件Getting_Control.html中实现。

为了执行此操作，我们需要在堆栈上找到SEH链，泄漏堆栈限制的结构化异常处理程序链如下所示。

很明显，在调试异常发生时，如果问题不是固定的，那么所有使用jscript9的五个结构化异常处理程序指针都将被使用，而MSHTML！_except_handler4似乎永远处于调试异常的死循环中。因此，如果我们可以修改5个JavaScript异常处理程序中的任何一个并触发异常，我们都将获得可以控制的指令指针。在我们原来的结构化异常处理程序的修改中，整个结构化异常处理链都会被堆栈缓冲区溢出所覆盖，但由此带来的问题便是SEHOP会被触发，因此我们只需要修改其中一个异常处理程序的结构化异常处理记录，并同时保持NSEH的完整性。因此，修改必须精确，且结构化异常处理记录的堆栈地址必须泄漏。要让泄露发生，我们就必须对堆栈进行扫描并查找到结构化异常处理链，在确定我们已经找到之后，我们就可以验证最终的异常处理程序是ntdll！FinalExceptionHandlerPadXX。由于ntdll！FinalExceptionHandlerPadXX函数在应用程序重新启动时发生更改，因此泄漏要分两步执行，首先找到正确的最终异常处理函数，然后再找到结构化异常处理链。为了获得第一个泄漏，我们要在ntdll！_except_handler4中搜索堆栈，因为只有在ntdll！_except_handler4的上下搜索中才会碰到第一个泄漏。

接下来，便是找到ntdll！_except_handler4的地址，但是这是很容易的，因为可以从任何受CFG保护的函数中找到ntdll.dll的指针，并且还包含一个间接调用。 CFG验证包含对ntdll！LdrpValidateUserCallTarget的调用，并且由于jscript9.dll受CFG保护，任何间接调用的函数都包含直接指向ntdll.dll的指针。在TypedArray对象的虚拟函数表的偏移0x10处，就存在一个这样的函数。