这个漏洞刚出来时就分析过,当时大体弄明白了原理,但对不少细节和原理仍是只知其一;不知其二。后来开始找工做……今天终于有时间来把欠的这部分功课补上。 html
这个漏洞网上的各类中英文分析已经不少了,所以这里我只根据本身的状况作一个小的整理和总结,并将参考的各类相关资料贴上来供本身温故知新。python
首先,CVE-2014-4114这个逻辑漏洞的核心在于当PPT调用IPersistStorage接口的Load方法来加载storage对象(OLE复合文档)对应的OLE复合文档对象时,未对全部类型的复合文档进行MOTW(Mark On The Web)处理致使的。从而使得攻击者能够经过伪造OLE复合文档的CLSID来绕过MOTW保护。其执行过程以下图所示:安全
图1 执行路径[1]ide
CVE-2014-4114攻击样本中复合文档对应的CLSID [2]如图所示:工具
图2 CLSID学习
经过查询注册表,{00022602-0000-0000-C000-000000000046} 对应的是Video Clip。由图1可见,CPackage::Load调用了ReadClassStg来获取复合文档的文件类型,并根据CLSID分两类处理。spa
而样本中两个文档的类型都为0x22602(对应_CLSID_AVIFile),所以CPackage::Load调用LoadMMSStorage进一步处理。LoadMMSStorage内部根据具体类型,调用CPackage::OLE2SoundRecReadFromStream --> CPackage::CreateTempFileName --> CopyStreamToFile最终将文件写入临时目录。调试
由图1可见,CopyFileW和CopyStreamToFile以后,未将读取到文件进行MOTW处理,即未调用MarkFileUnsafe。orm
图3 MarkFileUnsafexml
---------------------------------------------------------------------------------------------------
MarkFileUnsafe
MarkFileUnsafe的做用是经过调用IZoneIdentifier::SetId来设置文件的Security Zone。此处设置的URLZONE值为3,即URLZONE_INTERNET类型(图4),从而标明此文件来自于其余计算机(图5)。
图4 URLZONE
图5 Security Zone
注意,Security Zone是经过NTFS文件系统的Alternate Data Streams (ADS)特性实现的,而不属于Windows的ACL机制。它经过给文件建立一个名为Zone.Identifier:$DATA的Alternate Streams来保存Zone信息。如图6所示。
图6 Zone.Identifier:$DATA
随后,当用户试图运行、安装此类文件时,Windows会检测文件的Zone信息,阻塞执行并弹出一个警告提示,提示用户将有不可信的文件执行。
图7 安全警告
---------------------------------------------------------------------------------------------------
最终,写入临时目录的slides.inf和slide1.gif未经MOTW处理,如图8所示。
图8 样本释放的文件
随后,PPT经过OLE复合文档对象IOleObject接口的DoVerb方法来响应终端用户的动做。这里PPT根据幻灯片xml的定义,调用DoVerb方法(iVerb == 3)。以下图所示
图9 slide1.xml
IOleObject::DoVerb()内部根据iVerb的值进行不一样的处理。当iVerb大于等于3时,执行流程来到图10所示的位置。其功能与“右键单击文件,在Popup菜单中选择第2个(3-2=1)选项来运行文件”一致,而对于inf文件,其Popup菜单第二个选项恰好为“安装”(如图11所示),所以最终经过InfDefaultInstall.exe安装了inf。
图10 IOleObject::DoVerb() with iVerb=3 [3]
图11 Popup菜单
MS14-060发布3天后,就爆出补丁依旧能够被绕过,并在野外发现了相应的样本。随后微软发布了临时解决方案Fix it (Security Advisory 3010060)在MS14-064发布前缓解漏洞利用。
首先,看一下MS14-060补丁的修补方案,经过二进制对比工具能够发现MS14-060只完善了全部类型复合文档的MOTW处理,以下图所示。
图12 添加MOTW保护 [1]
然而,本次漏洞的问题不止这一处,前面的分析已经指出攻击者能够同时经过操控“OLE复合文档的CLSID”和“xml中的OLE Verb”来改变执行流程。
但问题在于并非全部被“MOTW保护”标记的文件在打开时都会弹出警告窗口。例如从网上下载的docx、pdf、zip等等文件,打开它们时并不会被提示安全警告(注:docx等office文件会在保护视图模式下打开)。
图13 “MOTW保护”标记的文件
当安装相关的软件后,会在右键Popup菜单中注册快捷方式方便用户操做,如图14所示,当安装python后,针对*.py文件的Popup菜单第二项便为Edit with IDLE。当攻击者操控“xml中的OLE Verb”为3来使用“edit with IDLE”编辑打开*.py时,并不会获得安全警告。Mcafee的研究人员经过这种方法实现了漏洞利用,详情请参考[4],这里再也不重复。
图14 针对*.py文件的Popup菜单
另外,在野外捕获到的攻击样本中,也有攻击者直接将exe嵌入ppt,并经过操控“xml中的OLE Verb”为3来使用“管理员权限”运行exe,如图15所示。此时,若受害者使用了管理员帐户登陆系统或关闭了UAC,也将得不到任何安全警告。若受害者使用标准用户帐户登陆系统或未关闭UAC,则将获得UAC警告对话框。
图15 以管理员身份运行
能够经过Jon Erickson在BlackHat 2014 Asia上的报告《Persist It Using and Abusing Microsoft’s Fix It Patches》来学习、分析微软在本次Sandworm Attack中发布的fix it。
在CVE-2014-4114曝出后不久就出现了直接嵌入文件(而非最先的UNC下载)的利用样本[5],我经过CVE-2014-4114生成器源代码修改了一份嵌入方式的生成器,但在保证复合文档类型为0x22602的状况下,inf并未按照预期安装(MS14-060补丁前),精力有限就没再去跟踪调试缘由了。
[1] Timeline of Sandworm Attacks
http://blog.trendmicro.com/trendlabs-security-intelligence/timeline-of-sandworm-attacks/
[2] Microsoft Compound Document File Format.
http://www.openoffice.org/sc/compdocfileformat.pdf
[3] Bypassing Microsoft’s Patch for the Sandworm Zero Day: a Detailed Look at the Root Cause
http://blogs.mcafee.com/mcafee-labs/bypassing-microsofts-patch-sandworm-zero-day-root-cause
[4] Bypassing Microsoft’s Patch for the Sandworm Zero Day: Even ‘Editing’ Can Cause Harm
[5] Xecure lab discovers new variant of CVE-2014-4114 in Taiwan APT attacks
http://blog.xecure-lab.com/2014/10/cve-2014-4114-pptx-apt-xecure-lab.html