*本文中涉及到的相关漏洞已报送厂商并得到修复,本文仅限技术研究与讨论,严禁用于非法用途,否则产生的一切后果自行承担。
概述
360威胁情报中心曾在2017年8月发布了《乌龙的CVE-2017-8570样本及背后的狗血》(详见参考资料[1]),当时由于在VirusTotal上发现了多例标注为CVE-2017-8570的Office幻灯片文档恶意样本,所以有安全厂商宣称第一时间捕获了最新的Office CVE-2017-8570野外利用漏洞样本,但经过360威胁情报中心的分析判断,这批Exploit样本实际上是CVE-2017-0199的另外一种利用方式(通过Office幻灯片加载执行Scriptletfile脚本),在微软2017年4月份的补丁中已经针对CVE-2017-0199这种利用方式实行了修补。
直到本月初,360威胁情报中心才监控到互联网上首次出现了真实的CVE-2017-8570野外攻击样本,基于360威胁情报中心的数据,以下热力图显示了从2018年1月11日以来CVE-2017-8570样本量的提交情况,可以看到漏洞Exploit一旦公开使用,马上就会进入被攻击者频繁使用的状态:
另外,因为CVE-2017-0199有天生缺陷(这部分我们会在随后的章节中描述),实际上目前已公开的CVE-2017-0199利用样本在Office Word上的利用威胁并不大,而CVE-2017-8570并没有该缺陷,所以8570在Office Word上利用的实际效果要比0199好很多,但POC构造相对较难,这也是一开始没有发现野外利用的原因之一。
样本分析
该漏洞还处于未被利用或尚无已知利用的状态:
直到2018年1月11日左右,360威胁情报中心才首次发现野外第一个利用CVE-2017-8570的RTF样本,随后利用CVE-2017-8570漏洞的攻击样本逐渐增多,我们选择最近出现的一个真实攻击样本进行分析。
野外利用的RTF样本分析
由于真实的CVE-2017-8570漏洞攻击样本在本月前几乎未出现过,所以相关杀软对该漏洞的检出率还不够理想,以我们接下来分析的攻击样本在VirusTotal上的查杀情况来看,57家杀软中只有11家能够查杀:
恶意RTF样本分析:
样本利用了RTF文档在VISTA以后的系统中会自动释放Package对象到%tmp%目录的特性,在文档将恶意Scriptletfile(.sct)脚本文件以Package对象的方式插入,在受害者打开RTF文档后,Package对象中的Scriptletfile(.sct)脚本文件会自动释放到%tmp%目录下
样本插入了两个关键的Objdata,其中一个是Package对象,包含的其实是一个Scriptletfile(.sct)脚本文件:
另一个则是包含了CVE-2017-8570漏洞的OLE2Link对象:
打开RTF文档后,自动释放Package对象到%tmp%目录,插入的Package对象实际上是一个恶意Scriptletfile(.sct)脚本文件
另一个OLE2Link对象用来触发漏洞,漏洞触发成功后会直接加载%tmp%目录下的MUZTWOWEZTHOBKW.sct脚本执行
包含漏洞的OLE2Link对象中使用了Composite Moniker来将“绑定”一个File Moniker,而File Moniker顾名思义会指定一个文件,漏洞样本中的File Moniker指定的是本地%tmp%目录中的sct脚本文件,而该sct脚本文件恰好是Package对象中释放出来的:
FileMoniker检测到加载的文件后缀是.sct后,通过COM接口加载执行Scriptletfile脚本文件
Payload
分析发现样本使用的Payload是FormBook远控软件,FormBook是一款以窃密为主的远程控制软件。FireEye曾报道过有APT组织使用FormBook作为Payload针对美韩航空航天公司、国防承包商与部分制造企业展开网络钓鱼攻击。
样本使用了VB编写,运行后首先以挂起状态创建一个新的自身进程,之后解密出真正的恶意代码,再使用ZwWriteVirtualMemory将恶意代码写入到刚创建的傀儡进程中,最后启动傀儡进程执行恶意代码。傀儡进程首先遍历进程列表查找Explorer.exe,并使用NtMapViewOfSection向Explorer.exe注入ShellCode:
Explorer中注入的ShellCode会在%systemroot%\system32下随机选取一个exe文件再次以傀儡进程的方式注入ShellCode,新的傀儡进程会删除原始病毒样本,并重新向Explorer.exe注入ShellCode,该ShellCode 为最终的执行的恶意代码。之后恶意代码会连接C&C服务器,以Get方式发送连接请求:
通过判断C&C指令以及特殊的“FBNG”字符串标志来执行对应的木马功能:
接收指令以及对应的木马功能:
功能编号 | 功能说明 |
---|---|
1 | 下载执行 |
2 | 木马版本更新 |
3 | 自清除 |
4 | 利用ShellExecute执行命令 |
5 | 清除浏览器Cookie |
6 | 重启 |
7 | 关机 |
8 | 收集浏览器密码,屏幕截图 |
9 | 下载ZIP文件 |
木马执行流程
Exploit来源
2018年1月9日,有安全研究人员在GitHub上(https://github.com/rxwx/CVE-2017-8570)上传了CVE-2018-8570的漏洞利用构造工具,360威胁情报中心通过分析确认该工具的确为针对CVE-2018-8570的Exploit构造工具,并且捕获到的攻击样本几乎都是使用该工具生成。
考虑到漏洞相关的技术细节和验证程序已经公开,所以此漏洞接下来极有可能被利用来执行大规模的攻击。
漏洞分析
漏洞概述
微软在2017年7月的安全更新中修复了这个针对Office的远程命令执行漏洞(CVE-2017-8570),该漏洞实际上是利用了Office OLE中的Composite Moniker对象在组合File Moniker对象的过程中,未做安全性检测,将File Moniker对象指定的远程/本地的ScriptletFile(.sct)脚本文件在Office中直接执行。
微软修复CVE-2017-0199实际上是在Office中禁用了htafile对象和script对象,而没有禁用ScriptletFile对象,由于通过Composite Moniker的方式可以执行ScriptletFile(.sct)脚本,相当于绕过了CVE-2017-0199的补丁修复,所以在针对CVE-2017-8570的补丁修复中,微软禁用了ScriptletFile对象:
2017年4月,修复CVE-2017-0199,禁用htafile对象和script对象
禁用的CLSID | ProgID | CVE |
---|---|---|
{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B} | htafile | CVE-2017-0199 |
{06290BD3-48AA-11D2-8432-006008C3FBFC} | script | CVE-2017-0199 |
2017年7月,修复CVE-2017-8570,禁用ScriptletFile对象
禁用的CLSID | ProgID | CVE |
---|---|---|
{06290BD2-48AA-11D2-8432-006008C3FBFC} | ScriptletFile | CVE-2017-8570 |
Composite Moniker
Composite Moniker对象的作用是可以将某个Moniker对象定义为一个新的Moniker对象(NewMoniker),或者将多个Moniker对象进行组合,比如可以使用Composite Moniker对象将两个File Moniker对象组合成一个。假设Composite Moniker对象包含了两个File Moniker对象:
File Moniker 1:"c:\work\art"
File Moniker 2:"..\backup\myfile.doc"
通过Composite Moniker对象进行组合后,相当于得到了一个带有完整文件路径的File Moniker对象:"c:\work\backup\myfile.doc"。
在触发漏洞的样本中有三个Moniker对象,分别是:
Composite Moniker:{00000309-0000-0000-C000-000000000046}
File Moniker:{00000303-0000-0000-C000-000000000046}
New Moniker:{ECABAFC6-7F19-11D2-978E-0000F8757E2A}
样本中的Composite Moniker将File Moniker定义为了一个New Moniker新对象:
执行ScriptletFile脚本
CompositeMoniker在将File Moniker定义为一个New Moniker新对象的过程中,会调用IMoniker::BindToObject方法将File Moniker进行Bind操作,IMoniker::BindToObject函数原型如下:
HRESULT BindToObject(
[in] IBindCtx *pbc,
[in] IMoniker *pmkToLeft,
[in] REFIID riidResult,
[out] void **ppvResult
);
pmkToLeft则指向File Moniker,File Moniker在样本中指定的文件为:%tmp%\MUZTWOWEZTHOBKW.sct,而由于FileMoniker需要初始化指定的文件,对象在检测到文件后缀后.sct后,会自动在注册表中查找处理.sct文件的接口:
确定.sct后缀
关联scriptletfile的CLISD
定位处理接口
查找到处理.sct文件的处理接口后,调用对应的接口启动.sct脚本执行环境,并执行脚本,栈回溯显示整个流程执行过程:
0:000> k
ChildEBP RetAddr
0037abe8 62e048ffjscript!CScriptRuntime::Run <-- 执行.sct脚本
0037ace4 62e04783 jscript!ScrFncObj::CallWithFrameOnStack+0x15f
0037ad3c 62e04cc3jscript!ScrFncObj::Call+0x7b
0037ade0 62e13797jscript!CSession::Execute+0x23d
0037ae2c 62e10899jscript!COleScript::ExecutePendingScripts+0x16b
0037ae48 6c61831fjscript!COleScript::SetScriptState+0x51
0037ae58 6c618464scrobj!ScriptEngine::Activate+0x1a
0037ae70 6c6199d3scrobj!ComScriptlet::Inner::StartEngines+0x6e
0037aec0 6c61986escrobj!ComScriptlet::Inner::Init+0x156
0037aed0 6c61980bscrobj!ComScriptlet::New+0x3f
0037aef0 6c6197d0 scrobj!ComScriptletConstructor::CreateScriptletFromNode+0x26
0037af10 6c623b7escrobj!ComScriptletConstructor::Create+0x4c
0037af3c 6c612946scrobj!ComScriptletFactory::CreateInstanceWithContext+0x115
0037af58 53c464bescrobj!ComBuiltInFactory::CreateInstance+0x19
0037afac 7601b573comsvcs!CNewMoniker::BindToObject+0x14f <--New Moniker
0037afe0 76083d8eole32!CCompositeMoniker::BindToObject+0x105 <-- Composite Moniker定义File Moniker
0037b04c 31a82c6aole32!CDefLink::BindToSource+0x1bf
WARNING: Stack unwind information notavailable. Following frames may be wrong.
0037b090 3152f55ewwlib!wdGetApplicationObject+0x6cd2f
0037b120 31473477wwlib!DllGetClassObject+0x158a4c
0038031c 314667efwwlib!DllGetClassObject+0x9c965
003831e03146501f wwlib!DllGetClassObject+0x8fcdd
漏洞成因
由于整个处理过程都没有进行安全检测(是否可以执行可能包含恶意代码的脚本),但其中的每一个步骤单独看来都没有安全问题:Composite Moniker将File Moniker定义为New Moniker、File Moniker按照正常的流程识别加载.sct文件等等,但是将所有环节组合起来却导致了安全隐患,这是导致该漏洞的问题所在。
弥补CVE-2017-0199的天生缺陷
CVE-2017-0199漏洞利用的方式有两种,一种是在Office Word文档中利用,一种是在Office幻灯片中利用。已经公开的Office Word文档中利用方法主要是通过漏洞执行.hta脚本,360威胁情报中心分析发现,其实大部分操作系统由于各种原因已经在注册表中对ActiveX控件执行.hta脚本的COM接口设置了killbit,也就是即使没有打上CVE-2017-0199漏洞补丁,在Office Word文档中也无法执行.hta脚本:
这使得CVE-2017-0199漏洞在Office Word文档中的利用威胁并不大,然而CVE-2017-8570漏洞利用执行的.sct脚本对应的COM接口却并未被禁止,所以CVE-2017-8570在Office Word文档中的威胁要比CVE-2017-0199大很多。
防护建议
补丁修复
软件厂商微软已经发布了漏洞相应的补丁,360威胁情报中心建议用户及时更新Office补丁修复漏洞:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8570
禁用“Package” ActiveX Control
360威胁情报中心监控到利用RTF文档自动释放恶意Package对象到%tmp%目录的特性进行Office漏洞攻击的样本越来越多,包括最近的CVE-2017-11882等漏洞利用也使用了该技巧,所以360威胁情报中心建议用户如果不需要使用插入Package对象这类功能,可以在注册表中通过设置killbit的方式禁用,以封堵这类攻击入口:
执行命令行命令 | 说明 |
---|---|
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Common\COM Compatibility\{F20DA720-C02F-11CE-927B-0800095AE340}" /v "Compatibility Flags" /t REG_DWORD /d 0x400 | 32位系统版本或64位系统中的64位版本 |
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Common\COM Compatibility\{F20DA720-C02F-11CE-927B-0800095AE340}" /v "Compatibility Flags" /t REG_DWORD /d 0x400 | 64位系统中的32位版本 |
总结
从360威胁情报中心捕获到的样本来看,CVE-2017-8570漏洞利用样本公开使用后,马上就进入被频繁使用的状态,并且由于没有CVE-2017-0199在Office Word中利用的“缺陷”,相信后续会有更多攻击者使用CVE-2017-8570替代CVE-2017-0199进行漏洞攻击。360威胁情报中心再次提醒用户,尽量不要打开来源不明的文档,也可以使用360安全卫士之类的防病毒软件对文档进行扫描后再打开以尽可能降低风险。
IOC
参考资料
[1] https://ti.360.net/blog/articles/analysis-of-fake-cve-2017-0158/
[2] https://justhaifei1.blogspot.co.uk/2017/07/bypassing-microsofts-cve-2017-0199-patch.html
[3] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8570
[4] https://github.com/rxwx/CVE-2017-8570
[5] https://msdn.microsoft.com/en-us/library/windows/desktop/ms693788(v=vs.85).aspx
*本文作者:360天眼实验室,转载请注明来自FreeBuf.COM