插件窝 干货文章 ThinkPHP6.0.13反序列化漏洞分析

ThinkPHP6.0.13反序列化漏洞分析

png uploads picture 方法 962    来源:    2024-10-26

最近有点闲下来了,不找点事干比较难受,打算找点漏洞分析一下,于是就打算看看tp的一些漏洞,thinkphp6.0.13是tp的最新版,八月份有师傅提交了一个issue指出tp存在反序列化问题,网上也有些师傅分析了一波,不过断点下的比较多,而且部分方法没有阐明其用途,所以我也尝试详细的分析一波。下面先给出poc

分析

首先看看POC的起始点

2.png

立即学习“PHP免费学习笔记(深入)”;

3.png

发现起始点在Psr6Cache这个类,我们进入这个类,不过没有发现__destruct或者__wakeup等常见的反序列化起始魔术方法,推测应该在其父类AbstractCache这个抽象类中。跟入AbstractCache类

4.png

如图,成功发现本次反序列化链子的起始类。这里我们可以控制autosave这个属性为false,从而进入save方法。

回到Psr6Cache类查看这个方法

5.png

可以发现,pool属性和key属性我们都可控。因此可能存在两种路线,调用不同类的同名方法(getItem)。或者是直接尝试触发__call方法。我们来看看POC作者是怎么让反序列化进行下去的。

6.png

作者用构造方法传入了exp,exp其实就是在实例化Channel类。我们进入Channel类查看

7.png

Channel类中有一个__call方法,那么作者是选择触发__call来让链子继续下去。这个call方法接受了两个参数,method是写死的(getItem),parameters是可控的(即前面可控的key属性)

8.png

跟入log方法查看,其接受三个传参(但是其实对后续的链子没啥用),传入record方法

9.png

跟入record方法

10.png

再返回查看作者的POC,发现其控制lazy属性为false,让函数进入最后一个if分支执行save方法

11.png

那么save方法应该是比较关键的方法了,跟入save方法,这里面有三个可能被利用的点,作者选择了哪一个呢?

12.png

根据POC不难发现作者选择了控制logger属性,利用构造函数对其赋值,令其为Socket类的对象

13.png

14.png

在这个类中,我们找到了一个复杂的同名方法,其中有大量的操作。

15.png

我们继续来看作者是怎么构造的,作者控制config属性,给其赋值为数组。数组有如下内容

16.png

关键在于这两个键值,作者控制config,让程序运行到调用invoke方法的分支

17.png

同时,app属性可控,作者令app属性为App类的对象,我们进入App类

18.png

这里先看看App类的的exists方法的情况,在其父类中找到了这个方法

19.png

继续往后,这里对App类进行了唯一一个操作,控制了instances属性的值。这里控制其值是为了进入Request类,并且执行url方法

20.png

21.png

作者在这里对Request类做出唯一的操纵,就是控制url属性的值。可以看出,如果url属性存在,那么就会进入第一个分支,其值等于本身。

22.png

同时又注意到,complete我们之前传入的是true。因此最终返回的结果就是$this->domain().$url,url我们已经控制了,那么domain方法返回什么呢?

23.png

OK,这点我们就不用看了。分析了这么多,我们得到了$currentUri最后的值,就是:

http://localhost/

24.png

currentUri作为一个数组被传入invoke了,根据链子的长度,达到invoke,我们的反序列化之旅就快结束了

25.png

查看invoke,App类找不到这个方法,在他的父类里找到了这个方法

26.png

这里可以看到。这个函数内有三分支走向,那么最终会走向哪里呢?根据我们之前$config[‘format_head’]的传入, 首先我们传入的这个对象不是Closure的实例或者子类,并且也不满足第二个分支的条件

27.png

因此进入到到第三个分支。我们跟进invokeMethod()方法。这里传入的$callabel就是[new \think\view\driver\Php,'display']、而$vars就是[‘http://localhost/’]

28.png

注意,我们传入的$method是数组,因此进入第一个分支。把new \think\view\driver\Php (即对象)赋值给$class,’display’(即方法名)赋值给新的$method。

然后下面进行了一个判断,如果$class是对象,那么其值就为它本身,因为我们传入的是对象,所以这里没什么变化。然后进入最关键的代码

可以看到,把对象new \think\view\driver\Php 以及方法 display传入了ReflectionMethod。

29.png

在最后,调用invokeArgs方法,传入了new \think\view\driver\Php对象,同时传入了$args

30.png

那么args是什么呢?

31.png

我们跟入之后发现是一个处理函数,因为本人比较懒,而且到这都快分析完了,就不去硬读了,直接给结论,总之我们传入的 $vars ,也即 [‘http://localhost/’] 其中的关键部分保留了下来,并且进入到了后续的传参中

32.png

继续往后看,对于这个函数(invokeArgs),可以简单的类比call_user_func(),因此最后的关键代码其实只有这两行

33.png

也即

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

常看tp反序列化的朋友就知道,已经结束咧!毕竟调用display方法了。但是上述这个调用ReflectionMethod类的操作到底是什么呢?我们可以借助如下实例来演示。所以说这玩意和call_user_func很像

34.png

最后是display方法,没什么好说的了,content传入display方法中,eval执行命令了

35.png

结语

TP的链子一如既往的有意思(以及复杂),特别是最后的ReflectionMethod类的用法上,如果不了解这个类以及类中的方法组合可以实现类似call_user_func函数的作用的话,那么就很容易错过这样一个精彩的漏洞。

【相关教程推荐:thinkphp框架】