蜗蜗侠's Blog-关注网络安全移动版

注：文章里“0day”在报告给官方后分配漏洞编号：CVE-2016-1843

一、背景

在前几天老外发布了一个在3月更新里修复的iMessage xss漏洞（CVE-2016-1764）细节 ：

https://www.bishopfox.com/blog/2016/04/if-you-cant-break-crypto-break-the-client-recovery-of-plaintext-imessage-data/

https://github.com/BishopFox/cve-2016-1764

他们公布这些细节里其实没有给出详细触发点的分析，我分析后也就是根据这些信息发现了一个新的0day。

二、CVE-2016-1764 漏洞分析

CVE-2016-1764 里的最简单的触发payload： javascript://a/research?%0d%0aprompt(1) 可以看出这个是很明显javascript协议里的一个小技巧 %0d%0 没处理后导致的 xss ，这个tips在找xss漏洞里是比较常见的。

这个值得提一下的是 为啥要用prompt(1) 而我们常用的是alert(1) ，我实际测试了下发现alert确实没办法弹出来，另外在很多的网站其实把alert直接和谐过滤了，所以这里给提醒大家的是在测试xss的时候，把 prompt 替换 alert 是有必要的～

遇到这样的客户端的xss如果要分析，第一步应该看看location.href的信息。

这个主要是看是哪个域下，这个漏洞是在applewebdata://协议下，这个原漏洞分析里有给出。

然后要看具体的触发点，一般在浏览器下我们可以通过看html源代码来分析，但是在客户端下一般看不到，所以这里用到一个小技巧：

javascript://a/research?%0d%0aprompt(1,document.head.innerHTML)

这里是看html里的head代码

继续看下body的代码：

javascript://a/research?%0d%0aprompt(1,document.body.innerHTML)与“xxx@xxx.com”进行 iMessage 通信今天 23:23javascript://a/research?%0d%0aprompt(1,document.body.innerHTML)javascript://a/research?%0d%0aprompt(1,document.body.innerHTML)javascript://a/research?%0d%0aprompt(1,document.head.innerHTML)已送达javascript://a/research?%0d%0aprompt(1,document.head.innerHTML)

那么关键的触发点:

javascript://a/research?%0d%0aprompt(1,document.head.innerHTML)

就是这个了。

javascript直接进入a标签里的href，导致点击执行。

新版本的修复方案是直接不解析javascript:// 。

三、从老漏洞(CVE-2016-1764)到0day

XSS的漏洞本质是你注入的代码最终被解析执行了，既然我们看到了document.head.innerHTML的情况，那么有没有其他注入代码的机会呢？首先我测试的肯定是还是那个点，尝试用"及<>去闭合，可惜都被过滤了，这个点不行我们可以看看其他存在输入的点，于是我尝试发个附件看看解析情况，部分代码如下：

< img class="transfer-icon" extension="html" aria-label="文件扩展名: html" style="content: -webkit-image-set(url(transcript-resource://iconpreview/html/16) 1x, url(transcript-resource://iconpreview/html-2x/16) 2x);">tttt< img class="transfer-button-reveal" aria-label="显示" id="filetransfer-button-45B8E6BD-9826-47E2-B910-D584CE461E5F" role="button">

发了个tttt.html的附件，这个附件的文件名出现在代码里，或许有控制的机会。多长测试后发现过滤也比较严格，不过最终还是发现一个潜在的点，也就是文件名的扩展名部分：

< img class="transfer-icon" extension="htm::16) 1x, (aaa\\\\\\\\\\\%0a%0d" aria-label="文件扩展名: htm::16) 1x, (aaa\\\\\\\\\\\%0a%0d" style="content: -webkit-image-set(url(transcript-resource://iconpreview/htm::16) 1x, (aaa\\\\\\\\\\\%0a%0d/16) 1x, url(transcript-resource://iconpreview/htm::16) 1x, (aaa\\\\\\\\\\\%0a%0d-2x/16) 2x);">testzzzzzzz"'>< img class="transfer-button-reveal" aria-label="显示" id="filetransfer-button-A6BE6666-ADBF-4039-BF45-042D261EA458" role="button">

我们提交的附件的后缀进入了style ：

 style="content: -webkit-image-set(url(transcript-resource://iconpreview/htm::16) 1x, (aaa\\\\\\\\\\\%0a%0d/16) 1x, url(transcript-resource://iconpreview/htm::16) 1x, (aaa\\\\\\\\\\\%0a%0d-2x/16) 2x);

也就是可能导致css注入，或许我们还有机会，不过经过测试也是有过滤处理的，比如/ 直接被转为了:这个非常有意思 所谓“成也萧何，败也萧何”，如果你要注入css那么肯定给属性给值就得用: 但是:又不能出现在文件名里，然后我们要注入css里掉用远程css或者图片需要用/ 而/又被处理了变成了:

不管怎么样我先注入个css测试下，于是提交了一附件名：

 zzzzzz.htm) 1x);color/red;aaa/((

按推断/变为了: 如果注入成功应该是

style="content: -webkit-image-set(url(transcript-resource://iconpreview/htm::16) 1x);color:red;aaa:((

当我提交测试发送这个附件的时候，我的iMessage 崩溃了～～ 这里我想我发现了一个新的漏洞，于是我升级OSX到最新的系统重新测试结果：一个全新的0day诞生！

四、后记

当然这里还有很多地方可以测试，也有一些思路也可以去测试下，比如那个名字那里这个应该是可控制的，比如附件是保存在本地的有没有可能存在目录跳转导致写到任意目录的地方。

有需求的可以继续测试下，说不定下个0day就是你的 ：）

最后我想说的是在分析别人发现的漏洞的时候一定要找到漏洞的关键，然后总结提炼出“模型”，然后去尝试新的攻击思路或者界面！

参考链接

https://www.seebug.org/vuldb/ssvid-92471

【从老漏洞到新漏洞 --- iMessage 0day(CVE-2016-1843) 挖掘实录  文/SuperHei（知道创宇404安全实验室） 安全脉搏整理发布】