翻译:myswsun
预估稿费:170RMB
投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿
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。
发表评论
您还未登录,请先登录。
登录