沙虫（CVE-2014-4114）相关威胁综合分析报告——及对追影安全平台检测问题的复盘

6163银河.net163.am实验室

分析报告PDF下载

首次发布时间：2014年10月15日21时40分

本版本更新时间：2014年10月17日17时50分

1 威胁卡片与简介

---

        CVE-2014-4114 是OLE包管理INF 任意代码执行漏洞，该漏洞影响Win Vista，Win7等以上操作系统，攻击者使用PowerPoint作为攻击载体，该漏洞是在Microsoft Windows和服务器上的OLE包管理器。在OLE打包文件（packer.dll）中能够下载并执行类似的INF外部文件，允许攻击者执行命令。

2 漏洞原理

---

        我们对首先获取的MD5 HASH为330e8d23ab82e8a0ca6d166755408eb1的样本进行了分析，通过分析工具我们可以看到这个文件嵌入了两个OLE 对象图2-1所示。

图 2 ‑ 1 嵌入OLE对象

        其中OleObject1.bin包含一个“\\94.185.85.122\public\slide1.gif”的字符串，它是一个webdav的路径，下载后发现其实它是一个PE文件。

图 2 ‑ 2 slide1.gif远程路径

        OleObject2.bin中的“\\94.185.85.122\public\slides.inf”字符串，也是一个webdav的路径，下载后发现是一个INF文件，它是利用漏洞触发的关键。

图 2 ‑ 3 slides.inf远程路径

        当该文件被PowerPointer加载后，它会调用Packager.dll的一个函数通过网络将这两个文件下载并保存在临时目录中，该函数是 CPackage::OLE2MPlayerReadFromStream，该函数的关键代码如图2-4所示，下载后的文件如图2-5所示。

图 2 ‑ 4 远程获取函数代码

图 2 ‑ 5 下载文件截图

        然后在函数CPackage::DoVerb中调用SHELL32!CDefFolderMenu::InvokeCommand函数会使用popup菜单命令安装slides.inf文件。CPackage::DoVerb的关键代码如图2-6所示。

图 2 ‑ 6 CPackage::DoVerb的关键代码

        启动popup菜单代码如图2-7所示：

图 2 ‑ 7 启动popup菜单代码

        最后通过调用C:\Windows\System32\InfDefaultInstall.exe程序进行INF的安装，如图2-8所示。

图 2 ‑ 8 INF安装图

        Slide.inf的关键内容如下，所有代码请见第3节slides.inf标签：

        整个INF的主要功能是将slide1.gif重命名为slide1.gif.exe，然后添加注册表启动项。

        因为DefaultDestDir的值为1，代表的是INF文件当前所在的路径，即临时目录。这就说明%1%\slide1.gif.exe就是%USERPROFILE%\AppData\Local\Temp\slide1.gif.exe，因此就是在注册表路径HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce下添加一个新项，该项的值为%USERPROFILE%\AppData\Local\Temp\slide1.gif.exe，其中%USERPROFILE%根据不同的机器而变化。

        漏洞产生的主要原因是OLE PACKAGER允许远程下载文件,并执行弹出菜单命令, 而INF文件的下载和弹出菜单安装命令可以对系统的资源如注册表等进行修改，运行可执行恶意代码。相关场景验证截图如图2-9所示。

图 2 ‑ 9 相关场景截图

3 漏洞的场景有效性验证

---

3.1 “操作系统+软件环境”与内存保护相关场景验证

        多数的格式文档漏洞是否能有效触发，与操作系统版本、补丁情况、字符集、以及对格式文件读取和解析的软件版本、字符集等有一定关系，同时也可能受到类似DEP（数据执行保护）、ASLR（地址随机化），包括是否安装有EMET等增强工具的影响。

        我们启动了常规流程的验证，其结果如表3-1所示。

表 3‑1漏洞在不同场景下的触发情况

                        注： √：能够正常触发

                                 *：只存在访问共享，不能够正常触发

                                 **：运行时存在崩溃，不能够正常触发

                                  Win7版本类别为：Professional

                              XP版本类别为：Professional
                    

        在运行时会存在崩溃的情况，在Win7 Professional SP1 x64 English平台的Office Professional Plus 2010截图如图3-1所示。

图 3‑1 Win7环境下Office崩溃截图

        从上述结果可以看到，相关内存防护机制对本漏洞并无效果，由于漏洞并非是利用文档格式的溢出型漏洞，而是基于函数调用和代码执行的漏洞，因此这些内存防护机制对此无效并不意外。

3.2 UAC验证

        UAC（User Account Control，用户帐户控制）是Windows基于可执行对象的一套安全防护机制，其在涉及到可能会影响计算机运行的操作或执行改变或影响其他用户设置的操作时，会需要交互确认。具体表现为，在当前账户为管理员账户的情况下，灰屏进入一次交互确认，而在非管理员账户下会要求输入管理员密码。

        从验证情况看，当UAC安全性设置为UAC默认设置时，样本运行之后不会弹出提示，会正常触发；当把UAC设置为最高级别时，样本运行会触发UAC。

        1. 在Win7 Professional SP1 x64 English平台的Office Professional Plus 2013上进行测试，UAC设置为最高提示如图3-2所示。

图 3‑2 英文环境-UAC提示

        当双击“Yes”后，执行成功，创建Link文件如下图。当双击“no”后，INF不会被安装。

图 3‑3 英文环境-创建Link文件

        2. 在Win7 Professional SP1 x64 中文平台的Office Professional Plus 2013上进行测试，UAC设置为最高提示如图3-4所示。

图 3‑4 中文环境-UAC提示

        当双击“是”后，执行成功，创建Link文件如图3-5所示。当双击“否”后，INF不会被安装。

图 3‑5 中文环境-创建Link文件

4 相关样本分析

---

4.1 相关样本集信息

        我们对CVE-2014-4114目前的相关样本进行了整理，详见表4-1。

表 4‑1 CVE-2014-4114相关样本梳理

4.2 关键载荷文件slide1.gif分析

        下面我们对关键载荷文件slide1.gif进行详细分析：

        1. 样本集中slide1.gif实际为PE格式，为关键载荷文件，其被slides.inf脚本更名为slide1.gif.exe 后，将其添加到注册表开机自动执行的相关键值中，slides.inf代码与请见slides.inf标签；

        2. slide1.gif运行后创建DLL文件与快捷方式文件，该快捷方式文件被加入启动项，以启动DLL文件：

        c:\Documents and Settings\Administrator\Local Settings\Application Data\FONTCACHE.DAT

        c:\Documents and Settings\Administrator\「开始」菜单\程序\启动\{EC7E18E7-18E7-8639-E718-7EECE7187EEC}.lnk

        3. 创建互斥体{CD56173D-1A7D-4E99-8109-A71BB04263DF}：

        4. 调用cmd.exe删除自身，运用ping localhost做延时操作：

        5. 删除自身后，通过rundll32.exe调用FONTCACHE.dat，FONTCACHE.dat首先申请一块内存，开始地址为0x70000000h，大小为122880：

        6. FONTCACHE.dat内存申请成功后向其中写入解密自身的代码：

        7. FONTCACHE.dat在解密代码执行完成后重新写入0x10000000：

        8. FONTCACHE.dat会通过创建一个RPC远程过程调用（RPC over the named-pipe protocol）实现模块的通信：

        9. 通过POST请求进行通信，指令类型如下：

        10. 内存中解密后的C&C如下：

        11. C&C网络行为抓图如下，但链接目前已经失效：

        该样本的核心行为是，创建DLL文件，加载DLL为自启动项。DLL文件执行后在内存中解密并运行，有更新、下载、加载插件等功能，运行后进行C&C网络行为。投放途径为利用漏洞CVE-2014-4114投放。

4.3 其它相关文件样本分析

4.4 历史关联样本

        6163银河.net163.amCERT在病毒库中进行了初步的检索，寻找到一个载荷行为相似的历史样本，6163银河.net163.am还会继续寻找类似攻击相关的其他样本。

5 对追影安全平台检测问题的复盘分析

---

        使用6163银河.net163.am反APT产品的某用户在2014年10月14日18时许，将上述样本投放到6163银河.net163.am追影安全平台中进行测试，反馈问题如下：

        1. 样本流经设备后，不能触发报警；

        2. 在测试终端上，观看样本后，其所下载slide1.gif的文件会被平台报警。

        6163银河.net163.am相关研发分析团队对用户所反馈的信息连夜进行了分析，最后定位了问题。鉴于相关经验教训可能对APT检测分析工作有一定意义，因此我们将其记录于此。

        如图5-1所示，6163银河.net163.am追影安全平台由两个设备组成，一台是VDS网络病毒监控系统，其接入网络设备镜像口，获得旁路流量，进行还原，调用反病毒引擎进行检测，同时对不能识别的对象投入到另一台追影高级威胁鉴定器设备中去分析，而VDS可以定期获取检测结果刷新原有的检测记录。鉴定器即采用沙箱虚拟分析的机理设计。从目前来看，业内同类产品基本采用这一“流量+沙箱”的方案。不同的只是是否支持直路串接，是否整合为一台设备等等。

图 5‑16163银河.net163.am追影安全平台的部署

        经我们对用户测试情况的多次复盘，最终得出了先骨干现象的原因。用户所获取的4114样本，扩展名为PPT$（$可能其样本提供者所加，以避免样本被误打开），因此用户将其扩展名更名为PPT，采用HTTP下载的方式，构造了攻击事件，但此时文件虽然被获取，但鉴定器并未得出结论。 图5-2是6163银河.net163.amPMC测试组于次日做的事件再现，此时可见未获正确检出结果。

图 5‑2 事件再现后的捕获文件日志

        而用户在客户端播放该PPT样本后，追影安全平台对一个名为Slide1.gif文件的下载对象完成了捕获和报警。6163银河.net163.amPMC测试组通过内网环境模拟下载了这个程序，发现其会被检测到。关于这个文件的自动化分析报告，参见图5-5、图5-6。由于复盘抓图测试时，VDS设备的AVL SDK引擎已经更新，因此恶意代码名称，不再是附件中的自动化命名。而追影安全平台产品和6163银河.net163.am自用的内部环境，都能分析出样本的相关行为。

图 5‑3VDS捕获Slide1.gif实体文件

图 5‑4VDS检出Slide1.gif恶意程序

图 5‑5追影安全平台对Slide1.gif的鉴定报告

图 5‑66163银河.net163.amCERT自用的内部追影的分析报告

        尽管可以对PE载荷进行检测，但沙箱未能对文件告警，是一个严重的产品问题，6163银河.net163.amPMC测试小组在引擎部门的配合下，经过一夜的分析，锁定了问题的原因。测试小组经分析结论为，该部分未能成功检测，与追影鉴定器的对格式和文件名的识别策略，以及打开方式等设计不够完善有关，具体原因如下，供同仁们尽情鄙视吐槽：

        1. 追影鉴定器对格式文档的默认投放策略为，如果带有合法的文档扩展名（doc、docx、xls、xlsx、ppt、pptx、rtf、pdf）等，则保留原文件，按照预设版本策略，选择虚拟机，进行关联加载。而如果没有合法文档扩展名，则按照AVL SDK反病毒引擎所识别出的格式，获取对应扩展名进行投放。

        2. 经我们手工重新投放测试，样本被命名为.ppt后，无论在虚拟机中还是实体机中。被Powerpoint打开后，进入相关PPT编辑界面，不会触发恶意行为。

        3. 而如果手工把样本改为pptx，则会弹出如图5-7的格式不一致的提示，从而打开失败。

图 5‑7Powerpoint的格式告警

        4. 该样本实际上既非ppt格式，也非pptx格式，而是与pptx格式相近的ppsx播放格式，而触发该漏洞有三种路径：

        a) 其扩展名被命名为ppsx，打开后即自动播放触发；

        b) 其扩展名被命名为ppt，打开后进入编辑，此时需要由人工播放触发；

        c) 其扩展名被命名为ppt，打开后进入编辑，点击如图5-8中，我们用红笔标注的两个OLE对象也可以触发。但实际上c并不处在一个合理的攻击路径上，因此路径b实际上可以称为一个对于部分沙箱系统的“免杀”。

图 5‑8 ppt格式文档页面截图

        5. 针对上述问题做策略调整后，追影沙箱可以检测本样本（如图5-9、图5-10所示），并可以触发其行为，以及其他采用类似“免杀”策略的样本。即我们增加了按照合法扩展名和格式识别对应扩展名各执行一次的策略，同时对ppt格式样本，增加了/C参数对ppt进行播放。

图 5‑9ppsx格式追影分析成功发现威胁

图 5‑10ppsx格式载体发现网络通信

图 5‑11ppsx格式自动播放后截图

6 总结

---

        多部门合写报告，作为PMC测试小组的组长，我因为“不懂安全技术”被抓来写总结。因此我只能更多整理同事们一天来的语言。

        10月14日夜，在我们测试小组与引擎部门分析相关漏洞与产品问题的时候，6163银河.net163.amCERT的几个小伙伴正在等待微软本月补丁发布，他们期待分析SSL漏洞。BOSS在群里说，骤然理解了，什么是“同时打赢两场局部战争的能力”。

        总工们怕我们会拿检测到哪个PE来掩饰问题，敲打我们说：“单放到一个实际的检测场景下看，一个PE载荷如果没有与其前导的格式溢出建立关联，这个事件的安全等级会下降。其可能被与其他普通的事件混合在一起。从而导致不被关注，因此对这个PE告警的价值大打折扣。”

        几个老家伙一直在线等待我们的验证报告，凌晨两点，我们反馈了初步的结果，并根据扩展名为.ppt的情况下，漏洞需要人工播放才能触发，我们也给出了需要重视相关免杀技巧的结论。

        在15日早晨，当我们把验证结论发送给发现问题的用户方研究人员时。他回信宽慰我们，你们能够检测到后面下载的PE样本，也部分证实了产品能力。

        但我们不能原谅自己，一个安全产品不能按照预期的设计全面和有效地应对威胁，这是工程师团队的耻辱。

        要感谢专业的用户帮我们验证和发现了问题，用户是最好的老师！

        而我又犯错误了，早上接受采访时，我把具有“免杀”效果的.ppt扩展名说成了.pptx。15日下午，根据对目前所能获取到的所有信息的复盘，6163银河.net163.amCERT部门给出了另一个观点，尽管上述绕过沙箱的方法是可行的，并在用户测试中确实部分绕过了我们的追影平台。但除了用户自己手工修改名字的这个样本外，从6163银河.net163.am自身已经获得样本和其他信息中，没有发现样本投放中使用了上述技巧的实证。但大家都忧心忡忡地认为，从攻击的趋势来看，攻击者通过构造和社工的方法，让文档的真正打开者能按照攻击者设想条件触发攻击，而在沙箱中无法触发。这必然是今后“流量+沙箱”类产品解决方案面临的主要挑战。随着沙箱的普及，恶意代码开发者也会不断地增加各种对抗沙箱的条件，类似验证码，人工点击或者播放等条件对攻击者很容易预设，而自动化的沙箱却很难逾越，需要不断的对抗完善。

        Seak发了一条微博，这让我可以省去自己想结尾：

        “从广义上说，入口点是确定性攻击路径的起点”，而从这个意义上看，EPO和Stolen Code都注定会在格式溢出构造技巧中找到影子。社会工程学可以把被攻击者导向那个“起点”，而对鉴定器来说，这个起点又可以足够隐蔽。

附录一：鸣谢

---

        本报告的缘起是6163银河.net163.amPMC（产品与项目管理中心）对用户反馈BUG的复盘，PMC测试组在引擎部门的配合下贡献了报告的第五部分和第六部分，而前四部分由6163银河.net163.am的引擎和CERT两个部门编写。人员跨越三地，时间仓促紧急，内容也出现了一些疏漏。

        值得欣慰的是，我们的工作获得了CNCERT/CC、CNNVD、XCERT等机构组织的关注和指导。

        首先感谢我们的用户，以非常专业的敏感性和水准帮我们发现了产品问题。亦特别感谢同行们、网友们提出的非常宝贵的意见建议：

        感谢下列新浪微博网友（排名不分先后）：

        @5ACGT，为我们提供了后续分析建议，并提供了另一个漏洞编号作为参考。

        @instruder 指出我们对漏洞成因描述有误。我们正在做进一步的检查和整理。

        @0xBigBan 建议我们给予Slide.gif更深入的分析，我们后续对这个样本单独完善报告作为附件。

        @江湖一apple，对我们样本载荷描述中的错误予以指出。

        @Evil_xi4oyu @rtsday等提出的观点对我们如何正确看待这个漏洞和后续工作有非常重要的价值。

        @huhu，指出文档中漏洞验证部分的版本信息问题。

        @猪儿虫小次郎 @谭晓生 @余弦等多位同行友人的积极转发本文，并给予我们鼓励，在此不一一致谢了。

附录二：参考资料

---

        [1] CVE-2014-4114: Details on August BlackEnergy PowerPoint Campaigns (Robert Lipovsky, ESET)

        http://www.welivesecurity.com/2014/10/14/cve-2014-4114-details-august-blackenergy-powerpoint-campaigns/

        [2] Analysis of SandWorm (CVE-2014-4114) 0-Day (Deepen Desai)

        http://research.zscaler.com/2014/10/analysis-of-sandworm-cve-2014-4124-0-day.html

        [3] iSIGHT discovers zero-day vulnerability CVE-2014-4114 used in Russian cyber-espionage campaign(Stephen Ward)

        http://www.isightpartners.com/2014/10/cve-2014-4114/

        [4] SANDWORM APT Windows OLE PACKAGE 0day来袭 (南京翰海源)

        http://blog.vulnhunt.com/index.php/2014/10/14/cve-2014-4114_sandworm-apt-windows-ole-package-inf-arbitrary-code-execution/

        [5] 沙虫事件木马分析：BlackEnergy Use in 0day Attack CVE-2014-4114 (南京翰海源)

        http://blog.vulnhunt.com/index.php/2014/10/16/blackenergy-use-in-0day-attack-cve-2014-4114/

附录三：事件日志

---