vaeThink v1.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();数据库中查询得到的数据的一部分。从作者的注释可以看到，读取的是用户组所有权限规则。