74CMS漏洞打包(从老博客转)
引子
这套CMS是上个月中做的审计，总共找到几个后台漏洞，可后台getshell，一个逻辑漏洞可任意发短信，还有一个前台注入漏洞。不过发到了某平台上之后,审核又要求我提交利用的poc，所以懒得发去了，就这里发来，刚才看了下最新版，已经修复了。版本是74cms_v3.6_20150902。
详情
逻辑漏洞
第一个逻辑漏洞是短信发送处的问题，在ajax_user.php文件中，原代码片段如下：
$mobile=trim($_POST['mobile']);
$sms_type=$_POST['sms_type']?$_POST['sms_type']:"reg";
if (empty($mobile) || !preg_match("/^(13|15|14|17|18)\d{9}$/",$mobile))
{
exit("手机号错误");
}
$rand=mt_rand(100000, 999999);
switch ($sms_type) {
case 'reg': $sms_str="您正在注册{$_CFG['site_name']}的会员,手机验证码为:{$rand},此验证码有效期为10分钟"; break;
case 'getpass': $sms_str="您正在找回{$_CFG['site_name']}的会员密码,手机验证码为:{$rand},此验证码有效期为10分钟"; break;
}
if($_SESSION['verify_mobile']==$mobile && time()<$_SESSION['send_time']+180)
{
exit("180秒内仅能获取一次短信验证码,请稍后重试");
}
else {
$r=send_sms($mobile,$sms_str);
}
if ($r=="success"){
$_SESSION['mobile_rand']=substr(md5($rand), 8,16); $_SESSION['send_time']=time(); $_SESSION['verify_mobile']=$mobile; exit("success");
}
else { exit("SMS配置出错，请联系网站管理员"); }
可以看出，这里每次会把这次输入的手机号和session中记录的手机号做验证，如果相同并且时间间隔不够3分钟，那么就会报错，但是这里有一个问题，就是每次输入了手机号后如果成功发送了短信，那么就会覆盖掉session中的手机号，所以我们只需要轮询两个正常的手机号即可越过限制。目前版本已经修复，修复方法也很简单，就是先做一个时间验证即可，不管输入的手机号是多少，发短信的时间间隔不可少于60s，很聪明的fix。
后台还有一个任意文件删除的问题，文件是admin/admin_article.php，这里会删除掉$_GET来的img指向的文件，代码片段如下：
$id=intval($_GET['id']);
$img=$_GET['img'];
$img=str_replace("../","***",$img);
$sql="update ".table('article')." set Small_img='' where id=".$id." LIMIT 1";
$db->query($sql);
@unlink($upfiles_dir.$img);
@unlink($thumb_dir.$img);
看到这里过滤了../，然而在windows下使用..\也是可以的，所以可以任意删除文件。
后台GetShell
后台GetShell的方法不少，这里算是其中一个，而且估计不会在短期内修补，因为算是一个正常的系统功能。
这个GetShell的方法很简单，就是先通过普通会员的头像文件上传，传上来有要执行的代码的图片，后台在包含进来即可。
思路就是这样，那么前台头像上传必须要没有验证上传的文件内容，看代码：
$savePath = "../../data/avatar/100/"; //图片存储路径
$savePathThumb = "../../data/avatar/48/"; //图片存储路径
$savePicName = time();//图片存储名称
$file_src = $savePath.$savePicName."_src.jpg";
$filename150 = $savePath.$savePicName.".jpg";
$filename50 = $savePathThumb.$savePicName.".jpg";
$src=base64_decode($_POST['pic']);
$pic1=base64_decode($_POST['pic1']);
$pic2=base64_decode($_POST['pic2']);
if($src) {
file_put_contents($file_src,$src);
}
file_put_contents($filename150,$pic1);
这里直接fileput_contents了，不过可惜没办法控制文件名，一般来说这里就没啥用了，不过后台的一个任意文件包含就可以用上了。
代码如下：
if (!empty($crons))
{
if (!file_exists(QISHI_ROOT_PATH."include/crons/".$crons['filename']))
{
adminmsg("任务文件 {$crons['filename']} 不存在！",0);
}
require_once(QISHI_ROOT_PATH."include/crons/".$crons['filename']);
adminmsg("执行成功！",2);
}
这个文件是在后台的计划任务管理那里，具体名字我也忘了……但是这个部分的目的是为了帮助管理员执行一些简单的任务，比如统计站点访问的情况或者其他的自定义代码，而这里的问题就是为了方便的做到统计的目的，这套cms在common.inc.php（具体名字忘了）里include了执行计划的代码，也就是说，只要后台添加了一个计划任务，前台即可执行。验证方法也很简单，这里大家可以做一个phpinfo的文件添加到计划任务，再访问下主页即可看见主页上用户登录处出现了phpinfo的结果。
由于这个计划任务的功能是系统功能的一部分，估计不会做啥修复，不过前台头像上传可能做一些修改，但是也不怕，这里其实还有一个问题。就是CSRF，虽然他有一个防CSRF的功能，但是他在后台竟然有个可以关闭CSRF的开关，那么出于方便或者啥的原因，如果管理员关闭了CSRF，那么只要管理员看见了一个精心构造的图片即可getshell（不过这可能性很低）。
SQL注入漏洞
这里只找到了一个前台注入漏洞，不过当时通过了官方DEMO站的验证。
文件位置： ajax_user.php，当act为get_pass_check时，出现了注入，代码如下：
require_once(QISHI_ROOT_PATH.'include/fun_user.php');
$username=$_POST['username']?trim($_POST['username']):exit("false");
if (preg_match("/^\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$/",$username))
{
$usinfo=get_user_inemail($username);
}
elseif (preg_match("/^(13|14|15|18|17)\d{9}$/",$username)) {
$usinfo=get_user_inmobile($username);
}
else
{
$usinfo=get_user_inusername($username);
}
这里没有对$username做过滤，不过全局有addslash，但是这里可以宽字节注入，那么就可以注入了。DEMO站示意图：
正常请求：
这里反回了false，因为不存在这个用户，那么换个payload：
sunrain%df%27%20or%20%df%271%df%27=%df%271
这句话就是简单地or 1=1，如果可以注入，那么应该是返回true的：
当然，这里也是可以出数据的，当时本机测试了，但是没截图。
后台注入还是不少，这里列出两个：
第一处： admin_category.php文件，当act是edit_color_save时，直接执行了如下语句：
$info=get_color_one($_POST['id']);
跟入函数：
function get_color_one($id) {
global $db;
$sql = "select * from ".table('color')." WHERE id=".$id."";
return $db->getone($sql);
}
发现这里没有引号，所以可以注入：
第二处： 在admin_baiduxml.php文件中，当act是setsave时，执行了如下语句：
foreach($_POST as $k => $v) {
!$db->query("UPDATE ".table('baiduxml')." SET value='{$v}' WHERE name='{$k}'")?adminmsg('保存失败', 1):"";
}
所以注入就很明显了：
