Oracle注入简单挖掘-绕过姿势

  • A+

Oracle注入简单挖掘-绕过姿势

背景

  在进行SQLi测试的时候,我们会发现我们提交的一些Payload会被WAF或者Filter过滤拦截掉。因此,通过优化的Payload在进行注入利用时具有更高的成功率,方便我们在探测到注入点时最大化的进行漏洞利用。如何在WAF和Filter下进行注入判断前面两篇文章已经提及了,最简单的东西总是最好用的,下面分享一些简单的深入利用的绕过姿势。

绕过WAF及SQLiFilter

  WAF是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的产品。其可以发现和拦截各类Web层面的攻击,记录攻击日志,实时预警提醒,在Web应用本身存在缺陷的情况下保障其安全。那么结合一些WAF本身的设计问题,即可进行绕过进行SQLi利用。

数据检测方式存在缺陷

  常见的业务数据请求方式有:GET型请求,普通POST型请求和上传POST型(multipart)请求。这里说的普通POST型请求指的是除了上传POST型请求之外的,上传POST型就是我们常见的文件上传数据包。
  一些WAF在进行数据包解析处理时,可能会存在类似的设计缺陷。例如在处理普通的GET、POST型请求时,会进行SQL注入、XSS等攻击特征的匹配。但是在处理上传POST型时,很可能只对类似恶意文件上传等攻击(文件上传包相关)进行检测,类似SQL注入等攻击就不再进行规则匹配了。那么此时若尝试以上传POST包进行业务提交,并且植入恶意的注入攻击语句,若服务器能解析的话,即可绕过WAF进行注入深入利用。
  有趣的是,现在大部分的开发框架,默认就满足上述以上传POST包提交数据完成业务的场景。以Java常见的SpringMVC为例:
  简单来说,服务器层面获取到前端请求后,接下来Spring MVC会收到服务器传来的request请求,此时若请求为上传POST型,Spring MVC会继续调用相关的解析器对其进行解析处理。以下是搭建的相关环境:
  正常情况下的数据包如下,查询业务,查询tkswifty成功返回对应的员工信息:

image001.png
  尝试以multipart方式提交(上传POST型),同样的服务器接收到参数后,相关框架也进行了解析并完成了查询业务:

image003.png
  那么此时若尝试以上传POST包进行业务提交,并且植入恶意的注入攻击语句,若WAF的数据检测方式存在缺陷的话,即可绕过WAF进行注入深入利用。
  此外,可能有些WAF在设计阶段已经考虑到了上述问题,在进行上传型POST数据包检测时,也会加入SQL注入等漏洞的检测规则。这里又引出另外一个问题就是,WAF是如何来判断当前数据包是上传型POST(multipart)数据包的呢?
  一般来说,很多都是通过HTTPHeader中的Content-Type进行判断的,当Content-Type的值为multipart/form-data;开头时,便认为当前数据包为上传POST型。那么对于框架来说,又是如何判断当前数据包为上传POST型的,是否存在绕过的可能。
  还是以Spring框架为例,追踪其MultipartResolver中的isMutipart()方法发现,其同样也是通过检测HTTPHeader中的Content-Type进行判断的,但是是先把获取到的Content-Type的值统一变成小写,然后检测是否为multipart/开头,是的话则认为当前数据包为上传POST型。
  那么这里又可以针对WAF的数据检测方式,尝试修改Content-Type的值,进行以下绕过尝试了:
- MULTIPART/form-data;(大小写替换)

image005.png
- multipart/;(删除form-data)

image007.png
- multipart/bypass;(替换无关数据)

image009.png
- ……
  可以看到,上述几种方式在Spring框架下都是可以正常进行业务解析的,若是WAF仅仅通过Content-Type的值是否包含multipart/form-data;来判断是否是上传型POST数据包的话,同样也会存在绕过的可能。
  综上所述,利用数据检测方式存在缺陷绕过手法如下:

image011.png

为业务和性能妥协

  由于要考虑到各种机器和系统的性能,对于一些超大的数据包,超长数据可能会跳过不检测。

image013.png
  在上传型POST数据包中,插入大量字符,有些WAF会直接不检测放行或者只检测其中的一部分(例如检测前面3W个有没有攻击特征,没有则放过)。
  针对这种,应该在WEB容器或者应用程序中来限定上传数据的大小。

规则通用性问题

  这里的话就是比较硬刚的思路了,很多时候WAF是通过黑名单的方式进行攻击特征检测的,那么我们只需要找到一些常见函数的替代品就好了。例如在Oracle注入场景中,类似casewhen,ascii(),substr()这些都是WAF的检测特征的常客。下面根据平时的一些积累,给大家分享下常用的一些Oracle注入绕过的函数:
- 使用decode()代替casewhen:

  casewhen在Oracle里,是做逻辑判断的,类似if…else…,常见的Payload如下:
case when 1=1 then 1 else 0 end(当1=1时返回1,否则返回0)

  那么这里使用decode()函数也可以达到异曲同工的效果,而且很多WAF都不拦截:
decode(1,1,1,0)

image015.png

image017.png
- 使用lpad()代替substr():
  因为要盲注,所以经常会用到字符串切割函数substr()。但是绝大部分的WAF都会对其进行拦截。
  那么此时可以使用lpad()进行代替:lpad(被填充的字符串,返回字符串的数量)
  可以通过第二个参数的值,返回切割的结果:

image019.png

image021.png
  综上,针对Oracle注入就可以得出一个新的利用Payload了:
  利用decode(lpad(想要拆解的内容,返回字符串数量),猜解的内容,返回值1,返回值2进行相关的盲注了。
  此外还有很多类似chr()、nullif()等函数也是不错的选择,欢迎各位表哥补充。
  附上一个大佬的注入cheat-sheet:
http://pentestmonkey.net/cheat-sheet/sql-injection/oracle-sql-injection-cheat-sheet
  除了WAF以外,开发人员也会针对web应用,在代码层写入对应的filter,用作对用户的请求进行预处理来达到拦截SQL注入的目的。其绕过的姿势其实与WAF类似。
  首先从github上随便找了个一个filter的demo:
  首先还是规则的通用性问题:

image023.png
  过滤的关键特征除了and、update等数据库共有的以外,其他规则可能都是针对MySql的一些特有的库名、函数等。那么此时若部署的数据库服务器是Oracle的,那么类似上面提到的decode()等Oracle特有的函数就成了漏网之鱼了,通过这个缺陷有可能就可以进行注入利用了。
  然后就是数据检测方式的缺陷问题,既然要对用户的请求进行预处理,那么肯定首先要获取到用户请求:

image025.png
  这里是通过request.getParameterNames()来获取到相关的参数,然后进行攻击检测的,但是request.getParameterNames()并不能获取到上传型POST(multipart)的数据,从而存在绕过SQLifilter的风险,下面利用这个过滤器,把环境搭起来了,以下是具体效果:
  正常情况下是可以获取到对应的参数然后进行恶意攻击检测的:

image027.png
  使用multipart提交后,filter就失效了:

image029.png
  同理,在filter中加入对上传型post检测时,如下的代码还是会存在上面提到的绕过可能:

image031.png

总结

  以上是日常渗透测试中遇到的一些比较常见的一些Oracle注入绕过姿势,当然还有例如分块传输等别的姿势,欢迎表哥们补充。

image033.png

相关推荐: CVE-2020-3956漏洞POC

漏洞概述 安全研究人员在对某财富500企业进行安全审计时,发现了一个影响VMware Cloud Director的代码注入安全漏洞。该漏洞CVE编号为CVE-2020-3956,CVSSV3评分为8.8分,漏洞严重等级为重要。 研究人员利用该代码注入漏洞,可…