原文作者:Eric Hacker LUCENT的网络安全顾问 Original author: Eric Hacker LUCENT network security consultant
发表日期:01/03/2001 Date: 01/03/2001
发表地点:SECURITYFOCUS.COM Post location: SECURITYFOCUS.COM
译者:ISHTAR(土鳖) Translator: ISHTAR (Eupolyphaga)
技术核心: Core technology:
UTF-8因为编码方式的缺陷导致同一代码的多重含义,从而可能导致IDS和OS对于代码的误认,产生相应漏洞,为入侵者打开大门. UTF-8 encoding of the defects because the same code multiple meanings, which may lead to IDS and OS code for the mistake, to produce vulnerabilities, open the door for the intruder.
最近关于使用UNICODE中的问题攻陷IDS的争论开始见诸于世,有Stuart McClure和Joel Recently the issue on the use of UNICODE in the fall seen in the beginning of IDS controversy known to the world, there is Stuart McClure and Joel
Scambray这样的好同志甚至宣称UNICODE的缺陷可以导致IDS的全面失效。 Scambray such good comrades and even claimed that UNICODE defects can lead to complete breakdown of IDS. 本文试图阐述何为UNICODE，利用UNICODE攻陷IDS的机理何在以及相应的补救措施。 This article attempts to explain what is UNICODE, UNICODE captured using the mechanism of what IDS and the corresponding remedies. 文章的核心主要围绕UTF－8展开。 The core of the article the main focus UTF-8 start. UNICODE缺陷对IDS的威胁是切实而复杂的，这也是我需要向读者阐述明白的问题。 UNICODE defects of IDS threat is real and complex, that is what I need to explain to the reader to understand the problem.
入侵IDS IDS Intrusion
衡量小偷是否得手的重要条件之一就是看他是否使报警系统成为摆设，入侵IDS也是如此。 Measure whether the thief succeeded one of the important is to see whether he makes a decorative alarm system, intrusion IDS as well. 一旦入侵者得知IDS对哪些行为会作出反应，就会采取相应的措施。 Once the intruder to know what behavior of the IDS to respond, it will take the appropriate measures. 攻击可以依据OSI模型的各个层次展开，即使NIDS（基于网络的IDS：NETWORK－BASED IDS）在防御低层的攻击方面有所建树，碎片攻击一样可以令其束手无策。 Attack can be based on all levels of the OSI model to start, even if the NIDS (network-based IDS: NETWORK-BASED IDS) low-level attacks in the defense claim the credit, the same fragment attack can make it do nothing. 就NIDS而言，基于应用层的攻击是一个很复杂的问题。 The NIDS is concerned, based on application layer attacks is a very complex issue. 由于NIDS必须完全模仿应用层协议的解释，攻击者就可以利用应用层和IDS之间的差异作为攻击的起点。 As the NIDS must be fully mimic the interpretation of the application layer protocol, an attacker can use the application layer and the difference between the IDS as the starting point of attack. 而使用签名的IDS就会发现自己完全无力应付复杂的交互请求。 The use of IDS signatures will find themselves completely unable to cope with the complex interaction request. 由于利用类似UNICODE支持的协议越来越复杂，IDS在应用层受到攻击的可能性正在日益增加。 As the use of similar UNICODE support more complex protocols, IDS at the application layer attacks are increasing the likelihood.
什么是UNICODE？ What is UNICODE?
UNICODE使任何语言的字符都可以为机器更容易的接受,UNICODE由UC(UNICODE协会)管理并接受其技术上的修改。 UNICODE characters in any language so that the machine can be more easily accepted, UNICODE by the UC (UNICODE Association) to manage and accept the technical changes. 包括JAVA、LDAP、XML这样的技术标准中均要求得到UNICODE的支持。 Including JAVA, LDAP, XML technology standards such as are required to be UNICODE support. UNICODE的字符被成为代码点（CODE POINTS），用U后面加上XXXX来表示，其中，X为16进制的字符。 UNICODE characters are a code point (CODE POINTS), followed by U XXXX to indicate where, X is 16 hexadecimal characters.
什么是UTF－8 What is UTF-8
在 UC发布的UNICODE3.0.1勘误表的D36节中，UTF8是指UNICODE的转换格式，在这种格式中，UNICODE的代码点是由4个字节组成的，UTF－8提供了一种技术可能，即即可以成为一种UNICODE的编码方式，又可以与INTERNET上表示文本时最常用的ASCII兼容。 Published in the UC UNICODE3.0.1 errata section of the D36, UTF8 is a UNICODE conversion format, in this format, UNICODE code point is formed by four bytes, UTF-8 provides a technology may , that is, that can be a UNICODE encoding, but also on the INTERNET that text with the most commonly used ASCII-compatible.
在实现兼容的过程中，UTF将标准的7位ASCII码（U＋0000到U＋007F）诠释为一个字符,从U+0080到U+07FF作为2个字符,U+0800到U+FFFF作为三个字符,再往上则作为4个字符,这种算法的设计理念在于不必进行表索引就可以直接换算代码. In the process of achieving compatibility, UTF standard 7-bit ASCII (U +0000 to U +007 F) interpreted as a character from U +0080 to U +07 FF as the two characters, U +0800 to U + FFFF as three characters, Beyond that is a four character, concept design of this algorithm is not the table index can be directly converted code.
MS的IE和OFFICE2K都支持基于UTF－8的URL，IIS在默认配置下将UTF－8阐述为3字节的进程，而APACHE则可以在配置后支持UTF－8。 MS IE and OFFICE2K support based on UTF-8's URL, IIS in the default configuration will be UTF-8 describes the process for the 3-byte, and APACHE can be configured to support the UTF-8.
UTF－8和UNICODE的安全问题 UNICODE UTF-8 and the safety of
BRUCE BRUCE
SCHNEIER是首先在2000年7月15日开始讨论这一安全问题的同志,他最先之处工具UNCODE的编码方式,可能会出现同一字符代表多重意义的情况,也可能会有新的代码点修改前代码点的情况. SCHNEIER is the first in the July 15, 2000 to discuss the security issues began comrades, he was the first of at encoding tools UNCODE may appear on behalf of the same character multiple meanings of the situation, there may be a new code-point change before the code point of the situation.
在安全文件里,字符的意义必须得到确认,但是由于UNICODE的复杂性,多重表示的可能性增加,安全缺陷也随之产生. UC已经认识到UNICODE的多重表示问题并已经修改了UNICODE标准以消除这种情况,在UTF-8新的勘误表里面有相关的说明,由于这些修改只是最近的事情,相关的应用层面的东西还来不及作出反应,IIS就是一个典型. In the security document, the meaning of the character must be confirmed, but due to the complexity of UNICODE, increase the likelihood of multiple representation, security flaws also will produce. UC has recognized that the problem of multiple UNICODE and UNICODE standards have been revised to eliminate This, in UTF-8 there are new errata relevant to that, because of these changes is only recently that the relevant application-level things had a chance to respond, IIS is a classic.
老的UTF-8转换格式最大的问题在于当转换任务增加一个字节时,整个代码点就会重新核算一次,也就是说,当UTF-8下开始一个2字节的转换是,它就会在单字节转换的基础上重新转换一次,当转换字节为三字节时,就会从单字节和2字节的基础上重新开始转换. The old format of UTF-8 conversion biggest problem is that when the conversion task add a byte, the entire code will be re-accounting point of time, that is, when started under UTF-8 conversion is a 2-byte, it will In the single-byte conversion, based on the re-conversion time when converting bytes to three bytes, they will single-byte and 2 bytes from the start based on the conversion.
一个典型就是"\",U+005C,在老版本的UTF-8里面,\可以被阐述为5C,C19C和E0819C.所有这些代码都代表者同一个UNICODE代码点:当请求按照算法进行处理后,得到相同的值,稍老一些的支持UTF-8的请求都会接受这三个值并将其认定为\. A typical is the "\", U +005 C, in the old version of UTF-8 inside, \ can be described as 5C, C19C and E0819C. All of these codes represent those with a UNICODE code point: When a request is processed according to algorithms , get the same value, slightly older support UTF-8 will accept the request and the three values identified as \.
应用带来大问题 Application to bring a big problem
UNICODE会带来另外一个大问题,就是应用请求和OS可能把不同的代码点理解成为一个意思. UNICODE will bring another big problem is the application request and OS code may point to a different understanding of a meaning.
在对WINDOWS2K的ADVANCE SVR（E文版）上的IIS进行测试后，我发现IIS真是一个阐述这个问题的好例子。 In WINDOWS2K the ADVANCE SVR (E version) on the IIS for testing, I found that IIS is really a good example of this problem set. 举个例子来看，字母A可以在UNICODE里面被阐述为以下代码点：U+0100,U+0102,U+0104,U+01DE,U+8721,需要注意的是,这些代码本身还有多重含义.由于IIS自身的问题,这可能会导致对字符A的将近30种表述方法,而E则有34种表述方法,I有36种,)有39种,U 有58种,一个字符串"AEIOU"就可能会有83,060,640种表述方法! For example look at the letter A can be described in the UNICODE inside the following code points: U +0100, U +0102, U +0104, U +01 DE, U +8721, needs to note that the code itself, there are multiple meaning due to IIS's own problems, which may lead to the characters A, nearly 30 kinds of formulation, and E, there are 34 kinds of formulation, I have 36 species) 39 species, U, 58 species, a string " AEIOU "kinds of statements may be 83,060,640 ways!
可能导致的问题 May cause problems
阐述这个问题的一个好例子就是MS的IIS4.0/5.0的EXTEND UNICODE DIRECTORY TRAVERSAL缺陷,RAIN FOREST PUPPY是首先开始公开讨论这一BUG的同志,他一言以蔽之的讲:IIS在对UTF-8解码之前检测目录的TRAVERSAL,然后就遗漏掉使用 UTF-8的目录TRAVERSAL,而OS则开始解码. Set a good example of this problem is the MS IIS4.0/5.0 the EXTEND UNICODE DIRECTORY TRAVERSAL defects, RAIN FOREST PUPPY is the first public discussion of the BUG beginning comrades, he was speaking a word: IIS in the UTF- test directory before 8 decoding TRAVERSAL, and then missed out on the use of UTF-8 directory TRAVERSAL, while the OS is starting to decode.
对这个漏洞进行的攻击会很容易,如果入侵者输入类似" http://victim/../../winnt/system32/cmd.exe"这样的URL,IIS就会在"../.."上产生一个错误,如果入侵者使用UTF-8将"../.."编码为"..%C1%9C.."并发送到IIS,目录TRAVERSAL就不会被处理,如果默认许可没有被修改, 入侵者就可以开始运行其他文件. Of this vulnerability will be very easy, if the intruder enter a similar "http://victim/../../winnt/system32/cmd.exe" this URL, IIS will be in "../.. "results in an error, if an intruder to use UTF-8 will "../.." encoded" ..% C1% 9C .. "and sent to the IIS, the directory TRAVERSAL will not be processed, if there is no default permission is modified, the intruder can start to run other files.
相应问题对IDS的影响 The impact of the corresponding problem of IDS
一般说来，当漏洞被公开时，IDS厂商们就会匆匆推出一些措施（当然，也有一些会去做些基础工作），只有以家叫NETWORKICE的才真正正确的处理了这个问题（NND ，做广告啊！？？） In general, when the vulnerability is exposed when, IDS vendors will rush some of the measures (of course, some will go to do the basic work), a family called NETWORKICE only really proper handling of this issue (NND, do Advertising ah!??)
现在，我们来看以看SNORT的最新规则： Now, we look to see the latest SNORT rules:
alert tcp !$HOME_NET any -> $HOME_NET 80 (msg: "IDS434 - alert tcp! $ HOME_NET any -> $ HOME_NET 80 (msg: "IDS434 -
WEB IIS - Unicode WEB IIS - Unicode
traversal backslash"; flags: AP; content: traversal backslash "; flags: AP; content:
"..|25|c1|25|9c"; nocase;) ".. | 25 | c1 | 25 | 9c"; nocase;)
alert tcp !$HOME_NET any -> $HOME_NET 80 (msg: "IDS433 - alert tcp! $ HOME_NET any -> $ HOME_NET 80 (msg: "IDS433 -
WEB-IIS - Unicode WEB-IIS - Unicode
traversal optyx"; flags: AP; content: "..|25|c0|25|af"; traversal optyx "; flags: AP; content:" .. | 25 | c0 | 25 | af ";
nocase;) nocase;)
alert tcp !$HOME_NET any -> $HOME_NET 80 (msg: "IDS432 - alert tcp! $ HOME_NET any -> $ HOME_NET 80 (msg: "IDS432 -
WEB IIS - Unicode WEB IIS - Unicode
traversal"; flags: AP; content: "..|25|c1|25|1c"; traversal "; flags: AP; content:" .. | 25 | c1 | 25 | 1c ";
nocase;) nocase;)
ISS RealSecure稍微强点,它使用匹配字符串的方法发现攻击行为( ISS RealSecure slightly strengths, it uses a string matching method to find aggressive behavior (
http://xforce.iss.net/alerts/advise68.php). http://xforce.iss.net/alerts/advise68.php).
但是无论SNORT还是RealSecure签名都只抓住了问题被公开的一面.事实证明其他的问题还有很多.比如入侵者可以用%C0%AE来取代下划线,在这种情况下,IIS一样的脆弱,但是IDS却会袖手旁观. But regardless of SNORT or RealSecure signature to seize the issue was open only one side. The fact that there are many other issues, such as an intruder can use% C0% AE to replace the underscore, in this case, IIS the same vulnerable, but they will stand by IDS.
还有一件罕为人知的事实,如果入侵者直接向IIS发送未被释放(UN-ESCAPED)的UTF-8字符,IIS会来者不拒.网页浏览器不能直接发送这些字符,但是在某些程序里可以打开一个端口来发送它们.比如,如果有人在URL里向IIS发送了诸如0*C0AE这样的字符,IIS会将其视为UTF-8对待,而大多数IDS则会熟视无睹,至于系统,那自然是叮叮当当了. There is a little-known fact that if an intruder is not sent directly to the IIS release (UN-ESCAPED) the UTF-8 characters, IIS will arrive here. Web browser can not directly send these characters, but in some program can open a port to send them. For example, if someone sent in the URL to the IIS, such as 0 * C0AE such characters, IIS will treat it as UTF-8, and most IDS will turn a blind eye, as the system , it is naturally rattled the.
虽然目前还很少有工具是基于UTF-8的,但是象WHISKER和FRAGROUTER这样的工具具备UTF-8攻击方式只是一个迟早问题,因为几乎所有的监护这IIS的IDS可以为几乎所有的URL签名方式攻陷. Although very few tools are based on UTF-8, but as a tool WHISKER and FRAGROUTER such attacks with UTF-8 is only a matter of time, because almost all of the care that the IIS IDS for almost all of the way the URL signature fall.
对于NDIS而言,也许唯一可行的办法就是在UTF-8进程上打主意,就象对付IIS一样.这对于NIDS的厂商来说不是什么新鲜主意,有些厂商已经有了支持重建TELNET进程的产品,也有的厂商已经有了支持处理HTTP进程以控制单字节编码.说好听些,叫协议分析,或者叫数据的模式匹配,不过不管怎么称呼,这些产品的问题还是很严重的. For NDIS is concerned, perhaps the only viable solution is in UTF-8 on the targeting process, as against IIS as this is for the NIDS vendors not new idea, some vendors already have products that support the reconstruction of the TELNET process, Some manufacturers also have support for handling HTTP process to control the single-byte encoding. say it nicely, called protocol analysis, pattern matching or data call, but no matter how you call, the issue of these products is still very serious.
有聪明的唯一准备在UTF-8自身上做文章的就是NETWORKICE,从FOCUS-IDS的邮件列表上看,从SCHNEIER开始揭示这个问题以来,它们就开始从事这方面的工作了,它们的劳动成果就是一个极其复杂的解决方案,我有幸参加了它们的测试,发现确实实现了很多所需要的功能. There are clever only to prepare on their own in the UTF-8 issue is NETWORKICE, from the FOCUS-IDS mailing list point of view, starting from SCHNEIER reveal this problem since they started working in this field, and their fruits of labor is an extremely complex solution, I was fortunate to participate in their tests and found that to achieve a lot of the functionality required.
NETWORKICE可以成功的检测使用UTF-8标准编码的入侵,如果入侵者使用单一代码点上的1个甚至多个UTF-8诠释,BLACKICE会成功的识别入侵,无论这种入侵是基于UTF-8还是其他的WEB入侵方式. NETWORKICE can successfully detect encoded using UTF-8 standard invasion, if an intruder to use a single code point of an even number of UTF-8 interpretation, BLACKICE will recognize the success of the invasion, whether the invasion was based on UTF-8 or WEB invasion of other ways.
UTF-8是一种UNICODE的算法注释,这可以解释NETWORKICE制作UTF-8引擎的方式,而IIS的工作方式则与之不同,所以使用非标准字符的UTF-8攻击可以攻陷BLACKICE. UNICODE UTF-8 is an algorithm that comment, which may explain NETWORKICE UTF-8 engine made way, and IIS work the contrast, so the use of non-standard characters in UTF-8 attack can capture BLACKICE.
越来越糟? Worse?
在 SOLARIS的APACHE环境下,UTF-8很有可能会被阐述成另外一副样子,真是TNND的世事无常理.NIDS可能被迫不仅要为每个应用都分给一个UTF-8的表,还得监视这些申请来自哪些IP以确认诠释是正确的,好些厂商在往这方面努力,结果恐怕只可能是越弄越烦琐. In the APACHE SOLARIS environment, UTF-8 is likely to be elaborated into the other one looks like, really TNND no common sense of things. NIDS may be forced not only to each application are distributed to a UTF-8 table, also These applications were monitored to confirm the interpretation from what IP is correct, this talent to better manufacturers, the result is probably more likely to get only more cumbersome.
咱们干吗去? Why do we go?
网络应用层的最大问题就是如果使IDS的分析和请求的分析可以同步,基于主机的IDS由于可以记录请求,所以在监控应用层的入侵方面一枝独秀,这些记录可以反映请求的过程和请求被执行的过程.因此,基于主机的IDS恐怕在应用层上更合适的IDS了. The biggest problem with the network application layer is that if the IDS analysis and the analysis of the request can be synchronous, host-based IDS can be recorded as a request, so the application layer intrusion monitoring aspects of thriving, these records may reflect the process and the request is a request executed process, therefore, host-based IDS probably more appropriate at the application layer on the IDS has.
其实在阻止基于UTF-8的入侵方面,还有一些我们可以采取的措施,NDIS可以分析协议,从而将URI从80端口中分拆出来,如果一个站点不使用UTF- 8,则任何使用UTF-8的企图会被发现并导致报警.当然,使用外语的机器会不得不使用UTF-8,从而使这种努力见效甚微,但是至少其他人可以受益非浅. In fact, based on UTF-8 to prevent the invasion area, there are some measures we can take, NDIS protocol can be analyzed to the URI in the spin-off from the port 80, if a site does not use UTF-8, then any use of UTF- 8 attempts will be found and lead the police. Of course, foreign language, the machine will have to use UTF-8, so that little of this effort bear fruit, but at least other people can benefit greatly.
如果IIS允许关闭多字节的UTF-8进程的话,结果也会好很多.UNICODE是一种可能会复兴的安全措施,虽然对于很多站点完全没有必要.当然,现行的 IIS/WINDWS体系要被废除,因为它还没有随这修订后的标准更新,但是MS会尽快修改这个BUG吗?实现应用层对UNICODE的支持是一件值得称道的工作,但是,除非整个复杂的安全结构标准被广为接受,应用层恐怕还是接受关闭UTF-8的选择为好. If IIS is allowed to close the multi-byte UTF-8 process, the result will be much better. UNICODE is a revival of the security measures might be, although there is no need for the many sites of course, the current IIS / WINDWS system to be abolished , because it is not standard with this revised update, but MS will change this as soon as possible BUG it? to achieve application-level support for UNICODE is a commendable work, but, unless the entire structure of the complex security standards are widely accepted , I'm afraid to accept the application layer off UTF-8 option as well.
结论 Conclusion
INTERNET上对于UNICODE的支持会带来重大安全隐患,现存的几乎所有IDS都可能会对基于UTF-8的攻击无能为力.NIDS对于应用层的保护除非奇迹出现,否则困难重重,这和光大厂商的宣传正好南辕北辙. UNICODE support for the INTERNET will bring significant security risk, almost all existing IDS are based on UTF-8 may attack powerless. NIDS for the application layer protection unless a miracle, or difficult, it's propaganda and Everbright manufacturers just poles apart.
Tidak ada komentar:
Posting Komentar