利用UNICODE缺陷攻陷IDS IDS, UNICODE, 缺陷, 攻陷

3ast

利用UNICODE缺陷攻陷IDS
原文作者:Eric Hacker LUCENT的网络安全顾问
发表日期:01/03/2001
发表地点:SECURITYFOCUS.COM
译者:ISHTAR(土鳖)

技术核心:
   UTF-8因为编码方式的缺陷导致同一代码的多重含义,从而可能导致IDS和OS对于代码的误认,产生相应漏洞,为入侵者打开大门.

   最近关于使用UNICODE中的问题攻陷IDS的争论开始见诸于世,有Stuart McClure和Joel
Scambray这样的好同志甚至宣称UNICODE的缺陷可以导致IDS的全面失效。本文试图阐述何为UNICODE，利用UNICODE攻陷IDS的机理何在以及相应的补救措施。文章的核心主要围绕UTF－8展开。UNICODE缺陷对IDS的威胁是切实而复杂的，这也是我需要向读者阐述明白的问题。

入侵IDS

   衡量小偷是否得手的重要条件之一就是看他是否使报警系统成为摆设，入侵IDS也是如此。一旦入侵者得知IDS对哪些行为会作出反应，就会采取相应的措施。攻击可以依据OSI模型的各个层次展开，即使NIDS（基于网络的IDS：NETWORK－BASED IDS）在防御低层的攻击方面有所建树，碎片攻击一样可以令其束手无策。就NIDS而言，基于应用层的攻击是一个很复杂的问题。由于NIDS必须完全模仿应用层协议的解释，攻击者就可以利用应用层和IDS之间的差异作为攻击的起点。而使用签名的IDS就会发现自己完全无力应付复杂的交互请求。由于利用类似UNICODE支持的协议越来越复杂，IDS在应用层受到攻击的可能性正在日益增加。


什么是UNICODE？

   UNICODE使任何语言的字符都可以为机器更容易的接受,UNICODE由UC(UNICODE协会)管理并接受其技术上的修改。包括JAVA、LDAP、XML这样的技术标准中均要求得到UNICODE的支持。UNICODE的字符被成为代码点（CODE POINTS），用U后面加上XXXX来表示，其中，X为16进制的字符。

什么是UTF－8

   在UC发布的UNICODE3.0.1勘误表的D36节中，UTF8是指UNICODE的转换格式，在这种格式中，UNICODE的代码点是由4个字节组成的，UTF－8提供了一种技术可能，即即可以成为一种UNICODE的编码方式，又可以与INTERNET上表示文本时最常用的ASCII兼容。

   在实现兼容的过程中，UTF将标准的7位ASCII码（U＋0000到U＋007F）诠释为一个字符,从U+0080到U+07FF作为2个字符,U+0800到U+FFFF作为三个字符,再往上则作为4个字符,这种算法的设计理念在于不必进行表索引就可以直接换算代码.

   MS的IE和OFFICE2K都支持基于UTF－8的URL，IIS在默认配置下将UTF－8阐述为3字节的进程，而APACHE则可以在配置后支持UTF－8。

UTF－8和UNICODE的安全问题

BRUCE
   SCHNEIER是首先在2000年7月15日开始讨论这一安全问题的同志,他最先之处工具UNCODE的编码方式,可能会出现同一字符代表多重意义的情况,也可能会有新的代码点修改前代码点的情况.

   在安全文件里,字符的意义必须得到确认,但是由于UNICODE的复杂性,多重表示的可能性增加,安全缺陷也随之产生. UC已经认识到UNICODE的多重表示问题并已经修改了UNICODE标准以消除这种情况,在UTF-8新的勘误表里面有相关的说明,由于这些修改只是最近的事情,相关的应用层面的东西还来不及作出反应,IIS就是一个典型.

   老的UTF-8转换格式最大的问题在于当转换任务增加一个字节时,整个代码点就会重新核算一次,也就是说,当UTF-8下开始一个2字节的转换是,它就会在单字节转换的基础上重新转换一次,当转换字节为三字节时,就会从单字节和2字节的基础上重新开始转换.

   一个典型就是"\",U+005C,在老版本的UTF-8里面,\可以被阐述为5C,C19C和E0819C.所有这些代码都代表者同一个UNICODE代码点:当请求按照算法进行处理后,得到相同的值,稍老一些的支持UTF-8的请求都会接受这三个值并将其认定为\.

应用带来大问题

UNICODE会带来另外一个大问题,就是应用请求和OS可能把不同的代码点理解成为一个意思.

   在对WINDOWS2K的ADVANCE SVR（E文版）上的IIS进行测试后，我发现IIS真是一个阐述这个问题的好例子。举个例子来看，字母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种表述方法!

可能导致的问题
   阐述这个问题的一个好例子就是MS的IIS4.0/5.0的EXTEND UNICODE DIRECTORY TRAVERSAL缺陷,RAIN FOREST PUPPY是首先开始公开讨论这一BUG的同志,他一言以蔽之的讲:IIS在对UTF-8解码之前检测目录的TRAVERSAL,然后就遗漏掉使用UTF-8的目录TRAVERSAL,而OS则开始解码.

对这个漏洞进行的攻击会很容易,如果入侵者输入类似" http://victim/../../winnt/system32/cmd.exe"这样的URL,IIS就会在"../.."上产生一个错误,如果入侵者使用UTF-8将"../.."编码为"..%C1%9C.."并发送到IIS,目录TRAVERSAL就不会被处理,如果默认许可没有被修改,入侵者就可以开始运行其他文件.

相应问题对IDS的影响

   一般说来，当漏洞被公开时，IDS厂商们就会匆匆推出一些措施（当然，也有一些会去做些基础工作），只有以家叫NETWORKICE的才真正正确的处理了这个问题（NND ，做广告啊！？？）

   现在，我们来看以看SNORT的最新规则：
alert tcp !$HOME_NET any -> $HOME_NET 80 (msg: "IDS434 -
WEB IIS - Unicode
traversal backslash"; flags: AP; content:
"..|25|c1|25|9c"; nocase;)
alert tcp !$HOME_NET any -> $HOME_NET 80 (msg: "IDS433 -
WEB-IIS - Unicode
traversal optyx"; flags: AP; content: "..|25|c0|25|af";
nocase;)
alert tcp !$HOME_NET any -> $HOME_NET 80 (msg: "IDS432 -
WEB IIS - Unicode
traversal"; flags: AP; content: "..|25|c1|25|1c";
nocase;)

ISS RealSecure稍微强点,它使用匹配字符串的方法发现攻击行为(
http://xforce.iss.net/alerts/advise68.php).

   但是无论SNORT还是RealSecure签名都只抓住了问题被公开的一面.事实证明其他的问题还有很多.比如入侵者可以用%C0%AE来取代下划线,在这种情况下,IIS一样的脆弱,但是IDS却会袖手旁观.

   还有一件罕为人知的事实,如果入侵者直接向IIS发送未被释放(UN-ESCAPED)的UTF-8字符,IIS会来者不拒.网页浏览器不能直接发送这些字符,但是在某些程序里可以打开一个端口来发送它们.比如,如果有人在URL里向IIS发送了诸如0*C0AE这样的字符,IIS会将其视为UTF-8对待,而大多数IDS则会熟视无睹,至于系统,那自然是叮叮当当了.

   虽然目前还很少有工具是基于UTF-8的,但是象WHISKER和FRAGROUTER这样的工具具备UTF-8攻击方式只是一个迟早问题,因为几乎所有的监护这IIS的IDS可以为几乎所有的URL签名方式攻陷.

   对于NDIS而言,也许唯一可行的办法就是在UTF-8进程上打主意,就象对付IIS一样.这对于NIDS的厂商来说不是什么新鲜主意,有些厂商已经有了支持重建TELNET进程的产品,也有的厂商已经有了支持处理HTTP进程以控制单字节编码.说好听些,叫协议分析,或者叫数据的模式匹配,不过不管怎么称呼,这些产品的问题还是很严重的.

   有聪明的唯一准备在UTF-8自身上做文章的就是NETWORKICE,从FOCUS-IDS的邮件列表上看,从SCHNEIER开始揭示这个问题以来,它们就开始从事这方面的工作了,它们的劳动成果就是一个极其复杂的解决方案,我有幸参加了它们的测试,发现确实实现了很多所需要的功能.

   NETWORKICE可以成功的检测使用UTF-8标准编码的入侵,如果入侵者使用单一代码点上的1个甚至多个UTF-8诠释,BLACKICE会成功的识别入侵,无论这种入侵是基于UTF-8还是其他的WEB入侵方式.

   UTF-8是一种UNICODE的算法注释,这可以解释NETWORKICE制作UTF-8引擎的方式,而IIS的工作方式则与之不同,所以使用非标准字符的UTF-8攻击可以攻陷BLACKICE.

越来越糟?

   在SOLARIS的APACHE环境下,UTF-8很有可能会被阐述成另外一副样子,真是TNND的世事无常理.NIDS可能被迫不仅要为每个应用都分给一个UTF-8的表,还得监视这些申请来自哪些IP以确认诠释是正确的,好些厂商在往这方面努力,结果恐怕只可能是越弄越烦琐.

咱们干吗去?

   网络应用层的最大问题就是如果使IDS的分析和请求的分析可以同步,基于主机的IDS由于可以记录请求,所以在监控应用层的入侵方面一枝独秀,这些记录可以反映请求的过程和请求被执行的过程.因此,基于主机的IDS恐怕在应用层上更合适的IDS了.

   其实在阻止基于UTF-8的入侵方面,还有一些我们可以采取的措施,NDIS可以分析协议,从而将URI从80端口中分拆出来,如果一个站点不使用UTF-8,则任何使用UTF-8的企图会被发现并导致报警.当然,使用外语的机器会不得不使用UTF-8,从而使这种努力见效甚微,但是至少其他人可以受益非浅.

   如果IIS允许关闭多字节的UTF-8进程的话,结果也会好很多.UNICODE是一种可能会复兴的安全措施,虽然对于很多站点完全没有必要.当然,现行的IIS/WINDWS体系要被废除,因为它还没有随这修订后的标准更新,但是MS会尽快修改这个BUG吗?实现应用层对UNICODE的支持是一件值得称道的工作,但是,除非整个复杂的安全结构标准被广为接受,应用层恐怕还是接受关闭UTF-8的选择为好.

结论

  INTERNET上对于UNICODE的支持会带来重大安全隐患,现存的几乎所有IDS都可能会对基于UTF-8的攻击无能为力.NIDS对于应用层的保护除非奇迹出现,否则困难重重,这和光大厂商的宣传正好南辕北辙.