主要的反NIDS技术应用介绍
2006-05-23    oasis   
打印自: 安恒公司
地址: HTTP://e1.anheng.com.cn/news/article.php?articleid=846
主要的反NIDS技术应用介绍

随着IDS(入侵检测系统)在网络环境中的使用越来越普遍,黑客在攻击一个装有IDS的网络时,首先考虑到的是对付IDS,一般采用的反IDS技术主要是"攻"(攻击IDS)或者"避"(绕过IDS的监视)。本文根据网上的IDS资料和笔者的实际研究,主要介绍一下当前主要的反NIDS(网络入侵检测系统)技术。

一.攻:包括直接攻击和间接攻击

  1. 直接攻击:直接对NIDS进行攻击。因为NIDS是安装在一定的操作系统之上,而且本身也是一个复杂的TCP/IP操作系统,这意味着NIDS本身可能受到smurf、synflood或jolt2等攻击。如果安装IDS的操作系统本身存在漏洞或 IDS自身防御力差,此类攻击很有可能造成IDS的探测器丢包、失效或不能正常工作。但是随着IDS技术的发展,一些NIDS采用了双网卡的技术,一个网卡绑定IP,用来与console(控制台)通信,另外一个网卡无IP,用来收集网络数据包,其中连在网络中的是无IP的网卡,因为没有IP,所以不能直接攻击,而且新的IDS一般采用了协议分析的技术,提高了IDS捕捉和处理数据包的性能,所以直接攻击NIDS这种方法已经行不通了。
  2. 间接攻击:一般的NIDS都有入侵响应的功能,如记录日志,发送告警信息给console、发送警告邮件,防火墙互动等,我们可以利用IDS的响应进行间接攻击,使入侵日志迅速增加,塞满硬盘;发送大量的警告信息,使管理员无法发现真正的攻击者,并占用大量的cpu资源;发送大量的告警邮件,占满告警信箱或硬盘,并占用接收警告邮件服务器的系统资源;发送虚假的警告信息,使防火墙错误配置,造成一些正常的IP无法访问等!

  目前,攻击NIDS最有效的办法是利用Coretez Giovanni写的Stick程序,Stick使用了很巧妙的办法,它可以在2秒内模拟450次攻击,快速的告警信息的产生会让IDS反应不过来、产生失去反应甚至死机现象。由于Stick发出多个有攻击特征(按照snort的规则组包)的数据包,所以IDS匹配了这些数据包的信息时,就会频繁发出警告,造成管理者无法分辨哪些警告是针对真正的攻击发出的,从而使IDS失去作用。当有攻击表现的信息包数量超过IDS的处理能力的话,IDS会陷入拒绝服务状态。Stick对许多IDS有影响,ISS公司的产品也不例外,该公司的产品中曾有"RealSecure Network Sensor 5.0"的Windows NT/2000版受到了影响,后来ISS发布了补丁,好像已经解决了这个问题。但其它一些公司的IDS,如snort,因为Stick发送的是按 snort规则组成的包,所以用Stick攻击装有snort的网络时,会产生大量的日志记录。

二.避:伪装自己,饶过IDS的检测,主要是针对IDS模式匹配所采用的方法来逃避IDS的监视。

  1.针对HTTP请求:

* URL编码:将URL进行编码,可以避开一些采用规则匹配的NIDS。

#二进制编码:HTTP协议允许在URL中使用任意ASCII字符,把二进制字符表示成形如"%xx" 的十六进制码,有的IDS并不会去解码。

如"cgi-bin"可以表示成"%63%67%69%2d%62%69%6e",有些IDS的规则匹配不出,但web服务器可以正确处理。不过现在大多数IDS已经是在匹配规则之前解码,目前这个手段已经不适用了,一般的IDS都可以检测到!

# %u编码,是用来代表Unicode/wide特征字符,但微软IIS web服务器支持这种非标准的web请求编码方式由于%u编码不是标准的编码,IDS系统不能解码%u,所以可以绕过IDS的检测。

例如:使用下列的编码方式就可以绕过一些NIDS对".ida"的攻击的检测。

GET /abc.id%u0061 HTTP/1.0

不过,snort1.8可以检测到这种编码后的攻击,但有一些公司的IDS没注意到这个问题。

解决办法就是在规则匹配前对URL内容的%u编码进行解码后匹配。

#unicode编码,主要针对IIS,将URL中的一些特定的字符或字符串(主要是针对一些IDS匹配的规则内容)用unicode编码表示,

例如:使用下列的编码方式就可以绕过一些NIDS对".ida"的攻击的检测。

GET /abc.id%c1%01 HTTP/1.0

snort1.8目前好象不能检测到这种编码后的攻击。采用通配符如"*string*"匹配的很多IDS应该都存在此类问题。

解决办法就是在规则匹配前对URL内容的unicode编码进行解码后匹配。

* 斜线问题:包括"/"和"\"。

# "/" 问题:如果在HTTP的提交的请求中把'/' 转换成 '//',如"/cgi-bin/test.cgi"转换成"//cgi-bin//test.cgi",虽然两个字符串不匹配,但对许多web服务器的解释是一样的。如果把双斜线换成三斜线或更多效果也是一样的。目前有些IDS无法检测到这种类型的请求。

# "\"问题:Microsoft用'\'来分隔目录,Unix用'/'来分隔,而HTTP RFC规定用'/', Microsoft的web服务器如IIS 会主动把'/' 转换成 '\'。例如发送"/cgi-bin\test.cgi"之类的命令,IIS可以正确识别,但这样IDS就不会匹配"/cgi- bin/test.cgi"了,此法可以逃避一些IDS。

* 命令问题:许多IDS系统检测时缺省认为客户提交的请求是用GET提交的,如GET /cgi-bin/test.cgi。但是相同的请求用HEAD命令也能实现,如用HEAD发送:HEAD /cgi-bin/test.cgi,则有些依靠get方法匹配的IDS系统就不会检测到这个扫描。

* 增加目录:插入一些无用的特殊字符,使其与IDS的检测内容不匹配。

如'..'意思是父目录,'.'意思是子目录,window下的"c:\tmp\.\.\.\.\"的意思就是"c:\tmp\";相应的unix下的 "/tmp/././././"和"/tmp/"等价。对"/cgi-bin/phf"可以任意变化成"/./cgi-bin/././phf等形式。

又如:GET /cgi-bin/blahblah/../test.cgi HTTP/1.0实际和"/cgi-bin/test.cgi"一样,目前一般IDS都能识别。

很多智能的IDS会把请求还原成正常的形式。

* 不规则方式:

#用tab替换空格(对IIS不适用):智能的IDS一般在客户端的数据中取出URL请求,截去变量,然后按照HTTP的语法格式检查请求。在HTTP RFC 中,http v1.0的请求格式如下: Method URI HTTP/ Version CRLF CRLFHTTP是按照空格来把请求分成三部分的。但是,Apache 1.3.6和其以后的版本(早些时候的版本可能也是)允许用tab去请求: Method URI HTTP/ Version CRLF CRLF这会使那些根据RFC协议格式处理这个请求的程序失败。但有的IDS为了减少误报会在匹配时用上空格。如"/phf"会很容易在字符串中匹配,但 "/phf(空格)"会减少很多误报, 这时对用tab的请求就没法匹配了。

# NULL方式:构造如下的请求: GET%00 /cgi-bin/test.cgi HTTP/1.0,由于在C语言中很多字符串处理函数用NULL作为字符串的结尾,如果IDS是利用c函数处理字符串的话,IDS就不可匹配NULL后面的字符串了。这种方式适合IIS,Apache不能处理%00。


* 虚假的请求结束:对有些智能的IDS来说,为了提高效率上和减少占有系统资源,对客户端发过来的数据,一般只会处理请求部分。

如发送如下请求:GET /%20HTTP/1.0%0d%0aHeader:%20/../../cgi-bin/test.cgi HTTP/1.0\r\n\r\n

解码后是这样的:GET / HTTP/1.0\r\nHeader: /../../cgi-bin/test.cgi HTTP/1.0\r\n\r\n

这是一个正确的请求,但对某些智能的IDS只会截取GET的命令行,发现"HTTP/1.0\r\n"后就结束,然后对截取得部分进行操作,所以智能的IDS就不能正确报告基于此cgi的攻击。

* 长URL(Long URLs):一些原始的IDS为了提高效率往往只检查前xx个字节,通常情况这样很正确,因为请求是在数据的最前面的,但是如果构造一个很长的请求: GET /rfprfprfprfp/../cgi-bin/test.cgi HTTP/1.0,超过了IDS检测的长度,这样就会使IDS检测不到后面的CGI。通常可以在请求中包涵1-2K个随机字符,但是有一些IDS会根据某些协议请求的长度来判断是否是缓冲区溢出,这时IDS就会对此类扫描误报为缓冲区溢出!

* 会话组合:把请求分开放在不同的包文中发出――注意不是分片,则IDS可能就不会匹配出攻击了。例如,请求"GET / HTTP/1.0"可以放在不同的包文中("GE", "T ", "/", " H", "T", "TP", "/1", ".0"),但不能逃过一些采用协议分析和会话重组技术的IDS。

* 大小写敏感:DOS/Windows与unix不同,它对大小写不敏感。例如:对IIS来说使用大小写是一样的,对有的老式IDS来说,可能造成不匹配。

针对HTTP请求进行欺骗的工具主要是Whisker,它采用了上面的一些技术进行WWW扫描,目前的IDS能发现绝大部分的欺骗方式,但对于采用URL编码(尤其是unicode编码)和不规则方式(如TAB替换空格)的扫描,有相当一部分IDS可能检测不到!


  2.针对缓冲区溢出:一些NIDS检测远程缓冲区的主要方式是通过判断数据包的内容是否包括/bin/sh或者是否含有大量的NOP。针对IDS的这种检测办法,有的溢出程序的NOP考虑到用eb 02 代替,但这种方式目前也已经成为一些NIDS检测是否为缓冲区溢出时匹配的标志。不过,k2先生又写了一个加密shellcode的程序 ADMmutate,利用了名为多形态代码的技术,使攻击者能够潜在的改变代码结构来欺骗许多入侵检测系统,但它不会破坏最初的攻击性程序。溢出程序经它一改,就可以摇身一变,而且由于采用了动态改变的技术,每次伪装的shellcode都不相同,本来NIDS依靠提取公开的溢出程序的特征码来检测报警,特征码变了后NIDS就检测不到了。

伪装前的shellcode格式为:

[NNNNNNNNNNNNN][SSSS][RRRR]

伪装后的shellcode格式为:

[nnnnnnn][dddd][ssss][rrrr]

其中:

N表示NOP,S表示shellcode,R表示返回地址;

n表示经过编码的NOP,d为解码器,s表示经过编码的shellcode,r表示返回地址。

经过ADMmutate伪装的shellcode可以逃过使用模式匹配并且利用字符串匹配的大部分NIDS!不过如果NIDS还依靠长度,可打印字符等等综合判断,则ADMmutate还是不能逃脱NIDS的监视,但是依靠长度、可打印字符等判断未必准确,以此判断会造成IDS漏报或误报。不过,对于使用模式匹配的NIDS来说,目前仍只能通过长度等简单的判断!

  3.针对木马:IDS检测木马和后门程序一般是通过端口来判断的,一般是通过后门程序的默认端口的连接来判断的,如Netspy的默认端口是7306, BO2k的默认端口是54320(1),所以只要后门程序不使用默认值就可以逃过一些IDS的法眼。目前大部分后门程序的通信都已采用加密的方式,所以目前的大部分NIDS只能通过非正常端口建立连接来判断,如果后门程序采用正常的端口进行通信,IDS就很有可能漏报!

  4.其它方法:

缓慢扫描:一般的IDS是通过在一定时间内某个IP扫描过的端口数或IP数是否超过阀值来判断是否扫描,所以如果扫描的间隔超过IDS中指定的时间,而且采用多个IP协同扫描的话,IDS就不能判断攻击者是否扫描。

地址欺骗:利用代理或者伪造IP包进行攻击,隐藏攻击者的IP,使NIDS不能发现攻击者所在。目前的NIDS只能根据异常包中的地址判断攻击来源。

利用LLKM处理网络通信:利用LLKM简单、临时改变TCP/IP协议栈的行为,如更改出现在网络传输线路上的TCP标志位,躲避一些IDS的监视。

复杂的TCP/IP包处理:利用IDS不能正确模拟所有的TCP/IP栈的可能行为,对TCP/IP数据包进行特殊的处理以避过IDS。如将TCP/IP 包分成很小的碎片,或者是打乱包的发送顺序,或者是发送重叠的包,或者是包含有不正确校验和、不正确序列号等,正常的TCP/IP软件可以正确重组和处理包,而有相当多的NIDS不能正确处理这些包,所以会忽略基于这种特殊包的攻击。测试NIDS关于TCP/IP包的处理能力,可以使用 fragrouter 或者 Cybercop Scanner。

结论:

由于目前的NIDS绝大部分是采用sniffer形式抓包,以模式匹配的方式检测和分析入侵,不能处理和分析加密或伪装后的数据包,特别是在网络负载流量高的情况下,许多NIDS会出现丢包现象,所以NIDS仍然存在误报、漏报的可能。黑客如果将上面的一些方法巧妙的结合起来,仍可以逃避目前一些 NIDS的监视。

[本文出处:安全焦点]

责任编辑: admin