标签：exe 函数 11882 漏洞 地址 进程 2017 poc
CVE-2017-11882分析总结
注： 这篇随笔记录了CVE-2017-11882漏洞分析的整个过程，并介绍了相关调试软件的使用
漏洞信息
CVE-2017-11882属于缓冲区溢出类型漏洞，产生漏洞原因于EQNEDT32.EXE（微软office自带公式编辑器）进程在读入包含MathType的ole数据时，在拷贝公式字体名称（Font Name数据）时没有对名称长度进行校验，导致缓冲区溢出。通过覆盖函数的返回地址，可执行任意代码。
漏洞复现
1. 环境配置
- 操作系统：Window 7 专业版（64 位）
- office软件：office 2003 sp3 完整版 http://www.xz7.com/downinfo/36948.html
- poc：https://github.com/embedi/CVE-2017-11882
注意：office 必须是带有公式编辑功能的，所以不能下载精简版的office。其次，在安装时必须选择完全安装，防止漏掉公式编辑功能。
2. 流程
在配置好环境的虚拟机上，打开poc，双机exploit.rtf文件，能正常已启动office软件并弹出calc.exe 则成功触发漏洞。
漏洞分析
1. 定位漏洞
分析漏洞的第一步自然是定位漏洞。
第一步:
-
找到漏洞发生在哪个模块，但是第一步就遇到了问题。我用processhacker分析进程状态，可以看到WINWOED.EXE 和 calc.exe被创建出来，WINWOED.EXE由explore创建，这个没问题，因为我是双击的文件打开的。calc.exe由 cmd.exe创建，也没问题，说明poc应该是拉起cmd的同时命令行传参，打开calc的。看不到cmd的父进程，这个不合理，至少有一个进程之类东西负责拉起cmd。这里没显示，我感觉有可能是这个父进程把自己隐藏了，或者跑路了。
-
接着我选择用pchunter来检测进程，因为pchunter的检测能力较强。从pchunter中能找到所有进程对应的父进程，但是这个关键的cmd的父进程id：1872却找不到对应的进程。虽然找到了这个关键进程的id，但是还是不知道它是谁。推测大概率是这个1872进程已经结束了，它的生命周期非常短。
-
花了很长时间，找到了解决方法，使用process monitor。process monitor虽然没有process hack那种动态变色方便观察的功能，但是它有个树形控件，看到所有进程之间的关系。但是依旧是遇到了一些困难，官网下载的process monitor 无法在我这个win7虚拟机上运行，显示错误：无法加载设备驱动。一番百度之下，找到一个解决方案，给win7打上某个补丁就可以。但是我觉得这个方案不行，因为我是复现poc，要是随便打补丁的话，就没有意义了。
-
但是我记得几年前我用过这个软件，是没问题的，所以我去下载了一个老版本：2.5，于是可以正常运行。
-
点击这个树形控件之后，成功找到了1872这个进程：EQNEDT32.exe，并根据路径找到了文件地址。从这个监控可以看出，EQNEDT32进程已经变灰了，说明它已经结束了，存在的时间很短。
第二步：
- 定位是这个EQNEDT32哪个函数有问题。原文是用的OD分析的，我使用的是windbg。因为这个EQNEDT32是自动启动并且很快结束了，所以必须要能在它运行的第一时间就挂上调试器。这里有两个解决办法，第一个是利用windbg的小工具gflag。它和windbg在同一层目录。
- 我们调试的是应用层软件，所以选择image file，然后填写名字和调试器路径即可。
- 还有一个方法是直接写注册表，方法一实质也是写注册表
- 这样子，只要EQNEDT32进程被创建就会立即被windbg挂住。
- 根据poc可以弹出calc，可以猜测程序中调用了WinExec，CreateProcess之类的api，
注： 这上面的第一个断点是错误示范，我第一次下断点，输错了模块名，导致断点下不上， 一度以为是符号的问题，不能在这些系统api上下断点。 - 直接g命令，或者f5 运行，第一处断点就找到了WinExec，
- 查看函数栈，可以看到函数地址，以及参数。
- 其中 00430c18是 函数返回地址，0018354是函数参数，查看0018354这个地址里的内容，可以看见cmd.exe /c calc.exe 字样，说明找到了poc触发位置。
- 再次查看函数栈，发现调用者返回地址是004218。查看这个地址的汇编。
- 找到EqnEdt32.exe中存在漏洞的函数，至此定位到漏洞函数。
第三步：
- 分析漏洞原因。在ida中找这个函数，G + 004218df
- 找到这个函数sub_4115A7，开始静态分析可能存在漏洞的地方。
- 这个函数很短 没什么问题，查看sub_41160F
- 在sub_41160F可以发现有一个字符串拷贝函数未作长度检验，也没有使用安全函数。这个地方就是漏洞所在。
2. 分析漏洞利用
- ida分析发现实际存在字符串拷贝溢出的函数是sub_441160F，其地址为004115d3
- 再次运行windbg，在004115d3处下断点
- 进入这个函数，单步到字符串拷贝的地方
- 分析栈帧发现，目前都很正常，函数返回地址被正确保存。
rep movs dword ptr es:[edi],dword ptr [esi]是字符串拷贝的关键步骤，它将esi指向的地址里的内存拷贝给edi指向的地址，先5查看两者内存，到这步还是正常的。
- 但是参数的长度超过了申请的变量大小，执行该语句之后，覆盖了原始返回地址
- 新的地址00430c12 就是 exe中原有的winexec函数。
- 可见，这个poc没有在shellcode中执行跳转指令，而是直接找了现有的一个API函数，在正常流程return的时候，覆盖函数返回地址，插入了恶意代码。
漏洞补丁
- 微软已经对此漏洞做出了修复
下载https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11882 更新补丁进行修补 - 在注册表中取消该模块的注册
标签：exe,函数,11882,漏洞,地址,进程,2017,poc 来源： https://www.cnblogs.com/HsinTsao/p/15408412.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。