漏洞概要 关注数(24) 关注此漏洞
缺陷编号：wooyun-2015-0115195
漏洞标题：网站安全狗SQL注入拦截bypass
相关厂商：安全狗
漏洞作者： RedFree
提交时间：2015-05-20 17:52
修复时间：2015-07-05 18:08
公开时间：2015-07-05 18:08
漏洞类型：设计缺陷/逻辑错误
危害等级：中
自评Rank：5
漏洞状态：厂商已经确认
漏洞来源： http://www.wooyun.org，如有疑问或需要帮助请联系 [email protected]
Tags标签： 无
漏洞详情
披露状态：
2015-05-20： 细节已通知厂商并且等待厂商处理中
2015-05-21： 厂商已经确认，细节仅向厂商公开
2015-05-31： 细节向核心白帽子及相关领域专家公开
2015-06-10： 细节向普通白帽子公开
2015-06-20： 细节向实习白帽子公开
2015-07-05： 细节向公众公开
简要描述：
网站安全狗注入防护存在缺陷，可被绕过。
详细说明：
针对asp+access,首先来挖掘一下数据库的特性。
1、可以代替空格的字符有：%09、%0A、%0C、%0D，如图：
2、可以截断后面语句的注释符有：%00、%16、%22、%27
%22(")、%27（')为什么会截断后面的语句呢，后来详测了一下这两个字符是在特殊条件下才能起到注释的效果。
但实测%00和%16不受条件限制。
开启安全狗的防护功能再测试执行SQL语句：
可以看到执行的语句被拦截。
实际测试得知安全狗拦截select + from，但不会拦截select + xfrom或select + fromx(当然x为一些特殊字符的时候依然会被拦截)。
安全狗匹配的是正常的sql语句，错误的语句并不会触发规则。但是语句是错误的，如何去得到理想的结果呢？
即然安全狗拦截的是select + from，那么正则匹配的长度是不是无限大呢？有没有可能构造出一段非常长的语句刚好达到匹配的极限，使from和后面的语句不能被匹配呢？带着这个疑问做如下测试：（已知道sql语句中一个分割符和多个分割符的执行效果是一样的）
果然，当%09、%0A、%0C或%0D超过一定长度后，安全狗的防御便失效了！
实际测试，from前字符串长度为49151（3*2^14-1）。而当使用空格时，这个长度会更乱短！
from前仅仅527个字符，便让防御失效了（171个空格）！
看来安全狗对170和49152这两个数字特别敏感哦！
漏洞证明：
测试语句：
170个空格：
171个空格：
突破拦截后，后面再跟上一些带有关键字的语句：
修复方案：
不能指哪修哪哦，同一个问题在不同功能上的体现！
版权声明：转载请注明来源 RedFree@乌云
漏洞回应
厂商回应：
危害等级：中
漏洞Rank：9
确认时间：2015-05-21 18:07
厂商回复：
感谢RedFree对安全狗的关注, 研发部门已经开始着手修复. 此漏洞目前通杀市面上大部分的WAF产品. 请将你的地址发送给我们. 我们将会给你发送礼品.
最新状态：
暂无