Tomcat is a small Web application server, which is favored by small enterprise webmasters. The open source code of the Tomcat server occupies a small amount of system resources, provides good scalability, and supports load balancing and email services. Especially on the Linux system platform, the Tomcat server has obvious advantages and has a wide user base.
Recently, Tomcat encountered a new vulnerability. Attackers can exploit this vulnerability to easily access the Web site background, upload jsp Web Trojans, and gain control of the server through further Elevation of Privilege penetration.
When attackers exploit this vulnerability to launch attacks, how can webmasters fix the vulnerability to report the security of Tomcat servers? I have seen a lot of repair methods for this vulnerability in the forum. After my tests, these methods cannot effectively prevent this vulnerability. There are also some pseudo-skills. These so-called skills not only cannot fix vulnerabilities, but also cause server faults.
For example, some people say that deleting Tomcat from its own startup can prevent this vulnerability, but they do not know that deleting Tomcat from its own startup will cause Website access exceptions. Based on this, the author builds a Tomcat environment and finds an effective way to fix this vulnerability after testing, and writes it out for sharing with you.
Environment Description
Windows Server 2003
TOMCAT version: 6.0
Site path: D: javaomcat4
I. intrusion Reproduction
In order to make our vulnerability repair targeted, the author simulates the process by which attackers intrude into the Tomcat server.
1. IP Scanning
Tomcat attackers first determine an IP segment, and then use a scan tool to detect the host with port 8080 enabled in the segment, because the default port of the Tomcat server is 8080. This process is omitted because it is a local test. Run Tomcat 6 directly and start the Tomcat server locally. (Figure 1)
Figure 1
Tip: in actual attacks, attackers can not only scan Tomcat servers, but also guess the username and weak password.
2. log on to the background
The default backend address of Tomcat is http: // www. *. *: 8080/manager/html. In the local test, enter http: // 127.0.0.1: 8080/manager/html in the address bar of the browser. In the displayed logon dialog box, enter the default username admin and password admin, successfully enters the background. (Figure 2)
Figure 2
3. Upload a jsp Trojan
There is an Upload a WAR file to install module in the background of Tomcat, through which you can Upload jsp webpage Trojans. In this example, we upload shell. jsp. By default, the uploaded jsp Trojan is stored in the shell directory and combined with the URL of the website. The URL of the jsp Trojan is http: // 127.0.0.1: 8080/shell. jsp. Enter the URL of the Web horse in the IE address bar to run the Web horse. The disk partitions and site directories of the server shown in 3 are clear at a glance. (Figure 3)
Figure 3
Our purpose is to fix the Tomcat login vulnerability, so we do not have to escalate the permission and complete its penetration simulation test. Below we will fix the Tomcat vulnerability.
Ii. Fix Vulnerabilities
1. Vulnerability Source
I found through testing that Tomcat vulnerability is caused by tomcat-users.xml files. This file stores the username and password for Tomcat background logon. By default, successful administrators obtain the manager permission, that is, Administrator permission. The following is the content of the tomcat-users.xml file in the default state, and the penultimate line is the most critical.
<? Xml version = 1.0 encoding = UTF-8?>
<Tomcat-users>
<Role rolename = "tomcat"/>
<Role rolename = "role1"/>
<Role rolename = "manager"/>
<Role rolename = "admin"/>
<User username = "admin" password = "admin" roles = "admin, manager"/>
</Tomcat-users>
2. Vulnerability repair
Knowing the cause, our vulnerability fix is to modify the tomcat-users.xml file. There are two ways to modify this vulnerability: Change the user name and password, and change the permissions.
1. Change the user name and password
We change the last line of the tomcat-users.xml file to, that is, change the login user to lw, login password to gslw. Finally, log on to the background again for testing. The default user name and password admin Logon failure is shown in Figure 4. The new user name and password are used for logon. (Figure 4)
Figure 4
2. Modify permissions
We changed the last row of the tomcat-users.xml file to remove the manager behind admin, which removes administrator privileges. Restart tomcat (the configuration file will be loaded when Tomcat is restarted, so that the modification will take effect .) As shown in figure 4, logon fails.
Summary: This article demonstrates Tomcat server vulnerabilities and its repair methods are not technically difficult, but these casual details often become server killers. Server managers should improve their security literacy. As a Server Manager, you must be diligent in analyzing and repairing vulnerabilities similar to the ones mentioned in this article.