Teach you from a defensive perspective Thinkphp history of vulnerability

One, foreword

In early nineteen nineteen, two RCE vulnerabilities in Thinkphp5 were published online. The vulnerability was so good that many attackers used scanners to scan the entire web. We continue to observe a large number of getShell attack traffic using these vulnerabilities through IPS devices. This paper mainly analyzes the whole network scanning and GetShell traffic traces of attacks using ThinkPHP from the perspective of traffic.

Thinkphp RCE vulnerability and scan traffic

2.1 Review of vulnerability principles

2.1.15.0.x version Vulnerability

Principle is to Thinkphp processing requests the key class for the Request (Thinkphp/library/think/Request. PHP), the class can implement some Settings of the HTTP Request

Thinkphp supports the configuration of a form masquerad variable, which by default is _method, so in method() you can override any function of that class by using a form masquerad variable, passing $_POST as an argument to the function. Requests can be constructed to override the value of a Request class attribute, such as overriding the Filter attribute, which holds the function for global filtering, to implement code execution.

2.1.25.1.x-5.2.x Vulnerabilities

Similar with 5.0 x version loopholes, leak point exists in the Request (thinkphp/library/think/Request. PHP) class, including:

The $method variable is $this->method, which is equivalent to the value of the “_method” parameter of POST, and can be used to override the value of the $filter attribute, which holds the function for global filtering.

When this vulnerability is triggered, an abnormality at the warning level will occur and the program will terminate. In this case, it is necessary to set the exception prompt to be ignored and configure error_reporting(0) in public/index.php to ignore the exception and continue to run the code, as shown in the following figure:

2.2 Network scan for Thinkphp vulnerabilities

From a traffic perspective, taking advantage of the Thinkphp vulnerability is sending an HTTP packet. We found some hackers scanner is to write a simple sentence as a fingerprint, subsequent access to the file to see if back to fingerprint information, access to successfully explain the shell has been successful, is basic to deliver two HTTP packets, scanner shell to write down the successful writing website IP and then manually with a kitchen knife connection url, for subsequent operations.

According to IPS device logs and manual verification, the attack steps of the attacker include two steps: 1. Scan the whole network and send EXP, and check whether getshell is detected based on fingerprint. 2, kitchen knife connection, remote control;

2.2.1 Exp is sent for scanning the entire network

Generally, scan logs traverse section B or C, and the time is relatively intensive. A scanner log fragment is recorded as follows:

It has three characteristics: 1. The destination IP addresses are in the same SEGMENT C or B; 2. The ports are fixed; 3

The packet sent by the scanner to confirm that shell has written successfully adopts the fingerprint dedicated by the scanner. Therefore, the IPS does not have this detection rule.

2.2.2 Kitchen knife Connection

Ips will also detect the attacker’s manual kitchen knife connection to the compromised site, and trace the source to the ThinkPHP vulnerability through context as the attacker’s breakthrough. Select a few typical cases recorded at the time:

Compromised Zhengzhou server 1 (122.114.24.216) :

The site did launch for ThinkPHP5 while the Webshell Trojan was still on the server. The Trojan uploaded by the hacker can be accessed through the server. The fingerprint information is Baidu, and the scanner uses this fingerprint to automatically judge the success of GetShell and record the URL.

Compromised Sichuan server (182.151.214.106) :

Compromised Sichuan server (182.151.214.106) :

In this case, although the Trojan was removed, the server was still connected. The server was also a ThinkPHP framework, and the user name was chanpei

The device records the packets when the hacker connects to the Trojan horse and executes the network query command. The information obtained is consistent with the preceding error information. In addition, it can be seen that the server is also a machine on 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:

Compromised US server (161.129.41.36) :

The Webshell on the server in America was also cleaned up. Through packet capture, it was found that some hackers used the same Webshell Trojan horse, namely X. HP, and they were suspected to be the same group of hackers.

When the hacker browsees the x. HP (Webshell) file content on the US server, the device records that the password of X. HP is Xiao and the flag bit is Baidu.

You can see that by using these two Thinkphp high-risk RCE vulnerabilities, a large number of server vulnerabilities were swept up.

Third, summary

This article combined with the history of Thinkphp vulnerability principle, to share the discovery of Thinkphp vulnerability attack successful cases. At present, the most logs detected by the device every day are webLogic, Struts2, ThinkPHP direct getShell logs or SSH RDP brute force cracking logs. Many attackers find the latest EXP and deploy it to their scanner to sweep the net, which can be several shells a day. Therefore, after the occurrence of high-risk vulnerabilities, users are advised to patch in time and configure security device policies. From several actual cases, the risk of scanners has always been there. This threat can be mitigated to some extent if websites are configured to prohibit direct IP access. Due to the limited level, we welcome you to point out the mistakes and exchange advice

To learn more, please visit:

Tencent T3-T4 standard boutique PHP architect tutorial directory directory, as long as you finish the guarantee salary rise a step (continue to update)

I hope the above content can help you. Many PHPer will encounter some problems and bottlenecks when they are advanced, and they have no sense of direction when writing too many business codes. I have sorted out some information, including but not limited to: Distributed architecture, high scalability, high performance, high concurrency, server performance tuning, TP6, Laravel, YII2, Redis, Swoole, Swoft, Kafka, Mysql optimization, shell scripting, Docker, microservices, Nginx, etc.