当前位置：WooYun >> 漏洞信息

漏洞概要 关注数(24) 关注此漏洞

缺陷编号：wooyun-2012-09025

漏洞标题：UC云端加速引擎存在非正常泄露referer问题

相关厂商：UC Mobile

漏洞作者： horseluke

提交时间：2012-06-29 21:40

修复时间：2012-08-13 21:41

公开时间：2012-08-13 21:41

漏洞类型：设计缺陷/逻辑错误

危害等级：低

自评Rank：5

漏洞状态：厂商已经确认

漏洞来源： http://www.wooyun.org，如有疑问或需要帮助请联系 [email protected]

Tags标签： 无

4人收藏 收藏
分享漏洞：

漏洞详情

披露状态：

2012-06-29： 细节已通知厂商并且等待厂商处理中
2012-06-30： 厂商已经确认，细节仅向厂商公开
2012-07-10： 细节向核心白帽子及相关领域专家公开
2012-07-20： 细节向普通白帽子公开
2012-07-30： 细节向实习白帽子公开
2012-08-13： 细节向公众公开

简要描述：

UC云端加速引擎，未能遵循常见的referer约定原则，导致了非正常的（javascript）document.referrer和（HEADER）HTTP REFERER泄露问题
（注意：本问题并不会泄露https地址，故综合评级低）

详细说明：

（追查过程详见修复建议）
有关来源的赋值和发送，浏览器似乎均没有很统一的做法。比如：
http://topic.csdn.net/t/20050708/02/4130391.html
http://hi.baidu.com/anglee2010/item/dffb1f122f4688a2ffded55a
但一般而言，有两个常见约定原则：
（1）用户通过手动在地址栏输入URL、通过收藏夹点击时，document.referrer和HTTP REFERER必为空
（2）用户从https使用任何方式跳回http时，document.referrer和HTTP REFERER必为空
不过UC云端加速引擎在第一点似乎存在缺陷：在渲染时，document.referrer以及HEADER头HTTP REFERER被必定赋值为上一个浏览页，而没有考虑用户实际的操作路径。
当然在第二点上，UC就没有问题，均遵循常见约定原则对两者进行了赋为空值的操作。
这个缺陷导致的结果是，用户在UC浏览器中假若使用了UC云端加速器（包括但不限于：2G/3G网络；WIFI下关闭WIFI优化设置等），在使用书签或者直接输入URL切换到新网站的时候，不该设置的document.referrer被设置了，不该发送的HTTP REFERER发送了，从而导致非正常的HTTP REFERER泄露给新网站。若这些网站记录了这些来源信息，除了扰乱统计成效外，还可能被不坏好意的网站主做坏事——亲，还在亲自辛辛苦苦地GOOGLE HACKING？只需0元，只需0元，自己做个手机网站，弄段来源统计代码，就可让潜在漏洞网站自动送上门来！
综合评估后，认为属于中低的云端设计缺陷。

漏洞证明：

（1）在某个服务器放置以下REFERER检测代码，假定为http://www.test.com/refer_test/index.php （存在XSS，请用完后即删除！）：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>DOCUMENT_REFERER_TEST_BY_HORSELUKE</title>
</head>
<body class="main-body">
	js:<div id="js"></div>
	<hr />
	php:<div id="php"><?php if(empty($_SERVER['HTTP_REFERER'])): ?>NONE<?php else: echo $_SERVER['HTTP_REFERER']; endif; ?></div>
</body>
<script type="text/javascript">
var refer=document.referrer||"";
if(refer == ""){
	refer = "none";
}
document.getElementById('js').innerHTML = refer;
</script>
</html>


（2）在手机端安装UC浏览器，并且设置使用云端加速功能（wifi连接下需要“关闭wifi优化”）。
（3）随便打开别的网站，比如： WooYun: structs2 远程命令执行漏洞分析
（4）打开完毕后，在地址栏输入：http://www.test.com/refer_test/index.php
也可以通过书签打开此地址
（5）页面可以看到，（javascript）document.referrer和（HEADER）HTTP REFERER均泄露了上一次访问的地址。
以上的最终效果（汗...乌云给动画gif打水印导致无效了，只好发最后一步的图了）：

修复方案：

猜测可能是云加速服务器单对单模拟运作，js渲染引擎需要保持浏览器的用户状态？又或者在设计时为了保证性能而不敢频繁改变模拟的浏览器状态？
由于对云端设计和模拟均不熟悉，故还是无法提出有效的建议。这点见谅。
附追查过程：
部分词汇约定：
以下均以“来源”统称“来路”
起因：
今天翻查某网站的统计来源时，发现一个有漏洞的工控web地址（此漏洞需进一步确定后再另提交）。
但这个工控web地址，根本不可能也实际上没有一个链接会指向这个网站，
那么问题是，它怎么会成为CNZZ统计代码认为的来源的？
与此有相同问题的有中国移动wifi上网认证页面。


初步分析：
翻查CNZZ统计代码，发现来源页面的获取是通过如下js脚本获取：

refer=document.referrer||"";


翻查完document.referrer的一些背景后，还是无法搞清楚，是什么浏览器在什么操作下，导致了会认为这个有值？
于是乎大海捞针地翻查CNZZ访问明细日志，竟然幸运地在短时间内找到。但问题是，是个手机公网出口ip，而且浏览器和操作系统均为空，无法得到任何有价值的信息：


蛋疼期：
在无法得到任何有价值信息的情况下，只好进行了瞎猜操作，使用手机和电脑上的各种原生和第三方浏览器进行了各种尝试，无果。
此蛋疼过程忽略。
曙光：
最后唯有祭出一招，写一段模拟cnzz的代码进行访问者user agent和referer的记录。
幸运的是，挂上去没多久，那个访客出现了：

$visit_log = array(
	array(
		'log_id'=>17,
		'time'=>'2012-06-29 19:02:47',
		'ip'=>'[忽略]',
		'user_agent'=>'IUC(U;iOS 5.1.1;Zh-cn;320*480;)/UCWEB8.4.1.169/42/997',
		'referer'=>'http://[工控地址，忽略]',
		'screen_width'=>800,
		'screen_height'=>600,
		'ext'=>'{\"user_agent\":\"IUC(U;iOS 5.1.1;Zh-cn;320*480;)\\/UCWEB8.4.1.169\\/42\\/997\",\"x_forward\":\"[忽略]\",\"http_accept\":\"*\\/*, dn\\/3969128191-24c84f20,text\\/vnd.wap.wml;q=0.6,ss\\/320x416,UC\\/42\",\"http_accept_charset\":\"x-gbk,utf-8;q=0.7,*;q=0.7\",\"http_accept_encoding\":\"gzip,deflate\",\"http_accept_lang\":\"zh-cn\"}'
	)
);


此日志清楚表明了用户是使用苹果手机上的UC浏览器进行访问的。
但问题是，明明已经测过安卓版UC浏览器，没发现问题啊。
正找同事用IOS测试的时候，突然想起UC不是有个云加速服务么？之前测试的时候，由于连的是wifi，就不会经过云加速，所以没问题。如果强制打开了呢？
于是乎再度拿起安卓版UC，重测移动3G上网和关闭wifi两种迫使使用UC云加速的情况，最终发现了以上问题的成因。

版权声明：转载请注明来源 horseluke@乌云

漏洞回应

厂商回应：

危害等级：低

漏洞Rank：5

确认时间：2012-06-30 00:00

厂商回复：

非常感谢,根据你的描述,可能确实存在此问题,我们将进行仔细的排查具体什么情况.

最新状态：

2012-07-19：已经在新版中修复了，再次感谢！