从老漏洞到新漏洞 – iMessage 0day(CVE-2016-1843) 挖掘实录

0x01 前言

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

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

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

0x02 CVE-2016-1764 漏洞分析

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

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

遇到这样的客户端的 xss 如果要分析,第一步应该看看 location.href 的信息。这个主要是看是哪个域下,这个漏洞是在 applewebdata:// 协议下,这个原漏洞分析里有给出。然后要看具体的触发点,一般在浏览器下我们可以通过看html源代码来分析,但是在客户端下一般看不到,所以这里用到一个小技巧:

这里是看 html 里的 head 代码:

继续看下body的代码:

那么关键的触发点:

javascript 直接进入 a 标签里的 href,导致点击执行。新版本的修复方案是直接不解析 javascript://

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

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

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

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

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

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

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

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

0x04 后记

当然这里还有很多地方可以测试,也有一些思路也可以去测试下,比如那个名字那里这个应该是可控制的,比如附件是保存在本地的有没有可能存在目录专挑导致写到任意目录的地方。有需求的可以继续测试下,说不定下个0day就是你的 :)

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

【via@SuperHei-n0tr00t security team