作者:Daniel J. Roelker
概要:本文描述了两种可以基于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协议解码的研究发现,大部分的漏报都是使用了这两项技术
概要:本文描述了两种可以基于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协议解码的研究发现,大部分的漏报都是使用了这两项技术