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

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

缺陷编号:wooyun-2014-064792

漏洞标题:各大CMS厂商的CMS存在的同一设计缺陷

相关厂商:各大CMS厂商

漏洞作者: 索马里的海贼

提交时间:2014-06-13 16:49

修复时间:2014-09-11 16:50

公开时间:2014-09-11 16:50

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

危害等级:高

自评Rank:20

漏洞状态: 已交由第三方合作机构(cncert国家互联网应急中心)处理

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

Tags标签:

4人收藏 收藏
分享漏洞:


漏洞详情

披露状态:

2014-06-13: 细节已通知厂商并且等待厂商处理中
2014-06-17: 厂商已经确认,细节仅向厂商公开
2014-08-11: 细节向核心白帽子及相关领域专家公开
2014-08-21: 细节向普通白帽子公开
2014-08-31: 细节向实习白帽子公开
2014-09-11: 厂商已经修复漏洞并主动公开,细节向公众公开

简要描述:

其实不能说是各大CMS的问题 应该说是php的一个小特性。对各CMS的影响因为代码逻辑的不同而各不相同,一定条件下可以劫持账户(如ecshop等)、或对被攻击用户造成“永久”DOS(如dz pw wp 乌云官方等)。本来不知道该不该提交这个问题,或者到底是提交到主站还是投稿到drops做讨论,后来想想问题总是存在的,对于有些CMS和站点来说还是有比较大的影响,所以还是发主站赚点rank吧 :)

详细说明:

先来看一个小测试

<?php
foreach($_GET as $k=>$v){
$$k = $v;
}
if(isset($my_var)){
echo $num."\n";
}
?>


然后用burp去跑

GET /test.php?my%§c§var=x&num=§x§ HTTP/1.1


payload是从00到ff
得到的结果是 20 2e 5b 5f 也就是 " " "." "[" "_"
除了_以外,空格 句号 方括号都能初始化my_var
再来做另外一个测试

<?php
var_dump($_GET);
?>


然后我们提交test.php?my.var=bar 或者?my[var=bar或者?my var=bar
可以看到返回都是一样的

array(1) {
["my_var"]=>
string(3) "123"
}


从上面两个测试可以看到,key并不是在循环初始化的过程被换掉的。而是php在初始化接收key的时候 就把" " "." "[" 这三个含在超全局变量$_GET中的key的符号转成了"_"
事实上刚发现这个问题的时候,第一个想到的就是dede的全局变量注册机制,如果提交一个请求 x.php?.POST[xx]=xx 岂不是可以绕过dede的正则?后来做了第二个测试发现是想多了。在初始化的时候已经被替换成了"_" 所以经过正则的时候一样会被拦下来。
接下来还是说一下这个小特性是怎么造成安全影响的吧。
这个特性不光影响$_GET, $_POST和$_COOKIE也一样会转换。GET和POST不多说,在各种全局检查机制下很难找到利用的空间(也不是没有,不过不是这篇文章的重点)。
说说$_COOKIE,现在写代码的码农们,为了美观也好好记也好,一般都会用"_"去分割cookie中的单词
如乌云的wy_uid
phpwind的xxxxx_winduser
ecshop的ECS_ID
有这种方式命名重要cookie就会受到威胁
以乌云为例,如果我当前的cookie是这样的
wy_uid=x;wy_pwd=y;
wy_uid是httponly的,我不能用js去修改,但是我可以用js添加一个有效期为1年的wy.uid=z;
在请求乌云的时候 我完整的cookie就是
wy_uid=x;wy_pwd=y;wy.uid=z;
当然 这个时候还是没问题的,因为$_COOKIE['wy_uid']会取前面的那个,但是 乌云的cookie是有有效期的,等他有效期一过,重新setcookie的时候我的wy.uid=z就排到wy_uid的前面
这时候再请求乌云 乌云拿的wy_uid就是z了,z无法通过乌云的检查逻辑,就会注销当前账号的session。就算乌云会删除wy_uid这个cookie(测试看来是没有)。也不会把我们的wy.uid删掉。这个cookie会一直在最前面,账号就再也无法登录了。这就是所谓的“永久”DOS。
再如ecshop ecshop的权限检查就靠一个ECS_ID,应该叫sessionid吧,这个地方ecshop存在Session Fixation(刺总翻译:Session 完成攻击 链接:http://hi.baidu.com/aullik5/item/e1a17560d073612369105bd5)的问题。登录后没有重新设置session(ECS_ID)而是在当前session(ECS_ID)设置用户信息。如果我给你提前设置(或者设置完了等你原先的session超时)一个ECS.ID。你就会一直用这个ECS_ID用到死。
setcookie ECS_ID改不了本地的ECS.ID。而ECS.ID有效期又非常长。只要你一登陆 我就能拿着这个ECS.ID访问网站获取你的所有权限。
以上两种只是简单的说明一下这个问题的危害,其实还有很多攻击方法比如去流量大的地方给所有访问的人设置一个返利网的cookie,去渗透目标常访问的网站挖个坑坐等目标上门种下rootkit(水坑攻击)等等等等。
问题的局限在于我得能设置目标域的cookie(比如一个xss),所以这个漏洞绝大多数厂商可以理直气壮的无影响忽略。这个就不在本文讨论之内了,仁者见仁吧。

漏洞证明:

给乌云添加一个wy.uid的cookie 看一下wy_uid的超时时间,关闭浏览器,等超时时间过去了再打开乌云看看是不是已经是未登录状态了。而且在清除这个cookie之前你再也登录不上乌云了。

修复方案:

关键cookie不要在key中包含"_"

版权声明:转载请注明来源 索马里的海贼@乌云


漏洞回应

厂商回应:

危害等级:高

漏洞Rank:20

确认时间:2014-06-17 22:04

厂商回复:

与此前的某贴一样,对于所述原理,CNVD确认可行,从处置可行性看,目前还未能列入处置流程。鼓励此类独立分析的贴,先行确认,立即公开,供大家参考。

最新状态:

2014-06-17:先公开。