Analysis of unsafe decompression GetShell instances discovered through traceability

Recently, when we helped a customer trace an intrusion incident, we found that the hacker used the website's "ZIP decompression function" to upload a Webshell before gaining access to the server. Because this leakage exploitation method is relatively representative in terms of "attack payload structure" and "actual decompression path", and the industry still does not pay enough attention to the "unsafe decompression" vulnerability. Therefore, we wrote this report, in which we explain the process of intrusion tracing and vulnerability discovery, and put forward some security suggestions from the two dimensions of security development and security dog ​​product protection solutions, hoping to benefit the industry.

It is worth noting that although the CMS has made relevant defense configurations, if you directly write the JSP file in the root directory of the CMS, it will not be executed and a 403 error will be reported. The attacker took advantage of the automatic deployment feature of the war package and used the idea of ​​​​"directory traversal" to make the war package jump out of the root directory of the CMS.

1. Intrusion traceability

A company’s operation and maintenance personnel discovered certain abnormalities in the system while on duty late at night. In order to investigate the problem as soon as possible, the customer contacted our company. Haiqing Laboratory then intervened to conduct traceability and analysis, and provide subsequent disposal plans.

It can be found by checking Tomcat’s log file /logs/localhost_access_log.yyyy-MM-dd.txt. Looking at the log, we can find that the attacker once blasted the login interface of the website (for "POST /cmscp/ "login.do" interface has a high access frequency), as shown in the figure.

Note: The HTTP status code when the blast is successful is 302, and the HTTP status code when the blast fails is 303.

In order to determine whether the attacker has uploaded a website Trojan, use Website Security Dog's Webshell AI detection engine to scan Tomcat's webapps directory. It can be found that the file named "/admin/login.jsp" is recognized as a Webshell (Hackers’ naming of this Webshell is somewhat confusing), as shown in the figure.

#After further manual confirmation, it can be determined that the jsp file is indeed a Webshell. And it is related to the automatic deployment of the admin.war file, as shown in the figure.

So how is this war package uploaded to the server? Continue to analyze the log file, focus on the "interface that may be a file upload function" during the analysis. It can be preliminarily determined that the hacker used the ZIP upload and ZIP decompression functions before using this webshell, as shown in the figure.

Find the test5.zip file called by the file decompression interface on the server. After analyzing it, you can find that the path where admin.war is located is "test5.zip\.. \..\..". Therefore, the ZIP file is a malicious file carefully constructed by hackers. It will make the decompression path of the war package no longer the default "/uploads/1" directory, but Tomcat's "webapps" directory, as shown in the figure.

Note: How to generate the malicious zip file in this article

(1) Execute the following python script to generate test5.zip:

import zipfile if __name__ == "__main__": try:binary = b'<script>alert("helloworld")</script>'zipFile = zipfile.ZipFile("test5.zip", "a", zipfile.ZIP_DEFLATED) info = zipfile.ZipInfo("test5.zip")zipFile.writestr("../../../safedog.html", binary)zipFile.close()except IOError as e: raise e

(2) Drag the war package containing Webshell to "test5.zip", as shown in the figure.

2. Code audit

Through the previous intrusion traceability analysis, it can be preliminarily concluded that this attack is related to the "ZIP" of the CMS Decompression interface" (GET /cmscp/core/web_file_2/unzip.do?ids={ids}&parentId={parentId}) is closely related. This interface corresponds to the unzip method of WebFileUploadsController.java, as shown in the figure.

Follow up the unzip method and find that its specific implementation is in WebFileControllerAbstractor.java. It can be found that when decompressing the zip file, the unzip method of the AntZipUtil class is called, as shown in the figure.

Following up the unzip method of the AntZipUtil class, we can find thatthis method does not perform parameter verification on the file name in the ZIP compressed package, just write the file. Such code writing will cause directory traversal vulnerability, as shown in the figure.

Currently, Haiqing Lab has submitted the vulnerability to CNVD and notified the manufacturer to fix it.

3. Summary

Through this example, we can find that the security of the decompression function may cause great harm to the security of the website (taking the Spring Integration Zip development component as an example, it also The "insecure decompression vulnerability" CVE-2018-1261 was exposed). If the website's business involves decompression functions, it is recommended to pay more attention to the dimension of security development. In addition, Safe Dog also provides corresponding product defense solutions.

In terms of security development, it is recommended that R&D personnel conduct self-examination and restrictions from the following aspects when implementing the decompression algorithm:

(1) Whether to limit the number of files in the compressed package Extension

For example: .war, .jsp, jspx, .jsp::$DATA (only affects Windows hosts)

(2) Whether to limit the actual decompression path of the files in the compressed package

(3) Whether to limit the total size of the files in the compressed package (to prevent denial of service attacks caused by the compressed package**)

(4) Whether to grant reasonable permissions to the Web application directory

In addition, we also recommend that users choose reliable and professional security products. For example, users who have installed safety dog ​​products will automatically receive an alarm text message from the system once a security incident occurs, so they can intervene as soon as possible to avoid larger incidents. Loss.

In terms of "Security Dog Product Defense", it is recommended that users use the website background protection of "Website Security Dog" and "Yunyu" as well as the file directory of the server dog The protection function, the web page background path protection function of Yunyu and Website Security Dog can protect against website background brute force behavior.

Yunyu's background protection function is as shown in the figure:

The website security dog's background protection function is as shown in the figure:

Server folder directory guard function:

The above is the detailed content of Analysis of unsafe decompression GetShell instances discovered through traceability. For more information, please follow other related articles on the PHP Chinese website!