代码审计之seacms v6.45 前台Getshell 复现分析

1.环境：

php5.5.38+apache+seacms v6.45

seacms目录结构：

│─admin //后台管理目录
│ │─coplugins //已停用目录
│ │─ebak //帝国备份王数据备份
│ │─editor //编辑器
│ │─img //后台静态文件
│ │─js //后台js文件
│ │─templets //后台模板文件
│─article //文章内容页
│─articlelist //文章列表页
│─comment //评论
│ │─api //评论接口文件
│ │─images //评论静态文件
│ │─js //评论js文件
│─data //配置数据及缓存文件
│ │─admin //后台配置保存
│ │─cache //缓存
│ │─mark //水印
│ │─sessions //sessions文件
│─detail //视频内容页
│─include //核心文件
│ │─crons //定时任务配置
│ │─data //静态文件
│ │─inc //扩展文件
│ │─webscan //360安全监测模块
│─install //安装模块
│ │─images //安装模块静态文件
│ │─templates //安装模块模板
│─js //js文件
│ │─ads //默认广告目录
│ │─player //播放器目录
│─list //视频列表页
│─news //文章首页
│─pic //静态文件
│ │─faces //表情图像
│ │─member //会员模块界面
│ │─slide //旧版Flash幻灯片
│ │─zt //专题静态文件
│─templets //模板目录
│─topic //专题内容页
│─topiclist //专题列表页
│─uploads //上传文件目录
│─video //视频播放页
│─weixin //微信接口目录
└─index.php //首页文件

2.利用代码

poc1

http://seacms.test/search.php
POST:
searchtype=5&order=}{end if} {if:1)phpinfo();if(1}{end if}

poc2：

POST:
searchtype=5&order=}{end if}{if:1)$_POST[func]($_POST[cmd]);//}{end if}&func=system&cmd=whoami
searchtype=5&order=}{end if}{if:1)$_POST[func]($_POST[cmd]);if(1}{end if}&func=system&cmd=whoami

3.执行效果

4.漏洞分析

 

漏洞产生链如上图所示，在search.php的212行下断点，由于在此处产生了parseIf()函数的调用，而且最终的命令执行是发生在此函数中，用payload打一次，将停在此处，进入此函数进行分析

如上图所示，其中buildregx函数是构建php的原生正则表达式

接下来使用$labelRule规则进行preg_match_all匹配出了全部知足的结果，并放在$iar中，我猜想这里class顶一个两个css样式，经过if条件来调整按钮样式的

经过这4行代码将$iar中的每条记录分为条件，以及条件体

接着判断正则$labelRule2所表示的字符串是否包含于条件体中，默认是不包含的，而且$labelRule3中包含的{else}字符串是出如今条件体中的，因此进入循环，此时将条件体又分为两块，

分别表明两种不一样的css样式，接着就是触发漏洞的核心，在这里也发现了eval函数的调用，用于代码执行的经典函数

如上图所示，将$strif变量与if条件进行了拼接，那么此处是否存在代码注入的状况？的确如此，此时能够看看$strif的值

其中第95条就包含有咱们的payload，那么此时将payload和if条件进行拼接能够获得：

if(1)phpinfo();if(1)

此时成功闭合了php语句，而且跟后面的$ifFlag条件体也成功闭合了，因此可以成功进行代码执行！！！代码注入真刺激~，到此已经实现RCE，那么想一想为啥会形成这样的漏洞，我向上看看变量是如何传递过来的，

 

parse函数就是在main.class.php这个类文件中定义的处理if代码块的函数，其入口参数为$content,那么回到调用parseIf函数的地方，也就是search.php，由于咱们漏洞文件也在该文件，那么咱们POST传递过来的payload最终会传递到content而后再进入到parseIf函数进行处理，而该处调用又是存在于echoPageSearch()函数中，那么回到该函数入口处，在其上方发现了对其的调用，如今在此文件全局搜索如下POST字符串

如上图所示，没有搜索到POST，那么有可能包含在common.php中，进去看看

正与咱们所猜想的同样，此时能够在注释中发现，其经过一段循环将POST中的值注册为变量了，而且咱们提交的标量里不能包含cfg_和GLOVALS字符串，而且在COOKIE中不可以设置，这里是为了防止变量覆盖

接下来还调用了_RunMagicQuotes()函数对变量值进行过滤，实际上进行了一个addslashes()函数的操做，并不影响咱们实际所用的payload

能够从上图看到传递进来的变量直接注册为内部的变量了，而且变量内容没有发生变化，那么说明都是咱们能够控制的，由于最后parse处理的变量是$content，那么咱们须要弄清$order是如何赋值到$content中的，

再次文件中搜索$order的使用

能够找到4处调用，第一处是在函数内部global来引用，第二处又将$order赋值给$orderStr,可是这样赋值没有影响到$content变量，所以看最后一处调用

如上图所示，将$content中的{searchpage:ordername}部分替换为了$order变量的值，为了更清楚的看看$content的内容是如何变化的，咱们能够在158行和160行处下断点，从新执行一次payload，此时能够在此断点处查看$content的值，并将替换先后的$content值进行对比，能够看到str_replace()函数将进行3处替换

即在此处完成了payload对$content变量的注入，以后在最终调用parseIf()函数处理$content变量以前，又对$content的内容进行了屡次替换，可是并无影响到咱们的payload，接下来看看程序是如何解析出来咱们的paylaod的

上面已经说过程序是利用

{if:(.*?)}(.*?){end if}

这一串正则来对$content变量进行匹配的，那么此时对于咱们注入payload的部分，最终是eval()中包含$strIf变量，那么因为是贪婪匹配，因此首先将会匹配到第一部分{if:"}{end if} 将“匹配出来做为一部分，而后下一次匹配再匹配到1)phpinfo();if(1做为另外一次匹配的部分

能够从$iar变量的值中验证咱们的推理是正确的，这里存在3处相同的匹配是由于以前$order对$content进行了3次payload注入，这样的构造的确很巧妙，首先1)phpinfo();if(1这一部分要闭合后面eval部分，而后再要知足前面正则匹配的逻辑可以把payload完整匹配出来，

这可能也是开发人员没有想到的，以后拼接的方法上面已经讲了，漏洞的整个分析流程到此结束。

5.修复方法：

在64行添加

$order = ($order == "commend" || $order == "time" || $order == "hit") ? $order : "";