Teach you how to look at Thinkphp historical vulnerabilities from a protection perspective

The following is the Thinkphp framework development tutorial column to introduce to you the historical vulnerabilities of Thinkphp from the perspective of protection. I hope it will be helpful to friends in need!

1. Foreword

At the beginning of 2019, two RCE vulnerabilities of Thinkphp5 were disclosed on the Internet. The vulnerabilities are very easy to use, resulting in many attackers using scanners to scan the entire network. scanning. We continue to observe a large amount of attack traffic using these vulnerabilities to conduct batch getshell attacks through ips devices. This article mainly analyzes briefly from the traffic perspective and uses thinkphp to attack the entire network scan and getshell traffic traces.

2. Thinkphp RCE vulnerability and scanning traffic

2.1 Review of vulnerability principle

2.1.15.0.x Version vulnerability

The principle is that the key class used by Thinkphp to process requests is Request(thinkphp/library/think/Request.php), which can implement some settings for HTTP requests

Thinkphp Supports configuring "form camouflage variable". By default, the value of this variable is _method. Therefore, in method(), you can use "form camouflage variable" to overwrite the variable to call any function of this class, and $_POST is used as the function. Parameters are passed in. Requests can be constructed to override Request class attribute values, such as overwriting the filter attribute (the filter attribute stores functions used for global filtering), thereby achieving code execution.

2.1.25.1.x-5.2.x version vulnerability

Similar to the 5.0.x version vulnerability, the vulnerability points all exist in Request(thinkphp/library/think/ Request.php) class, where:

##$method variable is $this->method, which is equivalent to the "_method" parameter value of POST, and can be used to override $ The attribute value of filter (the filter attribute stores the function used for global filtering) to achieve code execution.

When this vulnerability is triggered, a warning-level exception will occur, causing the program to terminate. At this time, you need to set the ignore exception prompt. Configure error_reporting(0) in public/index.php to ignore the exception and continue running the code, as shown below:

2.2 Whole network scan for Thinkphp vulnerabilities

From a traffic perspective, using the Thinkphp vulnerability is to send an http packet. We found that a hacker's scanner first writes a simple sentence as a fingerprint, and then accesses the file to see if the fingerprint information is returned. A successful access indicates that the shell has been successful. Basically, it sends two http packets, and the scanner records the successful write. Enter the website IP and URL of the shell and then manually connect with a kitchen knife for subsequent operations.

From IPS device logs and manual verification, the attacker's attack steps include 2 steps: 1. Scan the entire network to send exp, and identify whether to getshell based on fingerprints; 2. Connect with a chopper for remote control;

2.2.1 Whole network scan and send exp

Generally, scanning logs traverse segment B or segment C, and the time is relatively intensive. A certain recorded scanner log fragment is as follows,

has 3 characteristics: 1. The destination IP is the same segment C or B, 2. The port is relatively fixed, 3. The scanning time is very intensive

Scan The message sent by the scanner to confirm that the shell has been written successfully uses the scanner's dedicated fingerprint, so ips does not have this detection rule.

2.2.2 Chopper connection

When the attacker manually connects the compromised site with a chopper, it will also be detected by ips, and the source can be traced to the thinkphp vulnerability through context association. The attacker's breach point. Select a few typical cases recorded at that time:

The compromised Zhengzhou server 1 (122.114.24.216):

This website was indeed developed for thinkphp5, At that time, the webshell Trojan was still on the server and had not been deleted. The Trojan uploaded by the hacker can be accessed through the server. The fingerprint information is baidu. The scanner uses this fingerprint to automatically determine the success of getshell and record the URL.

The compromised Sichuan server (182.151.214.106):

The compromised Sichuan server (182.151.214.106):

This Although the Trojan in the case was removed, the server could still be connected at that time. The server was also a thinkphp framework. The username was suspected to be chanpei

. The device recorded the hacker's connection to the Trojan and execution of network query commands. message, the information obtained is consistent with the above error message. And it can be seen that the server is also located on a machine in the intranet. The screenshot shows that the network contains at least two subnets, 192.168.9.0 and 192.168.56.0, as shown below:

The compromised US server (161.129.41.36):

The webshell on this US server has also been cleaned up. Through device packet capture, it was found that there was a hacker The same webshell Trojan was used, namely x.php, and it is suspected that it is the same group of hackers.

When the hacker browsed the contents of the x.php (webshell) file on the US server, the device recorded that the password of x.php was xiao, and the flag was also baidu.

It can be seen that using these two high-risk RCE vulnerabilities in Thinkphp, a large number of server vulnerabilities were discovered at that time.

3. Summary

This article combines the historical vulnerability principles of Thinkphp and shares the successful cases of exploiting Thinkphp vulnerabilities. Currently, the most common logs detected by the device every day are direct getshell logs such as weblogic, struts2, thinkphp, or ssh rdp brute force cracking logs. Once many attackers discover the latest exploit, they equip their own scanners to scan the entire network, which may result in several shells in a day. Therefore, when high-risk vulnerabilities occur, it is recommended that users apply patches in time and configure security device policies. Judging from several actual cases, the risk of scanners has always been there. If the website can be configured to prohibit direct IP access, this threat can be mitigated to some extent. Due to the limited level, everyone is welcome to point out the errors in the article and share your suggestions

The above is the detailed content of Teach you how to look at Thinkphp historical vulnerabilities from a protection perspective. For more information, please follow other related articles on the PHP Chinese website!