Foreword
I haven't audited the code for a few days after I made the question. Today I took advantage of the PE class to review the code execution vulnerability of ThinkPHP5.1.x.
At first I wanted to make a big summary. After reading the articles on the Internet, the summary has been very good. I will not move the bricks.
This article is just for exercise, even ThinkPHP5.1.x, because of their different versions, whether the debug is enabled or not will cause different payloads. And now that RCE basically does not exist, just look for ideas. .
0x01
Write a small summary here, just mention it.
Let ’s first clarify the
difference between two major versions of rce
ThinkPHP 5.0-5.0.24
ThinkPHP 5.1.0-5.1.30
continues to be subdivided according to the payload:
One is caused by the method and __construct method of the Request class, and the other is because the controller obtained by the Request class in the compatibility mode has not been legally verified:
continue to subdivide:
1: Thinkphp5 method arbitrary call method leads to rce
's last article is the analysis of this:
$ this-> method can be controlled to call __contruct () to override the filter field of the Request class, and then App :: run () executes the judgment debug to determine Whether to execute $ request-> param (), and if $ dispatch ['type'] is equal to controller or method, $ request-> param () will also be executed, and $ request-> param () will enter input () Method, in this method will be overwritten filter callback call_user_func (), causing rce.
2: rce caused by method __contruct
The ideas are basically the same, but the details are different. In addition, 1 and 2 must enable debugging to RCE. When there is captcha routing, debug = true is not required.
3: Rce is not enabled due to forced routing
The relationship between the version and the DEBUG option
Sometimes you will find that even the version is still not RCE
After version 5.0.13, you need to enable debug to rce.
However,
in the thinkphp5 full version, the official website rubbed in a route of the verification code, which can be triggered by this route
.
Detailed payload summary:
https://y4er.com/post/thinkphp5-rce/
0x02
The topic we are going to analyze today is the rce
environment caused by the failure to enable mandatory routing :
"require": {
"php": ">=5.6.0",
"topthink/framework": "5.1.29"
},
The cause of the vulnerability:
thinkphp does not enable mandatory routing
by default, indicating that we can use the s parameter in the routing compatibility mode, and the framework does not perform sufficient detection on the controller name, indicating that it may be possible to call any controller and any method to execute,
eg: http: // site /? s = module / controller / method
access:
Look at the analysis of the payload:
first of all, we must know that
all user parameters will be processed by the input method of the Request class, which will call the filterValue method, and call_user_func is used in the filterValue method. This was also mentioned in the previous article analysis.
Find the request method
Follow up to thinkphp / library / think / App.php: 402
Follow up
routeCheck ()
is on this page. This method finally
returns $ dispatch
Through breakpoint
We see this method replaces our / with |
continue to look at init ()
Enter Url.php
Enter parseUrl
enter
Enter parseUrlPath ()
Here I got
[module / controller / operation] from the URL , which caused the route returned by parseUrl () to be
index think \ Request input.
Why? We return to parseUrl () to find the route
Resulting in the $ dispatch of thinkphp / library / think / App.php: 406 as
Directly call the input () function, and then execute to the run method of the App class
Also shown here
Then call the run method of
the Dispatch class. This method will call the key number exec thinkphp / library / think / route / dispatch / Module.php: 84, and then call the reflection class.
We follow up
In the exec function, the program uses the reflection mechanism to call the methods of the class. The classes, methods, and parameters are all under our control. And the whole process, did not see the program to detect the legality of the controller name, which is also the direct cause of the remote code execution vulnerability
All parameters are controllable, we let him call the input method
The input method has been said many times
After entering input (), continue to enter $ this-> filterValue ()
Implement rce
Bug fix
The official repair method is: add regular expression [1] (\ w) * $ to check the legality of the controller name.
// 获取控制器名
$controller = strip_tags($result[1] ?: $config['default_controller']);
if (!preg_match('/^[A-Za-z](\w|\.)*$/', $controller)) {
throw new HttpException(404, 'controller not exists:' . $controller);
}
Finally, use a picture of Master July Fire
A-For-z ↩︎