两种基于HTTP的通用IDS躲避技术

来源: BlogBus 原始链接: http://www.blogbus.com:80/blogbus/blog/diary.php?diaryid=532033 存档链接: https://web.archive.org/web/20041230100008id_/http://www.blogbus.com:80/blogbus/blog/diary.php?diaryid=532033

本站公告 BLOG停止更新常见IP碎片攻击详解从上传webshell到突破TCP-IP筛选到3389终端登陆子网掩码及其应用 Windows命令行技巧用PERL打造自己的缓冲区漏洞利用程序 Linux安全综述 DISCUZ2上传漏洞分析上传漏洞变换利用如何使tcp包和udp包穿透防火墙 TC函数命令详细表 dreamtheater Angel showlife tx7do jpxiong chensun netsky KKQQ Ziqi spy8888 Luzhu eVan SUNU Taynni wuhui CAT Neeao KusTa Hoky eviloctal lam Iceberg Jace Hardy Gusu・Lanye swap lilo xiaolu knIfe kaka Lo7e4L Super・Hei lichdr lamp FlyWeb evilhsu hackfree powers Sunlion EvilPhive xeric icyfoxlovelace GuoMing swords an85 ring zwx steve S4Ld0ne solaris myzky xpfox liso sevenline Golden・Section phoenix xrens BlackFox tuz hardy29a victorwoo xueyu・xiongying Blackfish skyshui zhouzhen cnbird <<<ASP创建SQL Server数据库的两种方法 | 首页 | 子网掩码及其应用>>> 两种基于HTTP的通用IDS躲避技术时间: 2004-12-08 概要:本文描述了两种可以基于HTTP协议的通用IDS躲避技术。这些技术包括旧式的HTTP躲避技术和新式的HTTP躲避技术。虽然躲避技术的类型不同，但它们都位于HTTP协议的请求URI部分，使用标准的HTTP/1.0和HTTP/1.1协议。请求URI地址中的躲避技术，通常与URL的编码有关系。对于Apache和IIS来说，存在多种合法的URL编码方式，文中会对每一种编码进行解释，并给出具体的例子。本文还会使用HTTP协议的属性来展示对抗IDS的HTTP IDS躲避技术。通过阅读本文，读者会了解HTTP IDS躲避技术的原理，并且能够使用这些通用的原则和例子，实现符合自己需要的HTTP IDS躲避。索引术语: 计算机安全、超文本传输协议、入侵检测、网络扫描 I．介绍自从Rain Forest Puppy（RFP）的网络扫描器whisker首次公布于众以来［1］，HTTP IDS躲避技术已经逐渐流行。原先许多的HTTP IDS技术，都是从whisker的第一个版本出现的，包括简单的使用多个“/”的混淆目录技术，也包括更复杂的－在URL里插入“HTTP/1.0”以躲避那些搜索URL地址的IDS算法。除了whisker中出现的躲避技术，还有其他类型的HTTP混淆方法。其中的一个混淆URL的方法就是使用绝对URI与相对URI［2］。虽然这些方法很有趣，但是都不如whisker扫描中使用的方法常见。下一个流行的躲避方法也是RFP发布的，利用了微软互联网信息服务器（IIS）的UTF-8 unicode解码漏洞［3］。虽然是IIS的一个严重漏洞，它同时也给出了一个IDS未曾实现的URL编码方法。目前为止，大部分IDS仍然只是关注以前whisker的ASCII编码与目录遍历躲避技术，对Unicode的UTF-8编码却没有相应的保护。Eric Hacker对这种类型的HTTP IDS躲避技术，写了一篇非常专业的文章［4］。本文也会对Hacker文中的一些观点分析并解释。我们将继续Hacker的观点并深入了解：这些编码到底意味着什么，怎样才能造出更奇怪的编码。本文介绍的其他种类的HTTP IDS躲避技术，使用了HTTP协议的属性。其中之一就是请求管道，以及使用内容编码头并将HTTP请求的参数放置到请求负载中的技术。 II．IDS HTTP协议分析为了能够识别URL攻击，IDS必须检查HTTP的URL字段，看是否有恶意内容。两种最流行的IDS检测方法－模式匹配和协议分析－都需要检测URL中是否含有恶意内容（通过某种形式的模式匹配或者HTTP协议分析）。两种方法的不同之处取决于你的目的，协议分析法只搜索HTTP流URL字段部分的恶意内容，而模式匹配法的搜索范围是整个数据包。这两种方法在处理恶意URL之前的行为是类似的。之后，协议分析法只需要对URL字段添加合适的解码算法即可（它已经有内建的HTTP协议解码引擎）。而模式匹配算法并不知道需要对包的哪一部分正常化，因此需要与某种形式的协议分析相结合，找到相应的URL字段，才能使用相应的解码算法。某种形式的HTTP协议分析被添加到模式匹配法中，之后两者又行为类似了。由于这些IDS方法的类似性，本文讨论的HTTP IDS躲避方法适用于各种类型的IDS。第一种通用的IDS躲避方法是无效协议解析。举个例子，如果HTTP URL没有被正确发现，那么恶意URL就不能被检查出来，原因是：IDS没有发现URL，就不能对URL进行解码。如果URL是正确的，IDS必须知道正确的解码算法，否则，仍然不能得到正确的URL。这就是第二种IDS躲避技术－无效协议字段解码。 A. 无效协议解析使用无效协议解析IDS躲避技术，在RFP的whisker［1］和Bob Graham的SideStep［5］中给出了很多例子。这两个程序的区别在于：whisker使用了有缺陷的IDS协议解析来躲避检查，而SideStep使用正常的网络层协议来躲避IDS的协议解码器。这种情况下，无效协议解析的躲避技术，对于HTTP协议的两个字段URL和URL参数是非常有效的。例如：如果IDS的HTTP解码器假设每个请求包只有一个URL，那么一个包里包含两个URL，IDS就不能对第二个URL正确解析。这种技术在请求管道躲避技术中还会提到。 B．无效协议段解码无效协议段解码可以测试IDS是否能够处理特定协议段的各种类型的解码。如果是HTTP，主要的目标就是URL字段。对于IDS，需要测试它与HTTP RFC编码标准的符合程度，还要看是否能支持特定Web服务器的编码类型（例如IIS）。如果IDS不能对某种URL编码进行正确解码，攻击者就能利用该编码跳过对恶意URL的检测。另一个HTTP无效协议段编码，是通过目录混淆，操纵目录属性来实现的。例如：对于/cgi-bin/phf，可以使用多个“/”而不是一个“/”来改变目录的“外貌”，或者使用目录遍历来混淆目录路径。需要注意的是，只有当IDS共同查找目录和文件时，目录混淆才能隐藏恶意URL。对于“/cgi-bin/phf”来说，如果IDS在“cgi-bin”目录中寻找“phf”文件时，我们的攻击例子才能奏效；如果IDS只寻找“phf”文件，目录混淆方法就不管用了。 III．无效协议段解码 URL混淆的前题是HTTP服务器所接受的各种类型的编码方法。实际上，大部分的编码方法都与IIS有关，为了文章的完整性，每种编码类型都对每种HTTP服务器进行测试。利用URL编码来混淆Web攻击的思想依据，是大部分的IDS缺乏对不同类型Web服务器编码的足够分析。IDS的模式匹配与协议检测技术都存在问题。对于URI请求的编码，只有两个RFC标准：十六进制编码和UTF－8 Unicode编码。这两种方法都使用“％”来表示编码。Apache也只支持这两种URL编码类型。我们研究的大部分其他编码类型，都是服务器相关的，不符合RFC标准。微软的IIS Web服务器就属于这一类。在这一段也包括了URL混淆。 A．十六进制编码十六进制编码方法是对URL进行编码的符合RFC要求的一种方式，也是最简单的URL编码方法。该方法只须在每个编码字符的十六进制字节值前，加一个“％”。如果我们想对大写的A进行十六进制编码（ASCII的十六进制值是0x41），编码的结果是： • %41 = ‘A’ B．双百分号十六进制编码双百分号十六进制编码是基于正常的十六进制编码。具体的方法是将百分号编码并后接信息编码的十六进制值。对大写的A进行编码，结果是： • %2541 = ‘A’ 你可以看到，百分号的编码是％25（等价于“％”），该值解码后变成了％41（等价于“A”）。这种编码方法受到微软IIS的支持。 C．双四位十六进制编码双四位十六进制编码也是基于标准的十六进制编码，每个四位十六进制使用标准的十六进制编码方法。例如，对大写的A编码，结果是： • %%34%31 = ‘A’ 正常的A，十六进制编码是％41。双四位十六进制编码的方法是对每个四位进行编码，因此，4被编码为％34（这是数字4的ASCII值），第二个四位，1，被编码为％31（这是数字1的ASCII值）。在第一次URL解码后，四位值变成了数字4和数字1。因为4和1前边有一个％，第二遍会将％41解码为大写的A。 D．首四位十六进制编码首四位十六进制编码类似于双四位十六进制编码，不同之处在是只有第一个四位被编码。因此对于大写的A，双四位十六进制编码后为%%34%31，而按照首四位十六进制编码结果为： • %%341 = ‘A’ 像以前一样，第一次URL解码以后，％34被解码为数字4，因此第二次解码时的对象就成了％41，最后的结果依然是大写的A。 E．后四位十六进制编码后四位十六进制编码与首四位十六进制编码完全相同，只不过只执行标准解码的后四位。因此大写A的编码结果是： • %4%31 = ‘A’ 第一次解码时，％31解码为数字1，第二次解码的对象就是％41，最终的结果是“A”。 F．UTF-8编码 1） UTF-8 介绍 UTF-8编码允许大于单字节（0－255）的值以字节流的形式表示。HTTP服务器使用UTF-8编码来表示大于ASCII代码范围之外（1－127）的Unicode码。 UTF-8工作的时候，字节的高位有特殊的含义。两字节的UTF-8和三字节的UTF-8序列表示如下： 110xxxxx 10xxxxxx (二字节序列) 1110xxxx 10xxxxxx 10xxxxxx (三字节序列) UTF-8序列的第一字节是最重要的，通过它你可以知道这个UTF-8序列有多少字节，这是通过检查第一个0之前的1的个数来获得的。例子中，两字节的UTF-8序列，0之前的高位有两个1。第一个UTF-8字节0后边的位可以用来计算最终的值。后边的UTF-8字节格式相同，最高位是1，次高位是0，两位用于鉴别UTF-8，剩下的6位用来计算最终的值。为了对URL进行UTF-8编码，每个UTF-8字节都是用一个百分号进行转换。一个例子是：%C0%AF = ‘/’. 2）Unicode码点简介可以使用UTF-8编码来对Unicode码点值进行编码。码点值的范围通常是0－65535，HTTP URL中的任何大于127的码点值都使用UTF-8编码。值为0－127的Unicode码点，将会映射成单独的ASCII值。这样，就剩下65408个值，可以表示其他语言中的字符（例如匈牙利语或者日语）。通常，这些语言有自己的Unicode代码页，从Unicode代码页中可以得到Unicode的码点值。每种Unicode代码页有自己独特的值，因此如果Unicode代码页变了，Unicode码点值所代表的字符也就不同了。这一概念对于下一节的URL编码是很重要的。 3）把躲避手段综合起来 IDS很难处理UTF-8编码的Unicode码点值，主要有三个原因：第一个原因是，UTF-8编码可以将一个码点值或者ASCII值用不止一种方式表示，这在最近的Unicode标准中已经修正，但是在Web服务器中仍然很常见（包括Apache）。例如，大写字母A可以用两字节的UTF-8序列编码： • %C1%81 (11000001 10000001 = 1000001 = ‘A’) 同样，大写字母A也可以用三字节的UTF-8序列编码： • %E0%81%81 ( 11100000 10000001 10000001 = 1000001 = ‘A’) 因此，使用UTF-8来对ASCII字符进行编码，会得到很多结果。第二个原因，某些非ASCII的Unicode码点也可以映射为ASCII字符。例如，Unicode码点12001可以映射为大写字母A。如果想要知道哪一个码点可以映射到ASCII字符，要么阅读整个Unicode码的映射，要么对服务器测试所有不同的Unicode码点。目前，唯一这么做的Web服务器就是微软的IIS服务器。第三个原因与第二个原因有关。如果Unicode码的映射改变或者未知，翻译后的Unicode码点就有可能是无效的。这一点很重要，这是因为中国、日本、波兰等国的IIS Web服务器使用不同的代码页，因此如果IDS不了解Web服务器使用的代码页，对URL进行UTF-8解码的结果就有可能是错误的。因此如果一个IDS不能对所监视服务器使用的Unicode代码页进行配置，对于IDS没有监测的代码页，任何Web服务器都是不受保护的。 G． UTF-8 空字节编码 UTF-8空字节编码与UTF-8编码类似，区别在于并不适用百分号进行转意，发送的字节就是实际的字节，如果A被编码，结果是： • 0xC1 0x81 = ‘A’ 这种类型的编码只被微软的IIS服务器所支持。 H．微软％U编码微软的％U编码使用一种独特的方式来对Unicode码点值小与65535（或者两个字节）的对象编码。格式很简单，％U后边是Unicode码点值的4个四位值的十六进制： • %UXXXX 例如，大写A可以编码成： • %U0041 = ‘A’ 这种编码被微软的IIS所支持。 I．不匹配编码不匹配编码使用不同的编码方法来表示一个ASCII字符，不过这并不是一种单独的编码。例如，我们使用微软的％U编码方法来对大写A进行编码。因为IIS要对URL进行双解码，我们可以使用其他的方法来对％U方法进行编码。比如，我们可以对％U方法中的“U”进行十六进制编码。这样，一个简单的％U0041就变成了％％550041。我们也可以对0041进行十六进制编码，或者使用别的编码方法。下边是一个针对IIS服务器的更加复杂的不匹配编码，使着分析这串字符到底代表什么ASCII字符： • %U0025%550%303%37 IV．无效协议解析 A．使用请求管道来实现URL躲避请求管道的躲避方法，是一种无效协议解析的躲避方法。它使用了HTTP协议版本1.1的请求管道来使URI更加模糊。请求管道标准允许Web客户端在一个数据包中发送多个请求，这个与HTTP的保持连接头有所不同，不要混淆。请求管道把所有的请求放在一个包中，而HTTP保持连接是为了保持TCP流一直开放，接受更多的请求。我们使用请求管道特性在一个包中嵌入多个URL。大部分的IDS都能正确解析第一个URL，但基本上都不能正确解析其余的URL。这为躲避技术打开了大门，其他的URL虽然能被服务器解码，但是却被大多数的IDS忽略。比如，下列的数据负载使用了请求管道的技术来躲避对URL的检测： • GET / HTTP/1.1\r\nHost: \r\n\r\nGET /foobar.html \r\nHost: \r\n\r\nGET /cgi%2Dbin%2Fph%66 HTTP/1.1\r\nHost: r\n B．使用POST和Content-Encoding参数进行躲避另一个在攻击中包含恶意数据的HTTP协议字段，就是URL的参数字段。大部分数据库和cgi类型的攻击，都使用了该字段，而大部分的IDS都有相应的规则来检测恶意的参数键和参数值。一种躲避IDS的简单方法，就是使用与编码URL相同的技术来对参数进行编码，但大部分的IDS对参数字段也进行了解码。我们的方法是：使用POST请求将参数字段放到HTTP请求头的末尾。如果参数字段是名文形式，IDS就能很容易的发现恶意内容，因此我们使用了头选项，Content-Encoding，对参数字段进行BASE64编码。除非IDS对POST的内容也进行BASE64解码，攻击就有可能不断进行；即使IDS对POST实现了BASE64编码，这也是一个非常耗时的过程，因此如果发送大量包含巨型参数字段的POST请求，甚至会对IDS造成DOS攻击。 V．结论 HTTP IDS躲避技术有两大类，分别是无效协议解析和无效协议字段编码。如果IDS对HTTP协议字段的编码类型不了解，就不能正确的解码URL，攻击躲避的事件就会发生。这也是经常讨论的编码技术。如果IDS对HTTP缺乏足够的了解，仍有可能发生漏报。请求管道与内容编码躲避技术就是需要注意的。通过对IDS协议解码的研究发现，大部分的漏报都是使用了这两项技术孤光剑隐发表于 2004-12-08 09:21 引用Trackback(0) | 编辑评论发表评论