vaeThinkv1.0.1代码执行漏洞挖掘分析

0x01 引言

本文是对一个小众CMS（vaeThink v1.0.1）进行分析、代码执行漏洞挖掘和审计过程的记录，该CMS基于ThinkPHP5开发。作为一名代码审计的入门菜鸟，也希望能够将实践和学习的过程记录和分享，以期能够与大家共同交流进步。

0x02 分析

通过git将项目源码下载到本地，首先对项目源码目录结构进行了解：

www WEB部署目录（或者子目录）
├─app 应用目录
│ ├─common 公共模块目录
│ │ ├─model 公共模型目录
│ ├─admin 后台模块目录
│ │ ├─controller 模块控制器目录
│ │ ├─model 模块模型目录
│ │ ├─validate 模块验证器目录
│ ├─port API接口模块目录
│ │ ├─controller 模块控制器目录
│ │ ├─model 模块模型目录
│ │ ├─validate 模块验证器目录
│ ├─common.php 公共函数文件
│
├─data 数据目录
│ ├─conf 配置目录
│ │ ├─module_name 模块配置目录
│ │ ├─extra 额外配置目录
│ │ ├─command.php 命令行工具配置文件
│ │ ├─config.php 公共配置文件
│ │ ├─route.php 路由配置文件
│ │ ├─tags.php 应用行为扩展定义文件
│ │ └─database.php 数据库配置文件
│ ├─runtime 应用的运行时目录
│ └─install.lock 用于系统鉴定是否完成安装
│
├─public WEB目录（对外访问目录）
│ ├─plugin 插件目录
│ ├─themes 模板文件目录
│ └─admin_themes admin模块模板文件目录
│ ├─index.php 入口文件
│ ├─router.php 快速测试文件
│ └─.htaccess 用于apache的重写
│
├─listenrain 系统核心引擎目录
│ ├─thinkphp ThinkPHP5框架文件目录
│ ├─vae vaeThink框架核心类库目录
│
├─extend 扩展类库目录
├─vendor 第三方类库目录（Composer依赖库）
├─build.php 自动生成定义文件（参考）
├─composer.json composer 定义文件
├─LICENSE.txt 授权说明文件
├─README.md README 文件
├─think 命令行入口文件


得到CMS的项目源码后，不着急进行源码的白盒审计，可以先将CMS部署和运行起来，认识和了解其功能点，同时进行黑盒测试。

该CMS的部署比较简单，只要有LAMP的环境，并且将网站根目录指向public目录即可，接着根据提示安装。安装完成之后，访问该CMS直接出现登录页面：

需要注意的是，一般在登录功能处可能存在SQL注入漏洞，但是本文着重挖掘代码执行漏洞的挖掘，因此其他类型会略过，我们继续通过安装时设置的管理员账号登入后台，进一步了解后台的其他功能点：

一般存在代码执行漏洞的地方，可能在如下这些功能模块：

1、网站配置文件写入
2、缓存cache文件写入
3、日志文件写入
4、文件上传
5、代码执行函数参数可控


从这5点出发，我们继续对该CMS进行挖掘。

0x03 配置、日志和缓存文件

在系统/配置菜单中，存在与网站信息、邮件和短信配置相关的功能页面。在不进行源码审计的情况下，首先查看数据库中的数据表和字段，发现没有存储和这些配置相关的信息，可以猜测这些信息可能直接经过处理后存储在某个配置文件中，经过对项目目录的大致了解，应该是在data/conf下。

我们输入特定的测试数据进行提交，并且通过grep过滤包含特定数据的文件：

欣喜地发现，输入的配置内容写入了data/conf/extra/webconfig.php中，并且同时注意到，输入的配置内容同样写入了日志文件data/runtime/log/201905/1557823231-14.log。

我们继续构造可控内容'];phpinfo();//，可以通过闭合前面的数组逃逸出来：

但是测试发现，可控内容前的return会直接返回，注入的代码并没有被执行。另外，注意一下配置文件的路径可以发现，data目录不是一个可以直接访问到的网站路径，除非能够配合其他的路径穿越或者文件包含漏洞才有更进一步的可能，这里的日志文件也是同理。

注意到data目录下还存在cache和temp目录，其中存储了一些缓存文件

除了和上面配置、日志文件存在同样的限制，这些缓存文件还通过exit()进行了安全处理：

0x04 文件上传

几条路暂时被堵死了不要慌，继续观察CMS的其他功能点。在管理员的修改个人信息页面，发现存在一个头像上传功能，简单选择一个t.php上传，页面提示文件类型错误，不排除这只是一个前端校验的可能，我们通过抓包修改文件后缀继续进行上传：

测试后发现这里的上传点果然只对文件后缀进行了前端校验，直接了当上传.php后缀的文件：

0x05 代码执行函数参数可控

该CMS除了头像功能点直接暴力的文件上传之外（过于简单。。），还有没有可能存在其他角度的漏洞点呢？比如用户输入可以直接作为某些代码执行函数的参数，导致任意代码执行。怀着疑问我们继续对CMS开始进一步的挖掘，PHPStorm启动！XDebug配置！

在PHP中常见的代码执行函数有eval、system等等，通过command+shift+f进行全局搜索这些函数名关键词来找到切入点。经过一番排查，最终定位到了一个比较可疑的地方listenrain/vae/lib/Auth.php第194行中的getAuthList函数：

我们继续从此处逆向回溯分析，查看该污点是否可被用户控制。

在eval函数中的参数存在一个变量$command：

该变量来自上一行的$rule['condition']，并且替换了{(w*?)}，但是没有进行其他的过滤操作：

$command = preg_replace('/{(w*?)}/', '$user['\1']', $rule['condition']);

$rule是从186行 $rules = Db::name($this->config['auth_rule'])->where($map)->field('condition,name')->select();数据库中查询得到的数据的一部分。从作者的注释可以看到，读取的是用户组所有权限规则。

我们通过分析和函数名可以大致对该函数作用有了解，是对通过用户id获得用户组权限，并且返回权限列表。

继续查看getAuthList的调用情况，是在check函数中：

回溯check函数，发现调用在：

到此，基本可以确定在管理员访问鉴权功能模块中会触发此流程。接着下断点进行动态调试，便于对变量值的查看，我们选择菜单中的任何一个选项进行访问，执行流程会经过上述我们分析过的检查函数中：

分析后可以确定，数据库中用户拥有的权限对应的规则的condition字段将会作为eval()的参数被执行

接着继续确定数据表中的condition字段是否为用户可控，分析后可以发现，在后台的系统/节点 http://127.0.0.1/index.php/admin/rule/index.html页面中存在对该数据表的操作功能，而附加规则对应数据表中的condition字段：

尝试修改附加规则内容后，访问任意一个菜单中的页面，并动态调试观察:

可以看到，可控内容没有经过过滤，成功触发该污点：

0x06 结尾

本文针对代码执行漏洞，从配置文件、日志文件和缓存文件的写入，文件上传以及函数执行参数可控的角度对vaeThink v1.0.1进行简单地挖掘和分析。全文内容比较简单，目的是记录和分享交流，请大佬轻喷。

最后，感谢阅读！