漏洞分析
uc_client\model\base.php 37行
跟进
继续跟进,可以看到此处进行了mysql查询,此处的UC_APPID查找其来源
ctrl+左键点进去看一下
发现是在配置文件里面写着的
全局搜索一下UC_APPID
发现是这样写进去的,首先在配置文件里面查找原先的define(‘UC_APPID’, …);然后用"define(‘UC_APPID’, ‘".$settingnew[‘uc’][‘appid’]."’)"进行替换,UC_APPID的值为$settingnew[‘uc’][‘appid’]
向上找$settingnew[‘uc’][‘appid’]的来源,发现参数可控,且只是对内容进行了简单的addslashes
那么我们只需要将payload赋值给$settingnew[‘uc’][‘appid’],其会被addslashes后(2280行)存入配置文件(2295行),然后当mysql查询时,从配置文件查询出来的还是原来的字符串,原因如下
转义一次的字符串被写入文件中,在PHP解析时就是没有转义过的原始内容 造成了二次注入的产生
比如
<?php
define('UC_APPID', 'sadsadsadasd\'');
printf(UC_APPID);
结果如下
漏洞复现
进入后台
抓包,此处写入payload
发包
发现成功写入
附
我们可以看到此时配置文件中为这样
当mysql查询时,要获取配置文件中UC_APPID的值,而该值只被转义过一次,所以在PHP解析时就是没有转义过的原始内容 造成了二次注入的产生
如下是漏洞触发点,简单调试一下
再次发包,发现UC_APPID的值确实为最原始的值,没有被转义,造成了二次注入
修复建议
对$settingnew[‘uc’][‘appid’]在进行一次addslashes
参考链接
https://www.hacking8.com/bug-web/Discuz/Discuz!-X-系列全版本-后台Sql注入漏洞.html
|