ecshop漏洞汇总 之一
把这个贴出来的目的,不是说我想借此出名,而是对于厂商对自己的产品安全所不负责任的态度让我无语
我是出于希望厂商能认真对待自己产品的漏洞,积极解决为目的.我怀疑商派公司对自己产品漏洞的认真程度与工作态度,我希望有漏洞会直接被厂方所关注,我不想提交在"乌云"上面,借助第三方平台解决漏洞的算什么?效率何在?如何来为用户保证安全呢?
或许我十分费解"乌云"的运营方式
这份漏洞报告已经向ecshop官方人员提交过,而且还出了补丁
到目前为止仍然有部分页面未进行修补!!!
发这篇blog之前,我还咨询过
ecshop官方人员说他们的演示站 www.ecshop.cn 跑得是最新的全补丁ecshop程序
比如 search页面,测试可以在
www.ecshop.cn
官方演示站进行
=================================================
我向官方提交过漏洞报告, 官方的补丁已经在下面的url中发布..
http://bbs.ecshop.com/viewthread.php?tid=148571
虽然这里只是提到了我给出了XSS的部分.
但是,官方第一次发布补丁的时候(3月18日),就已经偷偷的更新了sql注入漏洞,但这里对此只字未提...
随便了...既然不敢正视自己产品漏洞的公司,还算什么呢?
有人让我提交到"乌云"上面,我想还是算了,我不想折腾那个名气,官方不更新,最终漏洞被公开,还不如在我这里被公开呢..
--------------------------------------------------------------------------------------
下面是3月份我向ecshop官方提交的漏洞报告原文
由于整理时间仓促,语言不是很通顺,与此同时
由于出差等原因,我未能按时更新在fengblog上面...
在此向每日200多访问者表示歉意...
ECSHOP 2.7.2 漏洞报告
发现时间:
2011-3-2
影响版本:
ECShop_V2.7.2_UTF8_Release0604
(其他版本未测试)
漏洞简述:
首先,漏洞分为两部分,SQL注入和XSS脚本跨站漏洞.
漏洞描述:
XSS脚本跨站漏洞部分:
(1) "./search.php" 页面跨站漏洞
测试代码:
url访问
./search.php?encode=YTo0OntzOjg6ImNhdGVnb3J5IjtzOjE6IjAiO3M6ODoia2V5d29yZHMiO3M6NDg6IjE8L3RleHRhcmVhPjxTY1JpUHQgICA%2bYWxlcnQoMzE5NDQwMjcpOzwvU2NSaVB0PiI7czoxMDoiaW1hZ2VGaWVsZCI7czowOiIiO3M6MTg6InNlYXJjaF9lbmNvZGVfdGltZSI7aToxMjk5OTAwMzg0O30="
当我修改关键词框提交信息为
1
返回了下面的url
/search.php?category=0&keywords=1%3C%2Ftextarea%3E%3Ciframe+src%3Dhttp%3A%2F%2Fwww.fengblog.org%2F+width%3D800+height%3D160+frameborder%3D0+%3E%3C%2Fiframe%3E&imageField=
再次访问,才给编码…
可以看出,search.php对"keywords"文本框的提交内容进行base64的编码,虽然也对所提交内容使用htmlspecialchars()进行了过滤,程序也比较给力,在meta的keywords和title都有显示….(其实我也习惯这种方式开发,考虑seo嘛)
但是,代码确是在
在这里被运行的. 嘿嘿…
临时解决方法
关注第search.php页面,第108行,
$_REQUEST['keywords'] = !empty($_REQUEST['keywords']) ? trim($_REQUEST['keywords']) : '';
如果关键词不为空,则返回关键词,否则返回空…
可是,考虑到关键词是用户提交过来的,如果是恶意提交呢?
修改为
$_REQUEST['keywords'] = !empty($_REQUEST['keywords']) ? htmlspecialchars(trim($_REQUEST['keywords'])) : '';
还有另外一种方法,直接过滤 REQUEST,POST,GET但似乎这种全局过滤的效率…
(2) "./pick_out.php" 页面跨站漏洞
测试代码
url访问
/pick_out.php?cat_id=9&attr[173]=%253CScRiPt%253Ealert%2831944027%29%3B%253C%2FScRiPt%253E
分析:
Pick_out.php这个xss似乎只支持数值型的跨站.
看的出来,在第33行对value变量进行了过滤,但提交的arrt似乎在模板里被执行了.
我的思路陷入第23行的if开始,但似乎都不是好办法,
尝试性对$_GET['arrt']过滤,但插在哪里似乎都不合适.
(3) "./message.php" 页面跨站漏洞
测试url
/category.php?id=3&brand=0&price_min=0&price_max=0&filter_attr=1%00%22'%3E%3CScRiPt%20%0a%0d%3Ealert(31944027)%3B%3C/ScRiPt%3E
/category.php?category=3&display=text&brand=0&price_min=0&price_max=0&filter_attr=1%00'%22%3E%3CScRiPt%20%0a%0d%3Ealert(31944027)%3B%3C/ScRiPt%3E&page=2&sort=goods_id&order=DESC
分析:
似乎和上面的相似,也是只支持数字的提交,换成字符串测试不通过,但没有转码测试,通过测试可以得知, 问题出现在对filter_attr的处理上.
当变量filter_attr_str在第53行被提交的时候,就没有考虑过滤.
将第53行修改为
$filter_attr_str = isset($_REQUEST['filter_attr']) ? htmlspecialchars(trim($_REQUEST['filter_attr'])) : '0';
搞定
(4.1) "./exchange.php" 对cookie过滤不严密造成跨站
测试cookie
这个页面下的cookie中,ecs_id的值是随机生成的,后面跟了一个ecs[display],被xss的正是这个ecs[display],由于是测试环境,构造其为“ECS%5Bdisplay%5D”,将其cookie修改为
ECS_ID=ad523fc010e952d531bab991c4679388cc1d9c80; ECS%5Bdisplay%5D=1>">
测试ok,至于ecs_id,这个值不用管它,随他自己生成.
(4.2)接下来是基于模版的xss,这是因为,模版中的
这句里面的 smarty.server.PHP_SELF 变量的功能是返回当前url,但是,这种返回,是指返回用户浏览器中的url框中所提交的值,对此值并未过滤.
以至于,用户提交什么就返回什么,从而形成XSS
先说”exchange.php”页面
测试url
. /exchange.php/>">
*(5)涉及(4.2)中提到问题所存在的问题页面
Auction.php
Message.php
User.php
(exchange.php)
测试url构造方式与(4.2)所提到的方式相同.
(6) “./article_cat.php”页面存在 SQL injection漏洞
测试url
./article_cat.php?id=5&page=%2527
./article_cat.php?id=5&page=’
. /article_cat.php?id=5&page=feng'"
直接访问测试url,返回的内容中暴露了数据库名和一些相关表名,是不是与之前category.php的注入漏洞有些相似呢?
漏洞的详细利用方法在此不想再提及
此漏洞在这个页面中的第50句
$page = !empty($_REQUEST['page']) ? intval($_REQUEST['page']) : 1;
获取当前页码,若页码不为空,返回页码,否则返回1
这里疏忽了对当前页码进行判断,因为它是访问者 request而来的数据,
虽然只是强制将$_REQUEST['page']转换为整数类型
既然是数值型,那么这里未对其值进行判断就直接疏忽了
建议修改为
$page = !empty($_REQUEST['page']) ? intval(is_numeric($_REQUEST['page']) ? $_REQUEST['page'] : "1") : 1;
漏洞解决…
对此,目前已发现的都在上面所提及,整理时间有些仓促,语言上可能有些不连贯,晦涩之处,还望多多谅解, 加之本人水平有限,不当之处,还望提及讨论.
谢谢!
(这份文档可能在官方漏洞发布补丁之后3天内更新到我的blog上, www.fengblog.org,也是为了增加内容嘛...)
Feng
2011.3.13
------------------------------------------------------------------------------------------------------------------------------
可以看出,官方演示站 ecshop.cn并未更新程序.
对sql注入,官方似乎不太在意...
由于所在国之相关法律的原因,我不能公开ecshop exp
以及详细利用方法,但是可以提示给各位的是,可以尝试cookie相关的手法来update..嘿嘿
另外,今天 ecshop最新版全补丁程序,仍然存在大量漏洞,我表示很无语...
今天所发现的漏洞会在之后抽时间汇总之后,连同补丁一同放出
希望echsop厂商能正视自己所存在的问题! 抓紧更正!
对漏洞报告流程精简,难不成你们还要审批啊!
对国内厂商对自己产品不负责任的态度表示强烈的鄙视!!!!!
请问article_cat.php那个文件应该怎么利用呢？请问你有没有QQ或者MSN，我最近在看ECSHOP的一个网站，一直没什么进展，看到你写的这个文章，希望能教教我article_cat.php那个文件改怎么利用？
关于这里提到的漏洞,官方的补丁已经解决掉了,在官方的下一个补丁出来之前,这里是不会有任何透露的.
另外,我建议你辗转关注shopnc,很快会爆出很多漏洞出来....hoho~
ecshop被shopex收购后，shopex官方早就放弃了维护了
大牛 现在可以透露下article_cat.php里$page 利用方法吗 期望指导下
厉害，会长期关注您的blog，
为什么代码看起来像乱码呢？
1.$page = !empty($_REQUEST['page']) ? intval(is_numeric($_REQUEST['page']) ? $_REQUEST['page'] : "1") : 1;
实际应该显示成这样呀？
$page = !empty($_REQUEST['page']) ? intval(is_numeric($_REQUEST['page']) ? $_REQUEST['page'] : "1") : 1;
引号的编码也自动变化了.....在我的评论里.....那些乱码的内容，在评论里贴出来后反而正常了。除了双引号外。
这是由于在我的blog转换之后,有些字符上的差异...... 很费解关于双引号的这个事, wordpress插件折腾的...
article_cat.php 怎么利用呢，已经快一年了，官方貌似已经出补丁了，求公布