基于框架漏洞的代码审计实战（1）

前言

由于普通的，基于某个功能点的漏洞，已经是非常常见了，在这里分享一些基于框架漏洞的代码审计，毕竟大家都学了这么多反序列化漏洞与一堆的框架，还是要用于实战当中。

环境介绍

某开源项目最新版的CMS，该漏洞已提交至CNVD

查看READ.md，获取项目技术栈的相应版本

可以看到这里的thinkphp版本为5.1.41。正好该版本存在反序列化漏洞。接下来我们的思路就是找到反序列化的触发点。

找寻反序列化入口

如果打过ctf的同学都应该都比较清楚，触发反序列化的点，比较常见的就3种 1,unserialize()函数 2,phar反序列化 3,session反序列化

接下来我们就一个一个分析看看该cms是否存在反序列化入口

unserialize函数

我们直接全局搜索unserialize,看看有那些地方调用了该函数

可以看到有很多地方调用了unserialize函数，如果你看到这些函数就开始一头扎进去，开始分析，那基本上就可以说是对MVC毫无了解，在分析之前，你要确定那些是能调用的，那些是不能调用的，因此必须分析路由，去找寻那些页面是可以访问的，我们一般想调用某些函数，都是通过URL或者POST参数进行调用了。因此知道自己能调用那些函数，是非常重要的，也是缩小分析范围的至关重要的一步。本文分析的CMS是由thinkphp搭建，由于在大部分情况下我们都可以访问控制器下的大部分函数，因此可操作的空间就非常的大，但并不是所有框架都像一样自由

结合路由分析，可以发现并没有路由能访问到unserialize函数，可知unserialize这条路走不通

ession反序列化

其实session反序列化是真的不常见，可能只会在一些ctf中见到，因为两种session模式相互切换的场景是真的不常见，不过我们还是进行分析一下吧。直接全局搜索session.serialize_handler

不出意外，确实没有

phar反序列化

个人认为phar反序列化还是比较容易触发的，因为在很多功能点都会对文件进行判断，而有许多判断函数都可以触发phar反序列化，且并不需要pip.ini有特殊配置。这是在本机生成phar包时，需要开启phar.readonly这个配置。常见的函数如下：

继续我们的分析，一般每个web应用几乎都存在着文件上传功能，几乎都会用到is_file,is_dir,file_exists等函数 接下来外面就来分析源码，老规矩依旧是全局搜索

在这里就不浪费大家时间，找寻触发点直接省略，直接进入利用分析

可以看到这里rmdirr是update控制器里的一个方法，我们可以直接通过url调用该函数，能触发漏洞的原因在于，没写固定前缀，到这里可能有同学会提醒我还有后缀，但在这里可以给大家卖个关子，其实有很大一部分后缀是可以绕过的，这个我们在后面分析。言归正传，之所以要指定前缀就是防止攻击者使用phar协议，进行phar反序列化，到这里我们已经找到了反序列化入口，进行就是如何进行phar文件生成和反序列化漏洞利用