漏洞概要 关注数(25) 关注此漏洞
缺陷编号: WooYun-2014-68500
漏洞标题: phpyun绕过360艰难的SQL注射
相关厂商: php云人才系统
漏洞作者: Map
提交时间: 2014-07-14 18:53
公开时间: 2014-10-12 18:54
漏洞类型: SQL注射漏洞
危害等级: 高
自评Rank: 10
漏洞状态: 厂商已经确认
漏洞来源:www.wooyun.org ,如有疑问或需要帮助请联系
Tags标签: sql注射漏洞利用技巧 后台验证绕过
漏洞详情
披露状态:
2014-07-14: 细节已通知厂商并且等待厂商处理中
2014-07-14: 厂商已经确认,细节仅向厂商公开
2014-07-17: 细节向第三方安全合作伙伴开放(绿盟科技、唐朝安全巡航、无声信息)
2014-09-07: 细节向核心白帽子及相关领域专家公开
2014-09-17: 细节向普通白帽子公开
2014-09-27: 细节向实习白帽子公开
2014-10-12: 细节向公众公开
简要描述:
想在PHP云里进行一次SQL注射,真的是好难。
详细说明:
我首先发现了一个SQL注射,这个过程也不轻松。
在phpyun/model/class/action.class.php中
注意那句
,没错,只要m为空,那么这个后台的操作是可以被任何人操作的,正好,有一个操作就存在SQL注射漏洞。
在/phpyun/admin/model/index.class.php中的代码里
$_POST['chk_value']直接来自POST,直接进入了SQL语句。
但是如果你想POST内容,那么你还需要pytoken,这个又怎么拿到呢。
注意这一句
不过这个没问题,在登陆的页面就有,访问:http://localhost:8038/phpyun/admin/就可以取到。
好,接下来就是最糟糕的地方了,360的防御。
查看data/db.safety.php会找到相应的代码,怎么bypass呢?
怎么绕过呢,简单来说,只需要是多个数组就可以绕过了。
看,出现了新的情况,or被替换成了Or。
这部分的代码在:
如何避免被替换呢,有两个方法。
1,"%20"=>""
看,%20被替换成空了,我们只需要提交
%2520会被webserver转换成%20,%20就会被删除,留下的就是or了。
只需要知道sy_safekey,就可以实现SQL注射,sy_safekey怎么生成的。
如果我们想让服务器挂掉或者查询当前的数据库环境,很容易,我们可以很轻松的sleep或者获取当前运行的数据库信息了,这些不依赖select字符的事情我们都可以做了。
但是如果我们想做更多的事情,那么,我们就需要写个程序,post safekey到http://localhost:8038//phpyun/index.php?m=com&c=search&keyword=count,最多7999万次直到返回的count是count而不是Count,那么你就获取了sy_safekey,那么你就可以为所欲为了。
漏洞证明:
如果我们想让服务器挂掉或者查询当前的数据库环境,很容易,我们可以很轻松的sleep或者获取当前运行的数据库信息了,这些不依赖select字符的事情我们都可以做了。
但是如果我们想做更多的事情,那么,我们就需要写个程序,post safekey到http://localhost:8038//phpyun/index.php?m=com&c=search&keyword=count,最多7999万次直到返回的count是count而不是Count,那么你就获取了sy_safekey,那么你就可以为所欲为了。
修复方案:
foreach后intval
版权声明:转载请注明来源 Map@乌云
漏洞回应
厂商回应:
危害等级:高
漏洞Rank:13
确认时间:2014-07-14 21:30
厂商回复:
感谢您的提供,我们会尽快修复!
最新状态:
暂无
漏洞评价:
对本漏洞信息进行评价,以更好的反馈信息的价值,包括信息客观性,内容是否完整以及是否具备学习价值
漏洞评价(共0人评价):
登陆后才能进行评分
评价
-
@Map 本地测试了下,确实是自己没搞明白数组这块,复参与webserver有关是参考的http://www.80sec.com/%E6%B5%85%E8%B0%88%E7%BB%95%E8%BF%87waf%E7%9A%84%E6%95%B0%E7%A7%8D%E6%96%B9%E6%B3%95.html 里面提到“大家应该还记得09年的HTTP Parameter Pollution攻击,查看[3]文档,可以发现ASP/IIS和ASP.NET/IIS的场景下存在一个复参特性,本文将利用这种的特性的攻击简称为复参攻击”,当时看到列出的几个不同webserver不同语言的接收情况,就认为应该是webserver的问题,不过听你说完仔细一想,确实应该是应用程序接收参数处理的问题而与webserver无关,只是凑巧asp和asp.net都用IIS承载而已
9# 回复此人
评论