网站 › 『软件调试区』 › 【Office漏洞 第二弹】CVE-2018-0798及利用样本分析

ERFZE 发表于 2020-4-6 12:39

【Office漏洞 第二弹】CVE-2018-0798及利用样本分析

## 0x01 漏洞描述

- **成因**：`EQNEDT32.exe`在解析Matrix record时，并未检查长度，从而造成栈溢出。无论打不打CVE-2017-11882补丁都可以成功触发，使得攻击者可以通过刻意构造的数据内容及长度覆盖栈上的函数返回地址，从而劫持程序流程。

- **影响版本**：Microsoft Office 2007, Microsoft Office 2010, Microsoft Office 2013,Microsoft Office 2016

- **POC**：(https://github.com/houjingyi233/office-exploit-case-study/blob/master/CVE-2017-11882%26CVE-2018-0802%26CVE-2018-0798/cve-2018-0802%20poc%20with%20comments.rtf)

## 0x02 漏洞分析

> 笔者复现及分析环境：Windows 7 Service Pack 1、Microsoft Office 2010、x64Dbg、IDA 7.0(EQNEDT32.exe已打CVE-2017-11882补丁，但笔者分析时关闭了ASLR)

#### 0x02.1 静态分析

漏洞位于`sub_443E34`内：


其调用了两次`sub_443F6C`，但`sub_443F6C`在复制数据时并未检查传递进来的参数：


其中的数据长度可通过`a1`控制，具体计算方法是`(2 * a1 + 9) >> 3`，而其目的地址是由`sub_443E34`传递过来位于其开辟栈空间内的局部变量(`int`型)：


如此一来，便可通过精心构造的数据，覆盖`sub_443E34`函数的返回地址，进而控制执行流。

#### 0x02.2 动态调试

POC地址已于上文给出。直接于`sub_443E34`处设断，成功断下后，直接执行到调用`sub_443F6C`前查看其传递参数：


跟进查看，可以看到其计算后的实际复制数据长度：


跟进其调用的`sub_416352`可以查看要复制数据：


直接执行到`sub_443F6C`结束处，可以看到：


`sub_443E34`再次调用`sub_443F6C`，其执行流程同上：




可以看到，已经覆盖栈上`sub_443E34`的返回地址，劫持了执行流：


回到`sub_443E34`，直接执行到结束处：


通过ROP跳转到`WinExec()`：


成功弹出计算器：


## 0x03 Bitter组织某样本分析

> 样本名称：Urgent Action.docx
>
> 样本MD5：02C2A68CE9A35F5F0E1B3456E09D6CC9

通过远程模板注入的方式下载一RTF格式文档：


使用WinHex查看，确为RTF格式：


添加`.rtf`后缀后打开文档。直接来到`sub_443E34`调用`sub_443F6C`处：


此次调用`sub_443F6C`并未发生溢出，其复制数据长度如下：


复制内容：


其第二次调用`sub_443F6C`，发生溢出：


复制内容：


接下来直接执行到`sub_443E34`结束处，可以看到其劫持执行流：


通过ROP跳转到Shellcode：


Shellcode如下：


下面开始分析其功能。首先是计算跳转地址：


跳转之后，通过与计算出的EAX值比较的方式移动指针指向要复制的Shellcode，复制后跳转到Shellcode上执行：


通过PEB手动符号解析定位到`kernel32.dll`：


定位`kernel32.dll`中的`GetProcAddress()`函数：


跳转后执行`GetProcAddress()`：



之后通过`call`调用的形式给`CreateDirectory()`传递参数：


于C盘创建一名为Temp的文件夹。获取`LoadLibrary()`调用地址：


之后在`call`调用的同时传递参数：



接着再次`call`调用，先修正内存中的字符串，接着获取`URLDownloadToFile()`函数调用地址：



通过两次`call`调用来给`URLDownloadToFile()`函数传递参数：




之后调用`URLDownloadToFile()`函数从http://maq[.]com[.]pk/wehs下载文件到创建的Temp文件夹内，文件名为`smss`：


`call`调用的同时向`GetProcAddress()`传递参数，获取`MoveFile()`调用地址：


两处`call`调用向`MoveFile()`传递参数：


将`smss`重新命名为`smss.exe`。之后获取`LoadLibrary()`调用地址：


`call`调用的同时传递参数：


获取`ShellExecute()`调用地址：


通过三次`call`调用来给`ShellExecute()`传递参数，最后调用之：


接下来执行的`smss.exe`，非本文重点，故不分析。

## 0x04 xx组织某样本分析

> 写文章截图的时候中途断过两次，故前后文某些地址(使用这些地址只是为了方便说明)不对应，望读者谅解。
> 另，此样本在打了CVE-2017-11882补丁的机器上无法被成功利用。

直接定位到漏洞触发点：




第二次调用`sub_443F6`过程如下：




可以看到，栈上函数返回地址已经被覆盖：


但其并未直接执行到`sub_443E34`结束处，而是通过给其后调用的函数传参，再次执行`sub_443E34`(其调用函数的具体功能可结合IDA进行分析)：






下面来看第二次执行`sub_443E34`时调用`sub_443F6`的情况：







直接执行到`sub_443E34`结束处：


其后执行流程：


此处的`jmp 2911D4`值得说明一下，`2911D4`后20字节是在调用`sub_4428F0`时由`qmemcpy((void *)(v5 + 50), a4, 20u);`复制而来，其中源地址是0x18F3EC(可见图片54)。

计算接下来的跳转地址：


跳转到解密Shellcode部分：


解密Shellcode：


其后执行流程见下图(图中序号仅为表明顺序，并无他意)：


手动符号解析定位`msvcrt.dll`(由`cmp`语句比较的ASCII码可计算出)。


手动符号解析定位`kerner32.dll`(图中序号接上一张图片)

之后其调用的`sub_299122`如下：


通过遍历`msvcrt.dll`的输入表查找`GetProcAddress`，它并非调用`kernel32.dll`的`GetProcAddress()`，而是`ntdll.dll`的`LdrGetProcedureAddress()`：


再一次调用`sub_299122`，此次查找的是`VirtualProtect()`：




调用`GetProcAddress()`返回`msvcrt.clearerr`的地址：


调用`VirtualProtect()`修改`msvcrt.clearerr`页属性为0x40(PAGE_EXECUTE_READWRITE),大小是0x50：


对`msvcrt.clearerr`进行Inline Hook，修改指令长度为0x50，这解释了之前的修改页属性操作：


其实`msvcrt.clearerr`要实现的功能与`sub_6492C6`相同(详见图片77、78)：


调用`VirtualProtect()`修改`msvcrt.clearerr`页属性为0x20(PAGE_EXECUTE_READ),大小是0x50。


将返回的调用地址加5后，通过遍历`msvcrt.dll`的输入表查找`CreateFile`：



此次是查找`VirtualAlloc`：


接下来所查找函数不一一截图，依次是`ReadFile`、`WriteFile`、`CloseHandle`、`CreateProcess`、`GetModuleFileName`、`ResumeThread`、`TerminateProcess`。


其后传递给GetProcess的参数不再一一截图，依次是`ReadProcessMemory`、`VirtualQueryEx`、`VirtualProtectEx`、`GetModuleHandle`、`VirtualAllocEx`、`WriteProcessMemory`、`SetThreadContext`、`ZwUnmapViewOfSection`。

调用`GetTempPath()`：


之后将其于临时文件夹内释放的文件名拼接到路径后：


打开该文件：


其后行为不再一一截图，依次是`GetFileSize`(获取该大小)、`VirtualAlloc(0,0x3E000,0x3000,0x40)`(分配空间)、`ReadFile`(读取文件到分配的空间内)。

解密内存中的文件内容：


遍历文件句柄，找到符合下列条件的文件：



调用`VirtualAlloc`分配空间并写入内容(并非解密后的文件内容)：




复制解密后的文件内容：


之后创建一同名进程：



其后的部分行为见下图：




将解密后的文件内容写入创建的进程：


最终，结束原进程：


解密后的文件会在临时目录释放两个文件("白加黑")并运行之：


## 0x05 参考链接

- [手把手教你复现office公式编辑器内的第三个漏洞](https://www.anquanke.com/post/id/94841)

天空藍 发表于 2020-4-7 19:52

本帖最后由 天空藍 于 2020-4-7 19:55 编辑

图片较多，文字极少。一篇展示文而已。低价值的文章，不推荐阅读与加精。{:1_925:}

ERFZE 发表于 2020-4-8 10:00

天空藍 发表于 2020-4-7 19:52
图片较多，文字极少。一篇展示文而已。低价值的文章，不推荐阅读与加精。

请问什么样的文章适合加精呢？？

jxncyk 发表于 2020-4-6 13:45

大佬的神帖子

女萝岩 发表于 2020-4-6 13:59

可以，可以，看了楼主两个帖子，很详细。

jimy125 发表于 2020-4-6 14:43

这神技术贴，难得看完{:1_907:}

xiaoqu525 发表于 2020-4-6 15:50

大佬牛逼，吾辈楷模啊

sxxujunfeng 发表于 2020-4-6 16:07

学习学习，大有收获

yywapj 发表于 2020-4-6 16:13

赶紧膜拜下，不要说破，看都晕啊{:1_921:}

zhucha 发表于 2020-4-6 19:06

厉害呀。膜拜

chkds 发表于 2020-4-6 19:40

后排膜拜大佬.jpg

处女-大龙猫 发表于 2020-4-6 21:37

第一期都没看懂

查看完整版本: 【Office漏洞 第二弹】CVE-2018-0798及利用样本分析