Attackers can bypass Apache http proxy to continue dos tomcat.

Author: the heart of emptiness, source: IT expert network

In the long run, a complete security solution should be separated from the features of the existing architecture. It cannot intercept attacks because of the existing application architecture, therefore, it means that the impact is not great. If the security solution always relies on the existing features of the application, it will be able to withstand the risks that may be bypassed. As a result, we will one day have to install patches honestly. This is a good example.

　　In the previous article tomcat Remote Denial of Service Vulnerability Analysis (cve-2010-2227)> http://www.bkjia.com/Article/201011/78685.htmlAccording to the TOMCAT patch, the author analyzed the POC that attacked the unpatched version. I believe many people have experienced it. However, in actual use, only small companies like to put tomcat on the outermost side. Large enterprises like to use apache and other web servers for forwarding outside tomcat to achieve better response speed, or to separate static files and reduce server pressure.

In this case, you will find that the POC provided by the author is invalid, this flaw is mitigated if Tomcat is behind a reverse proxy (such as Apache httpd 2.2) as the proxy shocould reject the invalid transfer encoding header. "He said that if you have a web server to forward your tomcat, this vulnerability will be mitigated.

You may be relieved to see this and there is no repair.

Officially speaking, what is the principle? Let's take a look at the attack POC:

POST/CodePK/updateinfo HTTP/1.1 Host: localhost Keep-Alive: 300 Connection: keep-alive   Transfer-encoding: buffered Content-Length: 145 U_uid = admin & Signature = 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

Apache will automatically intercept such an HTTP header because it has "transfer-encoding: buffered" and process the packet by itself. It will not be handed over to tomcat for processing and an error will be returned directly. This is caused by apache, but it is not important. It is important that the interception mechanism can be bypassed. TOMCAT is still waiting for data packets behind apache. If it can bypass, it will become loyal again. To bypass apache's "automatic interception" (this name is easy to remember), apache must not recognize this header.

Send a packet, which is the information returned after interception:

A: ools> 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 ........Omitted <P> The server encountered an internal error or Misconfiguration and was unable to complete Your request. </p> .......Omitted

  Apache returns the 500 Internal Server Error. If the header "transfer-encoding: buffered" is removed, the system returns the 200 OK message, but the system does not die.

It seems that this is an endless loop, and it will never happen, so tomcat officially said it can reduce the harm.

However, if apache and tomcat do not have the same understanding of some characters, apache may miss some characters, but tomcat is just a coincidence, and if this character can affect this, bypass is the so-called "defense architecture", so we can find out if there are such "trivial" characters.

Apache and Tomcat have different implementation principles (nonsense). Therefore, it is normal to understand different characters.

Let's take a look at how we understand the http heads segmentation. I found "CRLF", which is defined as "" in apache source code. convert to the hexadecimal "0D 0A" (why do we mention hexadecimal). This is for your reference:Https://svn.apache.org/repos/asf/httpd/flood/trunk/flood_test.c

In fact, I am not familiar with C, nor do I know what this section is mainly about, but I see that it does define

　　"# Define CRLF """Only this definition of crlf.

How can this be used? This actually indicates that the CRLF that apache understands is "", but it does not know "" (take a closer look, and vice versa ).

The tragedy is that tomcat and JBOSS know them and like them!

Tomcat and jboss define this thing as follows:

　"If (xx ='' | xx = '')"

That is to say, not only do we understand the characters in turn, but we also know TOMCAT and JBOSS even if we split them into bones.

Now that we know this key point, we have the following ideas. We disguise the "transfer-encoding: buffered" field as a part of other fields, and let apache put it in the past and hand it over to tomcat for processing.

POC:

In this case, I used the 16-in-progress editor to open the data package file aa.txt that I copied.

Find

Transfer-encoding: buffered

Put the character before this line