黑客经验:针对IDS的逃避技术与相关对策

ZDNet软件频道 时间:2009-11-04 作者: | 中国IT实验室 我要评论()
本文关键词:黑客 IDS Windows
在网络蓬勃发展的几天,网络安全问题日益突出。网络上的黑、白两道在网络安全的各个领域都展开了激烈的竞争。黑帽社团不断推出躲避或者越过网络入侵检测系统(Network Intrusion Detection System,NIDS)的新技术,而NIDS的开发者不断地在自己的产品中加入对这些技术的检测。但是,由于NIDS本身的局限性,胜利的天平正在向黑帽子倾斜。本文将讨论一些基本的IDS躲避技术,以及如何识破这些技术。

  在网络蓬勃发展的几天,网络安全问题日益突出。网络上的黑、白两道在网络安全的各个领域都展开了激烈的竞争。黑帽社团不断推出躲避或者越过网络入侵检测系统(Network Intrusion Detection System,NIDS)的新技术,而NIDS的开发者不断地在自己的产品中加入对这些技术的检测。但是,由于NIDS本身的局限性,胜利的天平正在向黑帽子倾斜。本文将讨论一些基本的IDS躲避技术,以及如何识破这些技术。

  1.字符串匹配的弱点

  针对基本字符串匹配弱点的IDS躲避技术是最早被提出和实现的。一些基于特征码的入侵检测设备几乎完全依赖于字符串匹配算法,而对于一个编写很差的特征码,攻击者可以轻松地破坏对其的字符串匹配。虽然不是所有的入侵检测系统都是纯粹基于特征码检测的,但是绝大多数对字符串匹配算法有很大的依赖。这里,我们将使用开放源码工具snort的特征码来进行讨论。

  在UNIX系统中,/etc/passwd是一个重要的文件,它包含用户名、组成员关系和为用户分配的shell等信息。我们就从监视对/etc/passwd文件的访问开始,下面是用于检测的snort检测规则:

  alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-MISC /etc/passwd";

  flags: A+; content:"/etc/passwd"; nocase; classtype:attempted-recon; sid:1122;rev:1)

  snort使用字符串匹配算法对包含特征码(/etc/passwd)的HTTP请求进行检测。但是,这个规则的特征码过于简单了,攻击者修改攻击字符串可以很轻松地逃过检测(我们暂时不考虑攻击请求是通过HTTP发出的)。例如,把攻击请求由GET /etc/passwd改为GET /etc/////passwd,或者GET /etc/rc.d/.././/passwd,修改方式简直不计其数。这是最基本的娶亲检测逃避技术,对这种技术的检测也相对容易一些,只要在编写特征码时能够仔细考虑一下攻击可能出现的变体。目前大多数流行入侵检测系统都有非常强大的字符串匹配能力,足以检测此类攻击的大多数变体。不过,仍然有些编写不太好的特征码可以给攻击者以可乘之机。

  攻击者还可以在此基础上再加以变化,几乎不费吹灰之力就可以加大入侵检测系统的防御难度。例如在telnet之类的交互会话中,攻击者企图读取/etc/passwd文件。通常,入侵检测系统中存在很多特征码一些误用操作和后门等,但是这些特征码一般只包含黑客工具名、文件名和程序名。在获得/etc/passwd文件的内容时,我们不直接输入cat /etc/passwd等命令行,而是通过一个命令解释器(例如:perl)来实现我们的目的:

  badguy@host$ perl -e

  ‘$foo=pack(“C11”,47,101,116,99,47,112,97,115,115,119,100);

  @bam=`/bin/cat/ $foo`; print”@bam/n”;’

  从这个命令中,入侵检测系统根本就不会重组出/etc/passwd这些字符。显然,防御这种攻击就很困难了,因为这要求入侵检测系统必须能够理解这种解释器如何收到的命令,这恐怕不太现实。当然,入侵检测系统也可以对使用解释器的可疑行为进行报警,但是它很难对攻击行为进行精确的监视。

  通过把字符串处理技术和字符替换技术结合到一起,我们可疑实现更复杂的字符串伪装。对于WEB请求,我们不必使用命令解释器,在我们的请求中使用16进制的URL即可,以下的请求可以被目标WEB服务器解释为/etc/passwd:

  GET %65%74%63/%70%61%73%73%77%64

  或者

  GET %65%74%63/%70a%73%73%77d

  为了捕获这一个字符串的所有变体,你可能需要1000个以上的特征码进行字符串匹配,这还没有考虑UNICODE。UNICODE提供了另一种字符表达方式。有关UNICODE的IDS欺骗技术细节,本文将不多做讨论。如果想了解更多细节请参考SecurityFocus的IDS Evasion with Unicode。除此之外,RainForestPuppy在他的HTTP扫描工具Whisker中采用了另外一些IDS欺骗技术:

  -I 1 IDS-evasive mode 1 (URL编码)

  -I 2 IDS-evasive mode 2 (/./目录插入)

  -I 3 IDS-evasive mode 3 (过早结束URL)

  -I 4 IDS-evasive mode 4 (长URL)

  -I 5 IDS-evasive mode 5 (伪造参数)

  -I 6 IDS-evasive mode 6 (TAB分割) (not NT/IIS)

  -I 7 IDS-evasive mode 7 (大小写敏感)

  -I 8 IDS-evasive mode 8 (Windows分割符)

  -I 9 IDS-evasive mode 9 (会话拼接) (slow)

  -I 0 IDS-evasive mode 0 (NULL方法)

  如果想了解上面这些方法的技术细节,可以参考A Look At Whisker"s Anti-IDS Tactics。需要特别说明的是,rfp把whisker采用的anti-IDS技术单独放到了libwhisker(使用perl编写的)库中,为其它的程序采用这些技术提供了很大的便利。另外,nessus和babelweb等扫描工具都有自己的应用层入侵检测躲避技术。

  现在,IDS开发人员对各种网络协议有了更深入的理解,并且入侵检测设备在对数据包的负载进行字符串匹配之前会进行必要的协议分析,因此现在的IDS已经能够很好地处理上述的欺骗技术了。但是多余的字符转换又提高了入侵检测系统的负载,有时是得不偿失。为了减小这个负面影响,开发人员可以使入侵检测系统只在特定的端口进行字符转换。

  2.多变shell代码(polymorphic shell code)

  多变shell代码(polymorphic shell code)技术由K2开发的,设计思想来源于病毒逃避(virus evasion)技术。使用这种技术重新构造的shell代码更为危险,入侵检测设备非常难以检测到。这种技术只用于缓冲区溢出攻击,对付基于特征码的检测系统非常有效,而对于智能化的或者基于协议分析的检测系统的效果要差很多。为了便于讨论,我们以SSH CRC32缓冲区为例。我们先看以下snort检测规则:

  alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"EXPLOIT ssh CRC32

  overflow /bin/sh"; flags:A+; content:"/bin/sh"; reference:bugtraq,2347;

  reference:cve,CVE-2001-0144; classtype:shellcode-detect; sid:1324; rev:1;)

  alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"EXPLOIT ssh CRC32

  overflow NOOP"; flags:A+; content:"|90 90 90 90 90 90 90 90 90 90 90 90 90 90 90)

  上面的第一条规则简单地检查从外部到$HOME_NET,目标端口是22的数据包,搜索里面是否包含字符串/bin/sh。第二条规则是检查是否包含x86空操作字符(0x90)。多变shell代码(polymorphic shell code)使用很多方法逃避字符串匹配系统的检测。首先(以x86架构为例),使用其它的字符代替0x90执行无操作(no-op)指令。对于X86架构,有55种替代方式,其它的要少一些。这些替代方式以一种伪随机的方式结合到一块,建立缓冲区溢出shell代码包含无操作(no-op)指令的部分。除此之外,shell代码本身也采用XOR机制编码。通过这种方式建立的缓冲区溢出shell代码被重组后不会包含以上的特征码,从而能够逃过字符串匹配检测。

  多变shell代码检测对基于特征码检测的IDS是一个很大的挑战。Next Generation Security Technologie公司的技术白皮书Polymorphic Shellcodes vs. Application IDSs中提出了一些检测多变shell代码的设想。通过搜索无操作(no-op)字符的一个特定长度的正则表达式,可以实现对多变shell代码的精确检测。最近,Dragos Ruiu发布了一个用于检测多变shell代码的snort预处理插件spp_fnord,这个插件采用了和上面相似的检测技术。这个预处理插件有端口和长度两个配置选项。例如,如果某个人在配置时设置了80、21、23和53等端口,它就只对这几个端口的数据流量进行多变shell代码的检测,而不会对其它端口(例如:22)进行检测。

  3.会话拼接(session splicing,叫会话分割更合适一些)

  上面讨论的这些方法都是属于攻击数据在一个数据包中的情况,没有涉及攻击数据和会话通过多个数据包投递的情况。RFP在Whisker中实现了一种IDS逃避技术叫作会话拼接(session splicing),就是把会话数据放到多个数据包中发出,例如:

  +-------------------------+

  | packet number | content |

  |---------------+---------|

  | 1 | G |

  |---------------+---------|

  | 2 | E |

  |---------------+---------|

  | 3 | T |

  |---------------+---------|

  | 4 | 20 |

  |---------------+---------|

  | 5 | / |

  |---------------+---------|

  | 6 | H |

  +---------------+---------+

  通过这种方式,每次只投递几个字节的数据,就可能避开字符串匹配入侵检测系统的监视。要监视这种攻击,需要入侵检测系统或者能够理解、监视网络会话(即使IDS有这种能力,攻击者也可以通过其它的凡是避开监视),或者采用其它的技术监视这种攻击。snort使用以下规则来监视会话拼接:

  alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-MISC whisker

  space splice attack"; content:"|20|"; flags:A+; dsize:1;

  reference:arachnIDS,296; classtype:attempted-recon; reference)

  这条规则使snort检测目标为$HTTP_SERVERS 80端口的ACK报文的负载长度是否等于1以及是否包含空格(16进制的20)。使用这条规则可以精确地检测出whisker,但是攻击者只要稍加修改就可以避开这个检测。为了能够检测可能出现的会话拼接攻击,可以对上面这条snort规则进行扩展,使其检查负载很短的HTTP请求。但是,这样做的副作用是提高了误报警数量,而且在某些情况下攻击者还是能够避开监视。为了真正有效地检测这种攻击,需要入侵检测系统能够完整地理解网络会话,不过这是非常困难的。应该注意的是目前大多数系统能够重组会话,在所有的会话数据到达之前,它们会等待一些时间。而等待时间的长短与程序有关。例如,Apache/RedHat的会话超时时间是6分钟,IIS/Win2K等待的时间非常长。因此,攻击者完全可以每15分钟发送一个字节的会话数据,而IIS还会认为是有效的会话。最新版本的snort能够监视长期的会话和网络层欺骗,例如:小TTL值。

用户评论
用户名
评论内容
发表时间
ZDNet网友
2011-03-18 14:57:01
ZDNet网友
2010-05-21 00:49:14
ZDNet网友
2010-05-21 00:48:00
ZDNet网友
微软应该对自己的用户负责,如果用户完全使用xp升级微软win7,为什么要付出这样麻烦的代价?都是微软出品软件,且都是利用该软件获取信息以及处理文字、多媒体功能,微软应该尽可能方便用户!虽然有时候这样的请求也许跟不上时代技术发展的脚步,但是微软不要以此为借口,认为一切都理所应当,就不可以方便用户。还是要尽力,所谓拿人手短吃人嘴软,商业不正是讲求有商道吗!至少做人需诚实守信,尽可能帮助用户顺利、安全转换操作系统、各种必须软件功能尽可能兼容以及信息尽可能的少丢失!虽然这很大程度仅仅取决于微软等计算机专家、工程师的自我自律约束,我们普通用户恐怕很难知道微软究竟仅了多大力量为用户考虑,但是我相信真相会有被发现的一天,无论多久远。 微软从某种意义上来说,就是一个类似“掌握魔方”操作特别出神入化的公司。几乎奠定了电脑主要的“规则”,但是,我却相信不久将来我们会发现,电脑依然是非常有限的一个小系统而已!随着我们新的关键材料认知突破,电脑系统会真正被另一个革命性新电脑系统所取代,不要以为我这样的说法是无稽之谈不可实现,我却认为很有可能,只看这样的情况发生究竟是快还是慢,是早还是迟!变成历史的小玩具之后的电脑系统,微软会留下良好的历史声名吗?我们拭目以待! 网友::我爱佛祖
2010-02-03 13:52:55
- 发表评论 -
匿名
注册用户

百度大联盟认证黄金会员Copyright© 1997- CNET Networks 版权所有。 ZDNet 是CNET Networks公司注册服务商标。
中华人民共和国电信与信息服务业务经营许可证编号:京ICP证010391号 京ICP备09041801号-159
京公网安备:1101082134