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

漏洞发现原因

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

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

02.png这让我觉得是一个问题:在邮件中嵌入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,有了如下执行效果:

03.png我构造的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