前言
在插件发布后许多师傅都使用了这款 SQL 注入检测插件,在使用过程中发现了很多问题,在这里也是十分感谢对插件提出改进意见的师傅们。
师傅们反映的主要问题还是此类插件一个老生常谈的问题——误报。尤其是刚发布时,一旦访问 bilibili 这种页面资源很多,包含很多 API 请求的站点时误报率非常严重,而误报的原因主要也是产生在时间型盲注上和Yaklib的一些bug。
场景分析
在对现实环境站点做渗透测试时往往会遇到很多特殊情况,例如 WAF 拦截等。尝试过手工测试的师傅可能经常遇到虽然能够命令执行但是没法反弹 shell 的情况。这就是受到靶机环境影响的一个情况。一个泛用性检测插件,对于所有特殊情况都做考虑是很困难的,因此我们选择性地对一部分场景做了优化处理。
1.由于请求过于频繁导致链接被服务器直接断开,或者直接返回空的响应体
这点如果没有做好处理,就会在对参数进行 positive 和 negative 测试时出现误报,这个点是很关键的,因为只有在进行 positive 和 negative 测试后确定参数是 dynamic 时才会接着利用各种注入技巧对参数进行进一步细分化的 SQL 注入测试(Union 型 时间型),在之前版本中 Yak 引擎内部的 httpool 在遇到请求错误时,会把错误封装到返回结果中,而不是直接以 _, ok 的形式显式的展示出请求过程中出现问题,同时读取响应体也会正常的给出一个空的字符串。因此会出现,在对参数进行 negative 测试时可能因为目标服务器断开连接等错误出现误判。
2.请求量过大导致时间盲注非常不准确
时间盲注可以说是相当难处理的部分了,且听我慢慢道来…
首先在现代的后端代码中,对于数据查询都是会做比较精细的配置的,例如 timeout 这种参数,会在进行数据查询时被传入。如果我们sleep时间过长,就算确实存在注入也会导致因为sleep时间过长使服务器断开连接,或者是返回一些意料外的错误。
同时因为SQL注入检测的脚本应用场景是在被动扫描场景下的,Yak 的 MITM 对网站进行访问,同一站点的大量请求在同一时间涌入,就会在短时间对同一网站进行过多扫描。在使用 sqlmap 时,会看到 sqlmap 提示在测试期间不要 tense 网络,也就是说如果我们在使用 sqlmap 扫描时,若网络繁忙拥堵,很大概率也会让 sqlmap 产生误报的情况。
现阶段我们的脚本能进行的速率限制是很有限的,在之前版本的 SQL 检测脚本没有对请求速率做限制,导致误报率居高不下。但是说到底,只要我们使用了时间盲注,那误报基本就是不可避免的,因为网络延迟的不确定性和随机性。
打过CTF的师傅在使用python脚本进行半自动盲注测试时肯定也对这种问题深有体会,在使用WIFI网络跑时间盲注脚本时可能出现flag的个别位出现误判等问题。
3.Fuzz 模块的 bug
这个其实是因为 Yak 中的 Fuzz 模块的小 bug,当我们调用:
params := freq.GetCommonParams()
尝试获取某次HTTP请求中的参数时,Fuzz模块会尝试获取POSTGETCookie等参数,而在这个过程中因为传递的结构体比较复杂,在进行拷贝的时候应该使用深拷贝,确保原数据不被修改,此处因为拷贝处理的不是很好,导致参数在模糊测试时出现bug,在一次请求中很多参数的值都被渲染为 SQL 注入测试用的 payload,导致出现误判等问题。
修复与应对措施
1.对插件进行限流
2.修复mutate库中因浅拷贝未进行还原导致原参数污染的bug
3.降低部分判定的警告级别
结语
现在更新后的插件和Yak已经发布,请将Yak和插件更新到最新版本使用。
招聘需求(base成都)
往期内容推荐