Tomcat vulnerability utilization and security reinforcement instance analysis

Tomcat is a free and open-source WEB application server of the Apache Software Foundation. It can run on Linux, Windows, and other platforms, thanks to its stable performance, good scalability, and free features, it is favored by many users. Currently, most java web applications on the Internet run on Tomcat servers.

Tomcat is the carrier of Web applications. Once security problems occur, the security of Web applications running on Tomcat cannot be guaranteed. Therefore, it is necessary to study Tomcat vulnerabilities and security. This article describes Tomcat Attack and Defense in detail through examples. From the perspective of attackers, the author first describes in detail how attackers intrude into the website by exploiting Tomcat vulnerabilities that are often used during penetration testing, in the end, the server is fully controlled, and then the network security management personnel's point of view, in view of the characteristics of Tomcat, details on how to perform security reinforcement for Tomcat.

Use Tomcat management background configuration vulnerabilities to penetrate website instances

Tomcat has a management backend by default. The default Management address is http: // IP or domain name: Port Number/manager/html. With this background, you can conveniently deploy, start, stop, or uninstall WEB applications without restarting the Tomcat service. However, improper configuration poses a major security risk. Attackers can exploit this vulnerability to quickly and easily intrude into a server. Let's look at an instance.

Target IP Address: 192.168.30.128

Purpose: to fully control the server and obtain administrator privileges

Penetration Process:

Now let's access http: // 192.168.30.128: 8080/manager/html. The server will prompt you to enter your account and password, as shown in figure 1.

Figure 1

How can we get this user name and password? There are currently three options:

1. If you use Tomcat installation version running on Windows platform, and the version is between Tomcat 5.5.0 to 5.5.28 or Tomcat 6.0.0 to 6.0.20, we can use the CVE-2009-3548 vulnerability to log on to the background. If the version of Tomcat affected by this vulnerability is not changed during installation, Tomcat creates an account named "admin" by default, and the password is empty. 2 is the default tomcat-users.xml configuration file for tomcat installation version 5.5.27:

Figure 2

Note: The installation-free version of Linux and Windows platforms is not affected by this vulnerability.

2. If we use characters like "tomcat" and "654321" that are easy to guess as passwords, we can directly guess the background account and password.

3. If the first two methods are ineffective, we can use brute-force cracking to crack accounts and passwords. The success rate depends on whether the dictionary is powerful. This tool is available in both Windows and Metasploit. Next we will demonstrate how to use Metasploit to brute force crack Tomcat background accounts and passwords.
Open the Metasploit console, enter "use auxiliary/logs/http/tomcat_mgr_login", and set the corresponding configuration information, as shown in figure 3.

Figure 3

After setting, enter the "run" command to start executing the script. Because the password is relatively simple, it was quickly cracked, as shown in figure 4.

Figure 4

Now we have obtained the account and password of the Tomcat management background. You can log on to the background directly and upload a war-format Trojan. In this way, we get a webshell, as shown in Figure 5.

Figure 5

Figure 6

As shown in figure 6, Tomcat runs with the highest system permission. Therefore, you can directly add a backdoor account without privilege escalation.

Figure 7

From 7, we can see that a jspshell Administrator group account is successfully added and port 3389 is enabled on the target server. We can log on through remote desktop, as shown in figure 8.

Figure 8

So far, this server is under our full control. From the above process, we can see that the consequences of such vulnerabilities are very serious, and the attack is difficult. In fact, China Telecom once experienced such a vulnerability in a business system, as shown in figure 9.

Figure 9

Security reinforcement

Tomcat security reinforcement mainly involves two aspects: first, whether the Tomcat Web Server is secure, for example, whether there are security vulnerabilities, and second, whether the Tomcat Web Server provides available security functions, this part mainly checks whether Tomcat is properly configured and balances security, availability, and stability.

Tomcat version selection and Installation Considerations

Check whether the current Tomcat version has a security vulnerability. If the current version has a security vulnerability, You need to upgrade it to a new security version. When selecting the Tomcat version, we generally choose the latest stable version. This can strike a good balance between security and stability. If you want to upgrade from a lower version to a higher version, we recommend that you pass the test in the test environment before upgrading to avoid compatibility issues. About Tomcat security vulnerabilities can be concerned about the official release of the Security Bulletin (http://tomcat.apache.org/security.html), you can also pay attention to some of the latest vulnerability Release Platform Tomcat vulnerability information.

Use the custom installation path and customize the WEB root directory during installation. You can modify the default WEB root directory in server. xml under the conf directory of the Tomcat installation directory. Open server. xml and find the content shown in 10:

Figure 10

Add the following content before </Host>:

<Context path = "" docBase = "D:/javaweb" debug = "0" reloadable = "true" crossContext = "true"/>

The preceding statement sets the Tomcat virtual path. path indicates the virtual directory, which can be customized or empty. docBase indicates the physical path. If you access http: // 192.168.30.128: 8080 according to the preceding settings, the files in the D: \ javaweb directory are actually accessed. If the path value is not empty, for example, when it is set to path = "java", the access should be as follows: http: // 192.168.30.128: 8080/java. After the modification is complete, restart the tomcat service to take effect.

Tomcat Security Configuration

A. Tomcat downgrading

In Windows, Tomcat runs with the System permission (11) by default. The consequence is that once the WEB application is successfully intruded, a high-Permission Webshell will be obtained directly, the server can be fully controlled without permission escalation.

Figure 11

Now we will perform the downgrading operation on Tomcat. Create a new user, set a complex password, and make it not belong to any user group, as shown in Figure 12.

Figure 12

Go to "Local Security Policy"> "Local Policy"> "user permission allocation", find "Log on as a service", and add the user you just created, 13.

Figure 13

Open the "service" component, find the Tomcat Service, right-click "properties" ---> "Log on", and run the tomcat service with the newly created Tomcat account, 14.

Figure 14

Find the Tomcat installation directory, assign full control permissions for the "Administrators Group" and "tomcat" accounts, and delete all permissions for other accounts. If you do not assign permissions to the tomcat account, the Tomcat service cannot be started. Then, you need to assign permissions to the Tomcat log directory and the WEB directory separately based on the minimum permission principle. You only need to assign the "read" and "write" permissions to the log directory.

Note: You can use the following principles to grant permissions to WEB directories: write permission; Do not assign execution permission; Do not assign write permission if you have execution permission.

Generally, you need to assign the write permission to the upload directory and database directory, but do not assign the execution permission. Generally, you only need to assign the read permission to other directories. After the configuration, you must restart the Tomcat service to make the configuration take effect.

Figure 15

B. Tomcat Log Security Configuration

Regardless of the server, logs are a very important part. We need to strictly protect them, as well as on Tomcat, its logs are stored in the logs directory of the Tomcat installation directory by default. Note that Tomcat does not enable access logs by default, so we need to manually enable it. Open server. xml, find the following code, and remove the comments, as shown in Figure 16.

Figure 16

Then, modify the default log storage path and set that only the system administrator has full control permissions on the log storage directory. The tomcat account has the "read" and "write" permissions, as shown in figure 17.

Figure 17

C. delete default documents and sample programs

If you do not have a custom WEB directory, you also need to delete the servlets-examples and tomcat-docs directories under the default WEB root directory and all their files. To avoid unnecessary information leakage or other vulnerabilities. Some examples under the servlets-examples and tomcat-docs directories have seen security vulnerabilities such as CVE-2007-2449 and CVE-2007-1355.

D. Tomcat default Management Background Security Configuration

Tomcat has a management backend by default. Improper configuration may cause serious security vulnerabilities. In the initial instance, we used this vulnerability to successfully intrude into the target server. Therefore, it is very necessary for us to reinforce security. In general, this function is not required, so we recommend that you delete this management page. Delete manager. xml in the % tocmat_home %/conf/Catalina/localhost directory.

We recommend that you use the manager if necessary. modify the xml file name to a file name that is difficult to guess, and find the tomcat-user.xml under the conf directory of the Tomcat installation directory, set a Complex Administrator account and password