Part1 前言
大家好，上期分享了一次MS12-020蓝屏漏洞的巧用。这篇文章源于之前做的一个银行红队项目，遇到到了一个Oracle数据库的SQL注入漏洞，但是网上能搜索到的各种SQL语句都没法出数据，所以客户不认可这个漏洞的危害性，于是就开始了对这个Oracle的SQL注入绕WAF的探索过程：
Part2 研究过程
- SQL注入判断过程
经过对Web应用一系列的手工漏洞测试，发现这个网站对Web漏洞的拦截至少有两层防护：
1. 外网部署了WAF设备拦截，对常规的SQL注入关键字有拦截；
2. 绕过外围的Waf设备后，发现应用程序本身也对SQL注入漏洞进行了严格的过滤；
这相当于两个WAF串联的情况，非常难解决。接下来看一下这个注入点情况：
使用burpsuite不断地抓包重放，当看到这个POST请求的时候，proCode=002&specIds=8866@871（防止泄露项目信息，原来的数据包就不贴图了），发现参数的值中有一个@符号，直觉和经验告诉我，就觉得这里面会存在安全问题。因为我猜想，参数值为了保留@这个特殊字符，一定会对很多危险字符做出让步。所以重点对specIds参数进行了测试，还真发现了SQL注入漏洞。这个注入漏洞是这样判断出来的：
proCode=002&specIds=8866@871*(1-0)，返回正常
proCode=002&specIds=8866@871*(1-1)，返回错误
- SQL注入拦截关键字判断
这些都是SQL注入漏洞的基础，这里就不细讲了。接下来要做的是通过这个注入漏洞跑出数据，否则客户不认可这个漏洞。
首先看一下这个注入点过滤了哪些字符，specIds参数经过大量的手工测试，发现至少有以下过滤：
1. and、or 、xor、like、true等常见SQL语句的关键字通通不能用，大小写转换也不行。
2. substr、ascii、CHR、wm_concat、lower、upper等Oracle常见sql语句出数据的关键函数不能用。
3. | 、<、>、!等被干掉。（对于Oracle注入来讲，|竖杠被过滤掉，受限是非常大的）
4. select、from等SQL注入出数据的关键字被干掉。
看到这里感觉挺难的，但是比较幸运的是，这个specIds参数的单引号、（）左右括号、*没有过滤。尤其是单引号没被过滤，这个非常关键，为这个注入漏洞能够跑出数据留下了一线生机！
- 查看Oracle数据库手册
select、from这两个关键字被过滤了，想要出数据很难的。于是我从网上各种搜索，把Oracle数据库的关于数据查询的各种函数都找出来了，测试了一遍，几乎全被拦截掉了。但是幸运的是有一个instr函数成功绕过了所有防护，没被拦截。
接下来看看Oracle数据库手册上对INSTR函数的用法怎么描述的（这些翻译过来的中文使用说明看起来非常难以理解，我看了大半天才看明白）：
语法: INSTR（string1, string2[a,b]）
功能: 得到在string1中包含string2的位置。string1是从左边开始检查的，开始的位置为a，如果a是一个负数，那么string1是从右边开始进行扫描的。第b次出现的位置将被返回。a和b都缺省设置为1，这将会返回在string1中第一次出现string2的位置。如果string2在a和b的规定下没有找到，那么返回0。位置的计算是相对于string1的开始位置的，不管a和b的取值是多少。
根据手册构造出了以下SQL注入语句：specIds=816Q@Q871*(instr(sql插入点,'%s',%s)-(%s-1))
“sql插入点”需要替换成我们想要查询的sql语句，这里需要找一个不包含select、from的语句写法，最终经过测试，发现以下语句可行：
utl_inaddr.get_host_address()，组合起来就是：
specIds=8866@871*(instr(utl_inaddr.get_host_address(),'%s',%s)-(%s-1)) &channelId=128
- python脚本编写
以下是我写的python脚本的一个片段，我把域名、url地址都给打码了，大家可以照着改出一版自己的小脚本：
Part3 总结
1. Oracle注入、Mysql注入等等遇到过不了的WAF，多去查查相关数据库的各种特殊函数，非常有用。
2. SQL注入漏洞的防护最好使用预编译，对于不能使用预编译的情况，记得过滤的关键字一定要全面。
3. SQL注入漏洞深挖，总会有的。业务复杂度越来越高，各种研发人员更替，研发人员水平参差不齐，业务着急上线疏忽了安全问题整改等原因造成了这一现象。
