ThinkPHP 5.1框架结合RCE漏洞的深入分析(9)

来看下这3个if条件，在默认配置下，由于没有路由绑定，所以$bind为null。而empty_module默认模块也没有定义。所以第三个也不满足，那么只能寄托于第二个了。

在第二个中，1是判断$module是否在禁止访问模块的列表中，2是判断是否存在这个模块。

所以，这就要求我们在构造POC时，需要保证模块名必须真实存在并且不能在禁用列表中。在默认配置中，我们可以指定index默认模块，但是在实际过程中，index模块并不一定存在，所以就需要大家去猜测或暴力破解了，不过一般模块名一般都很容易猜解。

获取到模块、类名后，就是对其进行解析组成命名空间了。此过程对应上面第四大节中的4.3.4路由调度中。

这里首先对$name(类名)进行判断，当$name以反斜线\开始时会直接将其作为类的命名空间路径。看到这里然后回想一下之前的分析，我们会发现这种命名空间路径获取的方式和之前获取的方式不一样(之前是进入了parseClass方法对模块、类名等进行拼接)，而且这种获取是不需要和模块有联系的，所以我们想是不是可以直接将类名以命名空间的形式传入，然后再以命名空间的特性去自动加载类？同时这样也脱离了模块这个条件的束缚。

那我们现在再试着构造下POC：

剩下就是指定$function参数和$var参数值了,根据传参特点，我们来构造下。

http://127.0.0.1/tp5.1.20/public/index.php/index/think\Container/invokefunction/function/call_user_func_array/vars[0]/phpinfo/vars[1][]/1

构造出来应该是这样的，但是由于在pathinfo模式下，$_SERVER['PATH_INFO']会自动将URL中的“\”替换为“/”，导致破坏掉命名空间格式，所以我们采用兼容模式。

默认配置中，var_pathinfo默认为s，所以我们可以用$_GET[‘s’]来传递路由信息。

http://127.0.0.1/tp5.1.20/public/index.php?s=index/think\Container/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1][]=1

另外由于App类继承于Container类，所以POC也可以写成：

http://127.0.0.1/tp5.1.20/public/index.php?s=index/think\App/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1][]=1

漏洞利用扩大化

1.以反斜线\开始时直接将其作为类的命名空间路径。

2.thinkphp命名空间自动加载类的特性。

由于这两点，就会造成我们可以调用thinkphp框架中的任意类。所以在框架中，如果其他类方法中也有类似于invokefunction方法中这样的危险函数，我们就可以随意利用。

例如：Request类中的input方法中就有一样的危险函数。

跟入filterValue方法 。

POC:

http://127.0.0.1/tp5.1.20/public/index.php?s=index/\think\Request/input&filter=phpinfo&data=1 六、结语

写这篇文章的其中一个目的是想让大家知道，通过框架分析，我们不仅可以在分析漏洞时变得更加容易，同时也可以对漏洞原理有一个更深的理解。所以，当我们在分析一个漏洞时，如果很吃力或者总有点小地方想不通的时候，不如从它的框架着手，一步一步来，或许在你学习完后就会豁然开朗，亦或者在过程中你就会明白为什么。