漏洞概要
关注数(24)
关注此漏洞
漏洞标题:苹果CMS绕过检测SQL注入,第四发(绕过360防护)
提交时间:2014-06-26 10:59
修复时间:2014-09-24 11:02
公开时间:2014-09-24 11:02
漏洞类型:SQL注射漏洞
危害等级:高
自评Rank:20
漏洞状态:厂商已经确认
Tags标签:
无
漏洞详情
披露状态:
2014-06-26: 细节已通知厂商并且等待厂商处理中
2014-06-26: 厂商已经确认,细节仅向厂商公开
2014-06-29: 细节向第三方安全合作伙伴开放
2014-08-20: 细节向核心白帽子及相关领域专家公开
2014-08-30: 细节向普通白帽子公开
2014-09-09: 细节向实习白帽子公开
2014-09-24: 细节向公众公开
简要描述:
原来我之前说的那些都成废话了,厂商没有看懂,囧~,看回复把过错归结于360_safe3.php,不再发了,总结下原因。
详细说明:
index.php:
上面可以看到传递过来的参数$m经过be()转移看似很安全,-号分割数组后遇到神奇的$colnum,在$colnum中的变量intval处理,不在的呢?直接urldecode,我虽然没看明白为什么这样,当然最后得看这些变量会传递到哪里,所以这里难道仅仅是一个year写成yaer所造成的注入么,继续往下看,下面会包含inc/module/$ac.php
所以我们先看看vod.php:
如果说第一发是因为year写错了导致不在$colnum中,避过了自身be()的处理和360防护脚本,那下面的其他参数呢,比如letter,area,where,des,lang,pinying,等等这些都没有经过其他过滤,所以直接urldecode了一次,所以可以注入的地方就很多了。当然不仅仅是这个页面,module下的其他页面也存在这个问题,就请厂商自行排查了。
漏洞证明:
所以注入点很多,比如我们拿之前没有测试的letter来测试:
这才是罪魁祸首,由这处错误引起的其他注入不再发了。
修复方案:
漏洞回应
厂商回应:
危害等级:高
漏洞Rank:15
确认时间:2014-06-26 11:48
厂商回复:
在0602版本中测试已经被脚本拦截。下载地址更新:http:///
最新状态:
暂无