ThinkPHP6.0.13 Deserialization Vulnerability Analysis

I’ve been a little idle recently, and I feel uncomfortable if I don’t find something to do. I plan to find some loopholes to analyze, so I plan to take a look at some loopholes in TP. ThinkPHP6.0.13 is the latest version of TP. In August, a master submitted one The issue pointed out that TP has a deserialization problem. Some experts on the Internet have analyzed it, but there are many breakpoints, and some methods do not clarify their uses, so I also tried to analyze it in detail. Below is the POC

analysis

First look at the starting point of the POC

We found that the starting point is in the Psr6Cache class. We entered this class, but we did not find common deserialization starting magic such as __destruct or __wakeup. Method, it is speculated that it should be in the abstract class of its parent class AbstractCache. Follow the AbstractCache class

as shown in the figure, and successfully find the starting class of this deserialization chain. Here we can control the autosave attribute to false to enter the save method.

Go back to the Psr6Cache class to view this method

You can find that we can control both the pool attribute and the key attribute. Therefore, there may be two routes to call methods with the same name (getItem) of different classes. Or try to trigger the __call method directly. Let's take a look at how the POC author allows deserialization to proceed.

The author passed in exp using the constructor method, and exp is actually instantiating the Channel class. We enter the Channel class to see

There is a __call method in the Channel class, so the author chooses to trigger __call to continue the chain. This call method accepts two parameters, the method is hard-coded (getItem), and the parameters are controllable (that is, the previously controllable key attributes)

Follow the log View the method. It accepts three parameters (but it is actually useless for subsequent chains). Pass in the record method

followed by the record method

Go back and check the author's POC and find that its control lazy attribute is false, let the function enter the last if branch to execute the save method

Then The save method should be a more critical method. Following the save method, there are three points that may be exploited. Which one did the author choose?

According to the POC, it is not difficult to find that the author chose to control the logger attribute, use the constructor to assign a value to it, and make it an object of the Socket class

In this class we find a complex method of the same name with a large number of operations.

# Let's continue to see how the author constructs it. The author controls the config attribute and assigns it an array value. The array has the following content

The key lies in these two key values. The author controls the config and allows the program to run to the branch that calls the invoke method

At the same time, the app attribute is controllable. The author makes the app attribute an object of the App class. Let’s enter the App class.

Let’s first look at the exists of the App class. In the case of a method, this method was found in its parent class

Moving on, here is the only operation performed on the App class, which controls the value of the instances attribute. The purpose of controlling its value here is to enter the Request class and execute the url method

The author makes the only manipulation of the Request class here, It is to control the value of the url attribute. It can be seen that if the url attribute exists, then the first branch will be entered, and its value is equal to itself.

At the same time, we noticed that the complete value we passed in before was true. Therefore, the final returned result is $this->domain().$url. We have controlled the url, so what does the domain method return?

OK, we don’t need to look at this. After analyzing so much, we got the final value of $currentUri, which is:

http://localhost/

currentUri is passed in as an array Invoked, according to the length of the chain, reaching invoke, our deserialization journey is almost over

Check invoke, the App class cannot find this method, in other This method was found in the parent class

You can see it here. There are three branches in this function, so where will it eventually go? According to what we passed in $config['format_head'] before, first of all, the object we passed in is not an instance or subclass of Closure, and it does not meet the conditions of the second branch

So enter the third branch. We follow up with the invokeMethod() method. The $callab passed in here is [new \think\view\driver\Php,'display'], and $vars is ['http://localhost/']

Note that the $method we passed in is an array, so we enter the first branch. Assign new \think\view\driver\Php (i.e. object) to $class, and assign 'display' (i.e. method name) to new $method.

Then a judgment is made below. If $class is an object, then its value is itself. Because we are passing in an object, there is no change here. Then enter the most critical code

You can see that the object new \think\view\driver\Php and the method display are passed into ReflectionMethod.

At the end, call the invokeArgs method, passing in the new \think\view\driver\Php object, and passing in $args

So what are args?

After we followed up, we found out that it is a processing function. Because I am lazy and have almost finished the analysis at this point, I will not read it hard and give the conclusion directly. In short The key parts of the $vars we passed in, that is, ['http://localhost/'], are retained and entered into subsequent parameters.

Looking further, this function (invokeArgs) can be simply compared to call_user_func(), so the final key code is actually only these two lines

, that is,

$reflect = new ReflectionMethod(new \think\view\driver\Php,’display’);
return $reflect->invokeArgs(new \think\view\driver\Php,’ ’)

Friends who often watch TP deserialization will know that it is over! After all, the display method is called. But what exactly is the above operation of calling the ReflectionMethod class? We can demonstrate this with the help of the following example. So this thing is very similar to call_user_func

The last is the display method, there is nothing more to say, the content is passed into the display method, and eval executes the command

Conclusion

The chain of TP is as interesting (and complex) as ever, especially the usage of the last ReflectionMethod class. If you don’t understand this class and the combination of methods in the class to achieve functions similar to the call_user_func function, it is easy to miss this. A wonderful exploit.

[Related tutorial recommendations: thinkphp framework]

The above is the detailed content of ThinkPHP6.0.13 Deserialization Vulnerability Analysis. For more information, please follow other related articles on the PHP Chinese website!