Shulou(Shulou.com)06/01 Report--

This article introduces how to analyze arbitrary code vulnerabilities in Tomcat execution. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

This time, we analyze one of the two CVE vulnerabilities, which is wider than the official announcement. In addition to the Windows platform, other platforms are also affected by another form of utilization, the specific risk of executing arbitrary code, so in this description, friends check their own applications, if there is an impact, please fix it as soon as possible.

Vulnerability description

On the evening of September 19th, Apache Tomcat officially announced that all Windows platforms with HTTP PUT method support are at risk of remote code execution. Vulnerability code: CVE-2017-12615

The official description is as follows:

Details:

As we explained a long time ago, Tomcat contains two default Servlet for handling specific requests, one is DefaultServlet and the other is JspServlet. Both Servlet are included in Tomcat's default web.xml and merge with custom web.xml, so each application will have these two Servlet.

Since each Servlet can set some initialization parameters (init-param), some commonly used parameters are included in the default web.xml, such as whether to allow file lists, whether to debug,fileEncoding, the size of the sendFile, and so on. This allows you to set whether the HTTP PUT method is allowed or not.

Parameter configuration item: readOnly, which is mainly used to reject the PUT / DELETE method of HTTP.

ReadOnly

False

ReadOnly defaults to true, which means that PUT and DELETE are not enabled by default. If some friends' containers open readOnly due to application dependence, be sure to pay attention!

Let's see, in the PUT processing logic of DefaultServlet, readOnly is judged first.

The mapping configuration for DefaultServlet is as follows:

At this point, if you request a URL like this:

Request method: PUT

Path: http://xxx/context/abc.jsp/

Data: using raw format

You can easily construct one using Postman (for more information on how to use it, please see PostMan for Web development artifact. Interface testing is no longer a problem).

When the content of PUT is actually processed, it will be extracted and written.

If (this.resources.write (path, (InputStream) resourceInputStream, true)) {

If (resource.exists ()) {

Resp.setStatus (204)

} else {

Resp.setStatus (201)

}

} else {

Resp.sendError (409)

}

Although the path here is abc.jsp/, it will be dealt with in the actual processing. Due to the limitation of the file name specification, the last one / will be processed, so a file called abc.jsp is created, and the content of the file is the content of the raw we sent. And the content here can be written at will.

When the PUT request returns, request the abc.jsp again, and whatever is written at random in the raw will be executed, which is the risk of arbitrary code execution as we mentioned earlier.

The vulnerability officially described by Apache Tomcat in the Windows platform is also a naming problem. If a PUT request such as abc.jsp%20 is used in the url when the request is made, when it arrives at the DefaultServlet, the creation file will still filter out the space of% 20. The risk is the same as above.

Solution:

To deal with this problem, you need to set readOnly to true, or keep the initial value without adding configuration in web.xml.

This is the end of the analysis on how to carry out the analysis of arbitrary code vulnerabilities in Tomcat execution. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.