前言

这两天挑了款 cms 审计了一下。还是 tcl ，没审计出什么很厉害的洞。分享一下挖的思路

漏洞分析

找了一圈关键字，找到一处：

后台的删除幻灯片处：

我们看到有一句：

@unlink(APP_PATH . '..'. DS . $yfile);

而 $yfile 是哪里来的呢？

$yfile = str_replace($yuming['option_value'],'',$slide['slide_pic']);

$slide 是从数据库里查出来的。

临时跳一下，跳到 添加幻灯片 处。看看我们的 slide_pic 是怎么加进去的。

可以看到是获取了 slideshow 这个参数。这里并没有任何检查

我们再跳回 removeSlide 这个函数。

我们会发现在 unlink 前有个 if：

if(!empty($yfile) && $this->isLegalPicture($slide['slide_pic'])){

没错，isLegalPicture 这个函数就是检查函数，这个函数大概做了两件事：

判断文件名后缀是否为图片（白名单
判断文件名是否带有 /data/

这里第二个条件，是要 dirname 含有 /data/，不能是 /data/a.jpg ，但可以是 /data/a/a.jpg

现在知道变量来源了，我们再精简一下代码，把关键代码剪出来：

$yfile = str_replace($yuming['option_value'],'',$slide['slide_pic']);
if($this->isLegalPicture($slide['slide_pic'])){
@unlink(APP_PATH . '..'. DS . $yfile);
}

没错，这里最大的问题就是 isLegalPicture 的传参和 unlink 的传参不一致。

我们会发现上面有个 str_replace，他会把 $yuming['option_value'] 替换成 空

那么我能不能让 $yuming['option_value'] 变成一些特殊的值呢？

那么这个东西是什么呢？这玩意儿其实就是。

这里修改虽然前端有限制，但是挡不住我们万能的 bp（后端没有限制）。

现在我们就可以想想怎么利用了：

修改幻灯片为 /data/b/111.jpgapplication/install.lock/data/b/111.jpg
修改 站点域名 为 /data/b/111.jpg
删除指定幻灯片

删除时把 /data/b/111.jpg 替换为空，就是 application/install.lock 了。

漏洞复现

首先登陆后台，输入账号密码后可能会显示这个：

但是这里过滤不严，我们可以直接访问：/admin/Index/web.html。

（首先我们要先抓到修改幻灯片和删除幻灯片的包，因为我们修改了站点域名之后 js 和 css 会直接加载不出来。。。）

抓 系统设置 => 网站信息 的包，然后 domain 参数改成：/data/b/111.jpg

此时的 options 表：

然后修改幻灯片的数据包中，把 slideshow 改为:/data/b/111.jpgapplication/install.lock/data/b/111.jpg

用刚刚抓到的删除包 repeater 一次就好了：

这时候我们再看的 application 目录就已经删掉了。但是如果我们想写 shell 我们还得把 application/.htaccess 删掉。

我们把 id=2 的幻灯片改成图片：/data/b/111.jpgapplication/.htaccess/data/b/111.jpg

这里就不截图了。

删除之后：

然后我们就可以重新安装了：

这里我们不知道服务器的 mysql 账号密码的话，可能需要将 数据库服务器 的地址修改成网络上的，也可以是自己的 vps 。
然后把数据库名修改成：',eval($_GET[1]),'
其他的正常填，下一步。。

看看 application/database.php 文件：

总结

审了很久，也许是经验不太够（太菜），只审出了一个 laji 洞。

总结一下这个洞，大概就是传递的参数不同导致的，实际开发中还是不能太粗心，保证参数的统一。