今天分享的Writeup是关于Outlook for Andriod的存储型XSS漏洞，作者通过朋友发来的技术邮件偶然发现了该漏洞，历经长达几个月的复现构造，最终微软承认了该漏洞（CVE-2019-1105）。

漏洞发现原因

2018年底的时候，我一个朋友发邮件请我帮忙分析他在研究的一些JavaScript代码，虽然我不做漏洞挖掘，但他发过来的邮件在我的手机上显示出了一些奇怪的东西。我手机是安卓系统，以下是隐去发件人信息的邮件显示截图：

那个灰色边框，越看越有点奇葩。当我分析后发现。这可能是其中JavaScript包含了一个HTML形式的iframe框架，该iframe框架在解析时，手机应用无法正常显示呈现。但可疑的是，当我用笔记本电脑打开邮件时，整个解析都是正常的，如下所示：

这让我觉得是一个问题：在邮件中嵌入iframe框架可能会是一个漏洞，这可能和我手机上的Outlook应用有关。就Outlook来说，比较扯的是，iframe框架不受阻止外部图像设置的BlockExternalImages影响，但是，如果攻击者有能力在邮件中植入可运行的JavaScript代码，那将会是一个危险的安全威胁。

BlockExternalImages：Outlook  for iOS/Andriod中的安全设置，BlockExternalImages设置为true时将启用阻止外部图像。

有鉴于此，为了验证我的猜测，我尝试在电子邮件中插入脚本标签tag去代替iframe框架，但是不行。然而，我发现，可以通过在iframe框架中使用JavaScript URL，就能构造出一种绕过这种限制的方法，这就非常有意思了。

通过电子邮件实现的存储型XSS（Stored XSS）

通常，在一个Web浏览器中，可以通过javascript:这样的语法形式来调用一个URL，但是由于同源策略限制，单独域下的iframe框架中的JavaScript是不能对页面中的其它数据进行访问获取的。在Outlook for Andriod应用中，却不存在这样的限制，我构造的iframe框架中的JavaScript可以对我的用户cookie、token甚至其它邮件发起访问，不仅如此，还能把这些信息发回给攻击者的远程控制端，汗……。

这种安全问题相当可怕，要实现漏洞利用，攻击者只需发送一封包含有经过构造的JavaScript代码邮件给受害者，受害者用Outlook打开就会中招。正常来说，Outlook会对一些不安全的语法语义进行过滤转义，但由于构造的JavaScript代码处于iframe框架中，Outlook服务端不会对其进行探测发现，所以当邮件传送交付后，Outlook客户端也不会对其执行过滤转义，最终，包含在iframe框架中的JavaScript就能在客户端手机设备上成功运行了。这也就是我们所说的存储型XSS（Stored XSS），这种类型漏洞的风险隐患极大，攻击者可以利用它来实现多种目的，包括窃取信息和回传数据。攻击者只需向受害者发送一封构造好的邮件，当受害者阅读之后，就能窃取受害者的cookie、其它邮件或是个人数据等敏感信息。严重点说，这种存在于邮件阅读客户端的Stored XSS可经武器化分发部署，造成大规模的蠕虫或恶意软件方式的破坏感染。

漏洞上报后的复现历程

我觉得这是一个大问题，急需让微软方面知晓。于是，针对该漏洞，我制作了一个简短的PoC，它会执行一段任意外部脚本去窃取和回传个人敏感信息，由于漏洞利用构造不够深入，其中没有太多对邮件数据的访问获取展示。我马上把这个PoC发给了微软安全团队。

关于该漏洞，我确实不知道引发漏洞的源代码出在哪里，因为我自己就没有Outlook程序源码，而且，我基本没有调试移动应用的经验，但我想开发人员看到这段PoC后应该能理解。

但遗憾的是，微软安全团队却复现不了该漏洞，我也陷入了难堪和困境，但这明显是真的啊，我又向微软安全团队发了一段我这边漏洞复现的视频，之后，我了解到有一名安全研究人员也上报了该漏洞，但根据POC，微软安全团队仍然没成功复现。

为了证实是否是Outlook设置存在差异导致的原因，我又进行了一些测试，但也没发现问题所在，看来，这个漏洞要凉凉了。

微软：不能复现就不算漏洞

每个安全工程师和开发人员都会告诉你，不能重现的bug是一个令人头痛的问题，他们的时间对企业来说是宝贵而有限的资源。厂商安全团队可以花费很多精力去复现一个漏洞，最终的推理会是，如果他们不能成功复现漏洞，那么攻击者也不太可能成功复现和利用。所以从这点来说，厂商安全团队会尽量把责任推卸到上报漏洞的安全研究者身上，他们希望的是尽可能方便复现和确认的上报方式。

突破

我不能就这样罢休，几个月之后，这个漏洞仍然是我的一块心病，如何能让微软安全团队得以确认是一个难点。为此，我想到了从Outlook应用中提取HTML加载内容的方法，之后我才体会到，这种提取方式可能就是漏洞本身的问题吧！我能从Outlook应用中窃取数据，也就说明我可以用它读取和加载其中的HTML内容。于是，结合这个点，我构造了一个新的Payload，有了如下执行效果：

我构造的Payload形如以下：

<iframe src="javascript:alert(window. top. document. body. innerHTML+'')"
style="position:absolute;left:-2330px;" src=h

该Payload在Outlook服务端会被转义为HTML形式，但在Outlook客户端，它会被解析成：

<iframe src="javascript:alert(window. top. document. body. innerHTML+'')"
style="position:absolute;left:<a href=” tel:+442330”=””>-2330</a>px;" src=h</iframe>

漏洞出在客户端的代码解析中，Payload中的电话号码tel:+442330最终会被形成可点击按钮。该漏洞之前一直不能由微软成功复现，是因为我把我手机中的本地化设置为了UK，其电话号码会被判断为有效号码，而其它样式的本地化设置，将会把这个UK号码识别为无效号码，所以不能有效复现。

终于发现了问题所在，我把Payload中的电话设置成了US格式xxx-xxx-xxxx，它支持多种地区化设置下的漏洞复现，我迅速地向微软安全团队上报了POC。2019年3月26日，微软方面复现了漏洞并承诺在90天内进行修复。

漏洞上报进程

2018.12.10 –   向微软漏洞初报

2019.1.16 –     微软不能成功复现漏洞

2019.3.26 –    我向微软发送了通用POC

2019.3.26 –    微软成功复现

2019.6.20 –    漏洞修复

总结

2019年6月20日，微软修复了该漏洞，并分配了编号CVE-2019-1105，威胁影响为重要级别。对于个人和企业用户来说，保持应用软件的及时更新非常重要，这可以最大程度地降低入侵攻击风险。当然，作为研究者来说，漏洞挖掘和上报同样重要，这可以帮助厂商修补漏洞，实现更安全的产品。

*参考来源：f5，clouds编译，转载请注明来自FreeBuf.COM