首页
社区
课程
招聘
[翻译]使用最新的代码重用攻击绕过执行流保护
发表于: 2017-5-1 17:20 10427

[翻译]使用最新的代码重用攻击绕过执行流保护

2017-5-1 17:20
10427

最新的漏洞利用开始渐渐脱离基于ROP的代码重用攻击。在过去的两年里,出现了一些关于一种新的代码重用攻击的文章,Counterfeit Object-Oriented Programming(COOP)COOP是一种顶级的针对forward-edge的执行流完整性(CFI) 的攻击方式。在我们把CFI解决方案(HA-FI)整合进我们的终端产品中时,这种攻击吸引了我们的注意力。COOP主要出现在学术界,还没有出现在exloit工具包里。这也许是因为攻击者更趋向于使用更简单的方法。在win10年度更新中微软的Edge使用了执行流保护(CFGControl Flow Guard)。在CFG中,缺少backward-edgeCFI更容易受到攻击。但是当Return Flow Guard (RFG)出现,使得攻击者不能再依靠淹没栈中的返回地址进行攻击的时候,会发生些什么呢?

 

我们对评估COOP在攻击CFI时的效果很感兴趣。这不仅可以使我们保持在学术界和黑客社区中前沿研究中的地位,也可以测试产品的有效性,更改设计,甚至在必要时普遍地提高我们自己的防御能力。在我们的这一系列的两篇博文中的第一篇中,介绍了我们使用COOP函数重用对微软的CFG以及我们自己的HA-CFI进行攻击的评测。


微软执行流保护


已经有大量的论文,博文和会议发言充分地讨论了微软的执行流保护(CFGMicrosoft’s Control Flow Guard)。Trail of Bits在两篇最近的帖子里比较了Clang CFI和微软CFG。第一篇帖子着重Clang,第二篇强调微软对CFI的实现,还有额外的研究提供了CFG的实现的进一步细节。

 

在过去的几年里,绕过CFG也成为了安全会议中中一个流行的主题。在我们引用一些著名的绕过方法之前,最重要的是CFI能够进一步分为两种:forward-edgebackward-edge

Forward-Edge CFI: 保护间接调用或是JMP位置. Forward-edge CFI解决方案包括微软 CFGEndgameHA-CFI.

Backward-Edge CFI: 保护返回指令. Backward-edge CFI解决方案包括微软的Return Flow Guard,EndgameDBI exploit防护的一部分, 以及包括intelCET在内的其他ROP检测。

这个分类帮助我们描绘出了CFG保护位置的轮廓——间接调用位置——以及不打算保护的位置——栈返回地址。例如,一个最近的POC入选了exploit工具包,这个POC针对Edge,使用读/写的原始方法来修改栈中的返回地址。但这并不适用于CFG,不应该作为CFG的弱点来考虑。尽管如此,它成功地证明了CFG的有效性,并使攻击者转向劫持执行流,而不是间接调用的位置。这个例子实际上证明了CFG缺陷包括以下几点:利用未受保护的函数调用位置,重映射包括CFG代码在内的只读内存区域,并使他们指向需要受到检查的代码,在Charka中提到的JIT编码器的资源竞争,使用基于内存的间接调用。COOP或是函数重用攻击,在面对CFI的实现时有着公认的局限,因为“limitations of coarse-grained CFI”,他们并没有入选微软的bypass赏金。也就是说,我们不知道有哪些公有领域的POCs能证明COOP能指定攻击CFG的加固的二进制代码。

CFG对每个受保护的DLL添加了一个__guard_fids_table,它由一系列在二进制代码中合法的RVAs或是间接调用指令中敏感的目的地址组成。一个地址作为CFG bitmap索引的一部分而存在。bitmap里的bits能够根据地址是否是合法的目的地址而进行切换。在此之外,也有一个API能够对bitmap进行修改,例如,为了支持JIT编码的页面:

kernelbase!SetProcessValidCallTargets在使用系统调用更新bitmap之前会调用ntdll!SetInformationVirtualMemory

win10创意者更新有一项新增的功能可以抑制导出,也就是说,现在导出函数能在CFG保护的调用位置被标记为非法目的地址。这一功能的实现需要使用CFG Bitmap中每一个地址的第二位,以及在初始化每个进程的bitmap__guard_fids_table中每一个RVA条目的一个标记字节。

对于64位的系统,地址的第9-63位被用于在CFGbimap中检索一个qword,第3-10位被用于(模64)访问qword中某一指定位。在导出被抑制后,CFG允许一个给定的地址在CFG bitmap中用两位表示。此外,在大多数DLLs__guard_dispatch_icall_fptr现在被设置为指向ntdll!LdrpDispatchUserCallTargetES,在其中一个合法的调用目标必须从CFG bitmap中删去。


当你把动态解析符号表考虑进去的时候,实现这样一个导出表抑制变得有点复杂,因为使用GetProcAddress意味着随后的代码也能调用返回值作为函数指针。只要CFG bitmap中每一个条目没有被标记为敏感的或是不合法的(例如,VirtualProtect, SetProcessValidCallTargets等等),执行流保护可以通过把条目对应的两位从“10”(导出表抑制)改为“01”(合法的调用位置),解决这个问题。最后,一些导出表将会在进行创建时以不合法的间接调用开始,但最终在运行时代码中成为合法的调用目的地址。在今后我们的讨论中,这尤为重要。当这一情况发生时,一个调用栈的样例如下:

00 nt!NtSetInformationVirtualMemory

01 nt!setjmpex

02 ntdll!NtSetInformationVirtualMemory

03 ntdll!RtlpGuardGrantSuppressedCallAccess

04 ntdll!RtlGuardGrantSuppressedCallAccess

05 ntdll!LdrGetProcedureAddressForCaller

06 KERNELBASE!GetProcAddress

07 USER32!InitializeImmEntryTable


COOP概要

Schuster et al.认为COOPCFI实现的一个潜在的弱点。为了在绕过forward-edge CFI的检查之后执行代码,我们可以利用连续的攻击序列和重用已存在的虚函数。在ROP在有一个相似的方法,其结果是一系列小段合法函数,每一段代码实现最低限度的功能(例如,载入一个值进RDX中),但把它们组合在一起,却可以实现一些复杂的任务。COOP的一个基本组成部分就是利用主循环函数,在其中可以迭代对象链表或数组,调用每个对象中的虚函数。然后,攻击者把内存中“伪装”的对象组合起来,在某些情况下,可能会覆盖对象,这样就能在主循环中按攻击者安排好的顺序调用合法的虚函数。Schuster et al.证明了使用COOP payloads的攻击win7 32位和64位上的IE10,以及Linux 64位上的Firefox的方法。这项研究随后被扩展了,证明了递归或是带有许多非直接调用的函数也可以实现这一过程,而不仅仅是循环。随后又继续被扩展到用于攻击Objective-C 运行时环境。

这项前沿研究极其有趣和新奇。我们想要把这一概念应用到一些现代的CFI实现上,以对如下方案进行评估:a)在加固的浏览器中构造一个COOP payload的难度;b)是否能绕过CFGHA-CFIc)是否能改进CFI使其能检测到COOP类型的攻击。


我们的目标


我们使用COOP主要的目标是win10Edge,因为它代表着一个全新的CFG加固应用,并且它能让我们在内存中使用JavaScript来准备我们的COOP payload。弱点始终是我们小组的兴趣,为了这个目标,我们专注于劫持CFI的执行流,并对攻击者作出了下列假设:

1.任意的读-写原语都是从JavaScript中获得的。

2.因为在运行时动态地找到小段代码不是这项研究的内容,因此,允许使用硬编码偏移量。

3.所有微软创意者更新中最近的防御机制都能被使用(例如,ACGCIG,带导出表抑制的CFG)。

4.除了使用COOP以外,攻击者不允许以任何方式绕过CFG

在我们最初的研究里,我们在对微软年度更新(OS build 14393.953)中的Edge的研究中利用了一个Theori中的POC,我们使用创意者更新中的防御机制设计我们的payload,并在开启导出表抑制的win10创意者更新(OS build 15063.138)中对其进行验证。

一个理想的POC会执行一些攻击者的shellcode或是启动一个应用程序。攻击者的一个经典的代码执行模型,就是把一些内存中被控制的数据映射为+X,然后跳转到包含最新修改过的+X区域的shellcode。然后,我们的真实目的是在forward-edge CFI的保护下,产生一个能够执行一些有意义的代码的COOP payloads。这样一个payload提供了能够进行测试和改善我们的CFI算法的数据。进一步说,攻击Arbitrary Code Guard (ACG)或是Edge的子进程的办法超出了我们的研究范围。我们确定对于win10创意者更新研究的最终目标是使用COOP来使CFG无效,使得在DLL内能够跳转或是调用任意位置的代码。因此,我们总结出下面两个主要的COOP payloads

1.对于win10年度更新,以及缺少ACG保护的程序,我们的payload把我们的控制的数据映射为可执行的代码,在使得CFG无效后跳转到我们控制的shellcode所在区域。

2.对于win10创意者更新,我们的最终目标是仅仅是使CFG无效。


寻找COOP片段


下列Schuster et al.设想的蓝图,我们的第一业务是商定COOP各个组成部分的术语。学术论文将每个重用函数称为虚函数片段(virtual function gadget)或是vfgadget,当我们描述每一个特定类型的vfgadget时使用缩写,例如将主循环(main loopvfgadget称为ML-G。我们选择以更为非正式的方式来命令每种类型的gadget。在接下来的帖子中你能找到的术语定义如下:

Looper:对于执行复杂COOPpayloads(论文中的ML-G)至关重要的主循环gadget

Invoker:一个调用vfgadget的函数指针。(论文中的INV-G

Arg Populator:带一个参数的虚拟函数,它将一个值加载到寄存器中(论文中的LOAD-R64-G),或是移动栈指针或是把值加载进栈中(论文中的MOVE-SP-G

与论文相似,我们编写了脚本来帮助我们识别二进制中的vfgadgets。我们使用了IPA Python,推理帮助我们找到了loopersinvokersargument pupulators。在我们的研究中,我们发现了实现COOP的实用的方法就是,在返回到JavaScript之前,把vfgadgets链接到一起并依次执行少量的vfgadgets。根据需要通过额外的COOP payloads重复这个过程。因此,为了我们的目的,我们发现没有必要将二进制代码提升到IR。然而,将大量COOP payload拼接到一起,比如说完全通过重用代码运行一个C2 socket线程,也许会需要提升到IR。对于vfgadget的每个子类型,我们定义了一系列规则,并使用它在Edgechakra.dlledgehtml.dll)的两个二进制文件间进行搜索。这些规则中与looper vfgadget相关的一部分包括:

1.出现在__guard_fids_table中的函数

2.包含一个不带参数的间接调用的循环

3.循环不能影响到参数寄存器


vfgadgets的所有类中,搜索loopers是最耗时的。许多潜在的loopers有一些限制使其难以使用。我们寻找到的invokers不仅需要有调用虚函数指针的vfgadgets,还要能够在单一的counterfeit对象中,一次性又快又容易地填充六个参数的vfgadgets。因此,当尝试调用单个API时,COOP可以使用快捷方式,完全避免对循环和递归的需求,除非需要返回值。在x64程序上能够找到许多寄存器对参数寄存器进行填充。值得一提的是,Schuster et al.COOP论文中根据mshtml提出的大量原始vfgadgets仍然能在edgehtml中找到。然而,我们在我们的成果中添加了一个要求来避免重用这些,而不是为我们的COOP payloads寻找新的vfgadgets


COOP Payloads


通过脚本语言触发COOP,我们实际上能把一些复杂的任务从COOP中移开,因为一次性把所有东西拼接在一起非常的复杂。我们能使用JavaScript来帮助我们,重复调用微型COOP payload序列。这也让我们能把诸如算术和条件操作放回JavaScript中执行,并保留基本的函数重用来为通过COOP调用重要的API做准备。此外,我们展示了这种方法的一个例子,包括在我们劫持到的#1 section中将COOP的返回值传回到JavaScript,并讨论如何调用LoadLibrary

为了简洁,我将只介绍最简单的payloadspayloads的一个公共的主题是需要调用VirtualProtect。因为VirtualProtecteshims(译者注:应该是ieshimsAPIs被标记为敏感的且在CFG中并不是一个合法的目的地址,我们不得不在创意者更新中使用包装函数。正如Thomas Garnier所建议的那样,可以在.netmscoree.dllmscories.dll中方便地找到包装函数,例如UtilExecutionEngine::ClrVirtualProtect。因为微软的ACG可以防止创建新的可执行内存,以及把已有可执行内存改为可写,因此,我们需要一个替代方法。使用VitualProtect可以把只读内存重映射为可写的,所以我借用了2015年黑帽大会里介绍的这种技术,并将包含chakra __guard_dispatch_icall_fptr的页面重新映射为可写,然后重写函数指针,使其指向包含jmp rax指令的chakra.dll中的任意位置。事实上,在大多数DLL中已经存在一个函数__guard_dispatch_icall_nop,它刚好就是一个单一的jmp rax指令。因此,我就能有效地绕过CFG的保护,因为在通过了所有检查之后,在chakra.dll中所有被保护的调用位置将立即跳转到目的地址。想必我们可以采用这种方法进一步探索使用函数重用攻击ACG的方法。为了完成这个小小的链接过程,需要以下满足以下条件:

1.mscoroc.dll载入进Edge进程

2.chakra.dll的只读内存区域调用ClrVirtualProtect +W

3.重写__guard_dispatch_icall_fptr以通过检查

从上面的vfgadgets列表可以看出,对于COOP来说edgehtml是一个重要的库。因此,我们的第一任务就是泄漏edgehtml的基址以及其他必要的组件,例如我们的counterfeit内存区域。这样,payload就能包含硬编码的偏移并在运行时重新定位。使用TheoriPOC中泄漏的bug,我们就能获得我们想要的基地址。

//OS Build 10.0.14393

var chakraBase = Read64(vtable).sub(0x274C40);

var guard_disp_icall_nop = chakraBase.add(0x273510);

var chakraCFG = chakraBase.add(0x5E2B78); //_guard_dispatch_icall...

var ntdllBase = Read64(chakraCFG).sub(0x95260);

 

//Find global CDocument object, VTable, and calculate EdgeHtmlBase

var [hi, lo] = PutDataAndGetAddr(document);

CDocPtr = Read64(newLong(lo + 0x30, hi, true));

EdgeHtmlBase = Read64(CDocPtr).sub(0xE80740);

 


[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!

收藏
免费 1
支持
分享
打赏 + 2.00雪花
打赏次数 2 雪花 + 2.00
 
赞赏  CCkicker   +1.00 2017/05/08
赞赏  kanxue   +1.00 2017/05/07
最新回复 (7)
雪    币: 6112
活跃值: (1212)
能力值: (RANK:30 )
在线值:
发帖
回帖
粉丝
2
2017-5-2 15:05
0
雪    币: 393
活跃值: (150)
能力值: (RANK:110 )
在线值:
发帖
回帖
粉丝
3
真厉害。
2017-5-2 15:44
0
雪    币: 3736
活跃值: (3867)
能力值: ( LV4,RANK:50 )
在线值:
发帖
回帖
粉丝
4
屌炸天!
2017-5-2 19:04
0
雪    币: 773
活跃值: (315)
能力值: ( LV9,RANK:150 )
在线值:
发帖
回帖
粉丝
5
厉害,膜拜
2017-5-4 20:52
0
雪    币: 757
活跃值: (21)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
6
膜拜,
2017-5-5 09:41
0
雪    币: 583
活跃值: (147)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
7
不错。。。。好文要顶。不过  这让我想到了另一个思路就是  利用CFG  来保护我自己的程序 
2017-5-7 04:23
0
雪    币: 13
活跃值: (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
8
太过断了只能膜拜。
2017-5-10 16:41
0
游客
登录 | 注册 方可回帖
返回
//