Table of contents
1. Tomcat arbitrary file read and write vulnerability (CVE-2017-12615)
1. Vulnerability description
On September 19, 2017, Apache Tomcat officially confirmed and fixed two high-risk vulnerabilities, including a remote code execution vulnerability (CVE-2017-12615). When the vulnerable Tomcat is running on a Windows host and the HTTP PUT request method is enabled (for example, the readonly initialization parameter is set to false from the default value), the attacker may be able to upload to the server through a carefully constructed attack request packet A JSP webshell file containing arbitrary code, the malicious code in the JSP file will be executed by the server, resulting in data leakage on the server or obtaining server permissions.
2. Scope of influence
Apache Tomcat 7.0.0 – 7.0.79
3. Vulnerability analysis
The first statement is that the conditions for exploiting the CVE-2017-12615 vulnerability are that Windows+Tomcat 7.0.x+配置文件readonly=falsethe content of the configuration file is as follows:
init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>
When Tomcat sets readonly to false, it also enables support for the PUT request method. At this time, it means that we can upload files, so can we upload any files? No, we first need to understand the following two generals of Tomcat:
org.apache.jasper.servlet.JspServlet: handles jsp and jspx file requests by default, there is no PUT upload logic, and cannot handle PUT requests
org.apache.catalina.servlets.DefaultServlet: handles static files by default (except jsp, jspx file), there is PUT upload processing logic, which can handle PUT requests.
So even if we can PUT a file to the server, we cannot directly PUT files ending with jsp, jspx, because these files with these suffixes are all processed by JspServlet, and it cannot handle PUT requests.
But when we use the Windows feature to upload files in the following two ways, tomcat does not think it is a jsp file and hands it to DefaultServlet to process, thus successfully creating the jsp file, which is the so-called CVE-2017-12615 vulnerability.
evil.jsp%20
evil.jsp::$DATA
In addition, when we upload a file of type evil.jsp/ (that is, end with a backslash), the jsp file will also be successfully created, and this method will eliminate the PUT vulnerability The utilization extends to all versions of the Linux platform and Tomcat 5.x-9.x.
4. Environment construction
Vulnerability environment, we use vulhub deployment, deployment method, Baidu.
5. Vulnerability recurrence
The browser accesses the vulnerable environment, and BP captures packets 
to construct an attack request and send it
using the Ice Scorpion connection
2. Tomcat file reading/file inclusion vulnerability (CVE-2020-1938)
1. Vulnerability description
On February 20, 2020, the National Information Security Vulnerability Sharing Platform (CNVD) released a security bulletin about Apache Tomcat, and the Apache Tomcat file contained a vulnerability (CNVD-2020-10487, corresponding to CVE-2020-1938). Due to the implementation defect of the Tomcat AJP protocol, the relevant parameters are controllable. An attacker can use this vulnerability to read any file under the server webapp by constructing specific parameters. If the file upload function exists on the server side at the same time, the attacker can further realize remote code execution.
2. Scope of influence
Apache Tomcat 6
Apache Tomcat 7 < 7.0.100
Apache Tomcat 8 < 8.5.51
Apache Tomcat 9 < 9.0.31
3. Brief Analysis of Vulnerabilities
The Tomcat server establishes a connection with the client program through the Connector connector component, and the "connector" indicates an endpoint that receives a request and returns a response. That is, the Connector component is responsible for receiving the client's request and sending the response result of the Tomcat server to the client.
Tomcat configures two connectors in its configuration file server.xml by default:
HTTP connector
AJP connector
The HTTP connector is configured as follows. It listens on port 8080 and is responsible for establishing HTTP connections. This is what is used when accessing the web application of the Tomcat server through a browser
The AJP connector can interact with another web container through the AJP protocol. It listens on port 8009 and is responsible for establishing connections with other HTTP servers. This connector is needed when integrating Tomcat with other HTTP servers. The AJP connector can interact with a web container through the AJP protocol. By default, after the tomcat configuration is complete, the AJP connector service in the conf/server.xml file listens on port 8009.
Through the Gh0stcat vulnerability, an attacker can read arbitrary files in all webapp directories deployed under Tomcat. At the same time, if the application has an upload function in the website service, the attacker can also first upload a malicious file containing JSP code to the server (the uploaded file can be of any type, picture, plain text file, etc.), and then use Gh0stcat to upload the file Contains, thereby achieving code execution hazards.
4. Exploitation
Vulnerability environment is built using vulhub. After building, visit to
download the POC file https://github.com/YDHCUI/CNVD-2020-10487-Tomcat-Ajp-lfi/
and read the WEB-INF/web.xml file
5. Repair suggestion
1. Immediately upgrade Tomcat to version 9.0.31, 8.5.51 or 7.0.100 for repair.
2. Disable the AJP protocol.
Edit /conf/server.xml and find the following line:
<Connector port="8009"protocol=“AJP/1.3” redirectPort=“8443” />
Comment out this line (you can also delete it):
Configure the secret to set the authentication credentials for the AJP protocol.
For example (note that YOUR_TOMCAT_AJP_SECRET must be changed to a value that is highly secure and cannot be easily guessed):
<Connector port="8009"protocol=“AJP/1.3” redirectPort="8443"address=“YOUR_TOMCAT_IP_ADDRESS” secret=“YOUR_TOMCAT_AJP_SECRET”/>
3. Tomcat deserialization vulnerability (CVE-2020-9484)
1. Vulnerability description
On May 20, 2020, Beijing time, Apache officially released a risk notice for Apache Tomcat remote code execution, and the vulnerability number is CVE-2020-9484.
Apache Tomcat is an open source, Java-based web application software container that runs servlet and JSP web application software. When Tomcat uses the built-in session synchronization function, there will be a deserialization vulnerability if the unsafe configuration (without using EncryptInterceptor) is used. An attacker can attack the Tomcat server that uses the built-in session synchronization function through carefully constructed data packets. attack.
Successful exploitation of this vulnerability requires the following four conditions to be met:
1. The attacker can control the content and file name of the file on the server
2. FileStore is used in the server PersistenceManager configuration
3. The sessionAttributeValueClassNameFilter in the PersistenceManager is configured as "null", or the filter is not strict enough, allowing the attacker to provide an object to deserialize data
4. The attacker knows the relative path from the FileStore storage location used to the attacker-controlled file
2. Scope of influence
Apache Tomcat 10.0.0-M1—10.0.0-M4
Apache Tomcat 9.0.0.M1—9.0.34
Apache Tomcat 8.5.0—8.5.54
Apache Tomcat 7.0.0—7.0.103
3. Environment construction
Use docker to build
git clone https://github.com/masahiro331/CVE-2020-9484.git //下载环境
cd CVE-2020-9484
docker build -t tomcat:groovy . //创建镜像
docker run -d -p 8080:8080 tomcat:groovy //开启服务
After building, visit
4. Exploitation
Directly execute POC to load malicious session persistent files through JSESSION
curl 'http://192.168.10.171:8080/index.jsp' -H 'Cookie: JSESSIONID=../../../../../usr/local/tomcat/groovy'
Enter container verification
docker exec -it $CONTAINER /bin/bash
ls /tmp/rce
5. Bug fixes
1. Upgrade version
Upgrade to Apache Tomcat 10.0.0-M5 and above Upgrade
to Apache Tomcat 9.0.35 and above
Upgrade to Apache Tomcat 8.5.55 and above Upgrade
to Apache Tomcat 7.0.104 and above
2. Forbidden to use Session persistence function FileStore