Flash 0day特性带来的攻击思路杂谈

平时工作过于忙碌,技术的敏感度稍显滞后,好在隐隐感觉黑哥与小熊在群里提到的Flash 0day特性(CVE-2014-4671)具备非常大的价值,于是保存了笔记,晚上抽空断断续续研究了下,才意识到这个0day的价值。

原文链接:
http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/

乌云昨天出了个翻译:
http://drops.wooyun.org/tips/2554

大家可以先对照着读读,理解这个0day需要一些背景知识:
1. 了解Flash在前端安全的地位,关于这点毫不避讳地推荐阅读我们这本书《Web前端黑客技术揭秘》第二章关于Flash安全的描述,内容很全面清晰;
2. 了解CSRF攻击的本质,同样我们的书也提了;
3. 了解JSONP,随便百度下你就知道;

这次Flash 0day特性实际上是对Flash文件格式的一次Hack(CWS压缩,采用的是zlib里的DEFLATE压缩算法),这种Hack的具体实现我没仔细理解,Hack之后的结果是Flash文件可以用ASCII码来完全表示(且是纯字母数字),这个会导致什么后果呢?

我慢慢道来:

1.

曾经我们玩浏览器解析Hack时都明白一个道理,如何让浏览器错误识别文件格式,即MIME类型,比如根据文件名后缀、Content-Type响应头、文件内容等。

题外话:这种判断规则在不同浏览器的实现还存在一些差异,这种差异导致有的浏览器可以被攻击成功,而有的不行。

曾经著名的UTF-7 XSS就是浏览器根据文件内容的头几个字符来判断目标文件的编码方式,比如开头是:

+/v8
+/v9
+/v+
+/v/

这个简单的缺陷导致全球重要网站纷纷中招。

2.

通过这个Flash 0day特性,结合JSONP接口,就可以把Flash文件内容(纯字母数字)附加到JSONP的返回结果中(通过给JSONP的callback参数赋值),为了按照Flash格式正常解析,文件头必须是严格的Flash文件内容。如果没这个Flash 0day特性,传给JSONP的内容就很可能包含各种特殊字符,就很可能会被JSONP的防御机制给过滤掉,就好像2012年这位大牛给出的POC:

http://50.56.33.56/blog/?p=242

当时是没利用这个Flash 0day特性的,当然如果JSONP没什么防御,不要这个特性也行。可惜的是正是因为这个特性的利用,Google、Facebook等都沦陷了……因为它们的JSONP防御机制允许纯字母数字的字符串出现。

通过这两点的说明,大家明白了吗?

防御方式可以好几种,最Nice的是:

在JSONP callback回来的内容之前强制加上/**/,这是JavaScript注释符,应该不会影响正常是JSON格式的解析执行,同时又可以避免根据文件头几个字符来决定目标文件MIME类型的解析机制。

曾经UTF-7 XSS漏洞也采用了类似的防御机制,在返回的内容前面强制加上个空格,这个道理是一样的:)

可惜Flash修补了这个0day特性,否则这种攻击很快会流行起来。这是一种非常经典的跨域攻击,我没来得及Demo,谁有结果可以告知我一声。

本杂谈比较乱,要想理解透彻,靠大家自己啃了。

最后,为什么说是0day特性,而不说是漏洞,这又是个很长的话题了……

2 comments

  1. xssee
    xssor
    希望朋友能吧上面两个编码工具源码分享一份谢谢

  2. 三个办法:
    1、截断;
    2、在callback name前加个空格或注释;
    3、将jsonp数据用try catch包裹;

发表评论

电子邮件地址不会被公开。 必填项已用*标注