0x00 背景
之前wooyun上经常也看到一些bypass的方法,如利用mysql的特性bypass web程序的防注入函数,又例如直接构造绕过防注入的正则等等。最近在编写IPS特征的时候,发现在一些其他的角度上可以做到绕过IPS防护,下面就将这些另外的角度做一个总结。在描述的时候涉及到一些网络层面的基础知识,这里不单独叙述,在利用姿势里面强调。
Ps.此处说明,方法不代表能bypass掉所有的IPS。
0x01 bypass姿势
IPS性能优化导致IPS规则bypass
做过IPS测试的选手应该都会听到过这样一句话,厂商在保证检测率90%的条件下,性能是多少。这里所说的性能一般是性能测试中涉及的新建,并发,吞吐等等指标。此处不叙述这些指标。
从上面可以看出IPS的检测效果和性能是有一个平衡关系的。先来描述一些基本概念,第一个概念是数据流和会话的概念:
在网络基础中有五元组的概念,即为源地址,目的地址,源端口,目的端口以及协议号,五元组相同即认为是一条同样的会话,当你在浏览器中访问www.wooyun.org的时候,打开wireshark抓包工具抓包,然后follow下这一条stream可以发现如下内容。这也就是所描述的会话和流。
IPS中一般是通过会话,流来进行检测的。如何来通过会话来检测呢,这里有第二个概念需要了解,第二个概念为重组:
为什么要重组,一个以太网包的最大长度为1518字节,譬如我们这时候发送一个大附件出去,此时就会把数据分成多个数据包发送出去,数据包在internet上转发的时候会被路由转发,在整个internet中转发的时候会出现乱序,导致有些数据包先到IPS设备,有些数据包后到IPS设备,此时就需要IPS将发送的数据包,完整的组合起来。因为组合起来之后才可以方便后面的数据分析,提取内容。如下图所示:
现在问题就来了,如果对于每条数据流的所有内容都做检测应该就没问题了,但是每条数据流的所有内容都进行检测,肯定所耗费的资源也就越多,应该大部分厂商不会检测数据流的所有包。因此就会出现个问题,到底检测多大的大小呢?在处理这个问题的时候有些使用的是包数,有些使用的是流大小的方法。但是这都会导致所说的一个问题,就是性能优化导致的bypass。如下图所示:
在该数据流中,前面多个包如20个包没有发现特征,20个包之后的内容不再做ips检测,这样后面的包里的特征就没有受到IPS引擎的检测。
利用:
例如我们在绕过bypass的时候,人为的将get方式提交改为post方式提交,同时在提交的时候,添加大量的填充数据,如使用post的方式,上传一个大的文件,虽然这部分填充数据不会被服务器端所处理,但是在通过IPS设备的时候就会被解析处理,有可能就bypass掉了ips的检测。
截断绕过IPS规则
Ips规则即为经常说到的ips特征,见到过的很多IPS特征都是根据不同协议来分的,如http,smtp,pop3,tcp,udp等等,每一种协议下又可以有不同的内容,如http协议下可以有cookie,header,msgbody等等。
这些特征都会被以一种算法加载到内存中,然后等到数据流解析完毕之后,进行匹配。因此这里又涉及到了一个基础概念:协议解析。
协议解析为啥?即将上面重组过后的信息,提取相应的内容赋值给协议变量。打个比方,如http协议,在重组完成之后肯定会出现http标准的内容,http的cookie,header,method等等,因此IPS会根据标准的内容解析,然后将解析的内容赋值给类似http_cookie,http_method的变量。有了这些变量就可以对数据流进行IPS特征匹配了。效果如下图所示:
解析出来各种http的相关内容,当然不同的协议解析出来的内容不相同,有的可能是smtp,tcp等等。
但是在这个过程中,如果程序员处理的不好,就会出现IPS bypass的情况。
举个例子,例如某漏洞的特征为search{xxxx},特征利用正则编写,需要匹配search{},括号内容随意,此时,攻击者提交search{sada%00},这样在协议解析的时候出来的结果是search{sada,不会匹配到后面的}符号,导致了bypass。
编码绕过IPS规则
url编码绕过IPS规则同样存在可能性。
在IPS中对于同一种协议可能有多种协议变量,如HTTP中可能有没有url_decode的协议变量和进行了url_decode的协议变量,如果没有正确使用也会导致IPS规则绕过。
浏览器在发送数据包的时候,会对url进行编码,而且不同浏览器的编码还不相同,例如chrome对于单引号编码为%27,但是IE浏览器对于单引号不做编码,同时浏览器对于英文字符都不做编码的。
之前碰到了一个例子,在IPS规则中,书写特征的人员使用了未解码的协议变量书写特征,如特征为包含search关键字,此时我们可以这样bypass规则,将search书写为%73earch,这样当数据包经过IPS设备的时候,内容未作解码还是为%73earch,未匹配上规则,而到服务器端时候,被解码为search。
因此这里说,在做web测试的时候,尽量编码一些英文字符提交,可能会有惊喜。
请求方式绕过IPS规则
http常用请求方式有GET和POST两种方式,POST提交的时候又常见的有www/urlencode的方式和multipart的方式,后者常常用于文件上传。 查看一些CMS的源码,经常会发现有类似的代码,如下代码摘抄自dedecms:
#!php
if (!defined('DEDEREQUEST'))
{
//检查和注册外部提交的变量
foreach($_REQUEST as $_k=>$_v)
{
if( strlen($_k)>0 && preg_match('/^(cfg_|GLOBALS)/',$_k) )
{
exit('Request var not allow!');
}
}
foreach(Array('_GET','_POST','_COOKIE') as $_request)
{
foreach($$_request as $_k => $_v) ${$_k} = _RunMagicQuotes($_v);
}
}
可以看出无论get提交,cookie提交,post提交对于web服务器端,其实效果是一样的,但是对于IPS就不一样了。在我接触的不同的IPS中,对于不同http请求部分,拥有不同的协议变量,同时不同的协议变量也有解码和未解码之分。
举例,如dedecms中的一个漏洞,uploadsafe.inc.php界面的错误过滤导致recommend.php页面可以sql注入。网上给出的POC通常是一个url,直接粘贴到浏览器,即可以获取到了管理员账号密码,因此一些IPS规则通常就直接书写了一个httpurl解码的规则。
很容易此处更换一下提交方式,使用post的方式,无论是urlencode的方式还是form-data的方式,均可以绕过该规则。
此处如果发现post方式被过滤了,此处对于post的内容进行编码,然后再提交,仍然存在可以绕过的可能。
因此各位在编写payload的时候尽量使用编码过的post方式提交,成功的概率大一点。
Ps.之前wooyun上看见有提交二进制文件混淆绕过的,此处暂时没有想到为什么。
其他方式绕过IPS规则
1:对于host以及useraget的修改 一般不要使用默认的useragent,如使用一些自定义或则模拟浏览器的http-header字段。如那些sqlmap的特征可能就是针对于useragent做的文章。
2:字符混淆 尽量不使用网上公开的poc,针对于一些payload中可控的部分做字符混淆,使用字符填充等等。
3:漏洞利用方式 例如之前报过dedecms的recommend的注入漏洞,该漏洞是因为uploadsafe.inc.php界面导致的,其实利用页面还有flink.php等等,网上利用的最多recommend的poc,因此使用flink.php的页面可能就绕过了dedecms ips特征的防御,又如牛B的dedesql.class.php的变量覆盖漏洞,网上大多poc是基于download.php的,其实erraddsave.php等其他页面也是可以利用的,使用一些非主流POC的利用页面,也是可以bypass掉ips特征的。 一般的IPS特征都与基于一个页面来写特征,避免误报的。
0x02 总结
IPS和WAF网络攻击的防护设备,往往为了自身的一些如性能的提升,而放弃了一些功能,例如我见过有些IPS规则在编写的时候不支持正则表达式。可能就是正则表达式匹配的时候会大大的影响性能。由于这些功能上的放弃,必然导致各种各样规则的bypass,作为用户既需要这些防护设备,同时也需要做好自身网络安全的提升,如服务器的补丁,相关服务器的实时监控等等。
学习了!
这个好!
非常不错,学习了
其实ips bypass跟waf差不多
好文啊
用不了??
好文,通俗易懂。大赞。
强烈建议打赏功能正常起来好吗!
楼主这篇文章直接导致zone上的杀狗大戏
不明觉厉
好文
好的东西,往往复杂多变