* 本文属CE安全网投稿文章 未经允许 不得转载 ! 作者ID:daomeng *
审计该 CMS 中的内容只涉及到前台,后台中有存安全问题但对我来说没什么意义,所以没有过多的关注,感兴趣的朋友可以自己动动手。
因为本身已经做了一定的安全加固,本次审计并没挖掘出高危漏洞。但存在几个可以对网站造成危害的安全风险,在此仅做为思路分享给大家参考学习。
框架是这个 CMS 自写的,里面处理接收参数均在 ./framework/lib/util/request_class.php
文件中,比如:
//同时处理$_GET $_POST public static function args() { $num = func_num_args(); $args = func_get_args(); if($num==1) { ...省略... } else if($num>=2) { ...省略... } else { return $_POST+$_GET; } }
参数及过滤则放在 ./framework/lib/util/filter_class.php
中,所以在阅读代码是可以看到接收参数是这样的:
Filter::int(Req::args('address_id'))
接收参数 address_id
,并用正则至获取数字
Filter::text(Req::args('invoice_title'))
接收参数 invoice_title
,并用 htmlpurifier 扩展清洗 xss 注入
Filter::sql(Req::post('email'))
接收参数 email
,并用正则过滤恶意 sql
碰到这种就可以直接放弃了,可以看看代码:
public static function int($str) { $number = preg_replace("/[^\d]/", "", $str); $number = ($number=='')?0:$number; return $number; } public static function sql($str) { if(class_exists('TPdo') && class_exists('pdo')){ }else{ if (!get_magic_quotes_gpc()){ $str = addslashes($str); }else{ $str = preg_replace('/(?<!\\\\)(\"|\')/i','\\\\$1',$str); } } $str = preg_replace('/([^a-z]+)(select|insert|update|delete|union|into|load_file|outfile|and|or|sleep|tiny_)/i', ' $2', $str); return $str; }
在官网示例中测试成功
http://shop.tinyrise.org/index.php?con=simple&act=address_save&accept_name=1&mobile=13888888888&phone=13888888888&province=110000&
看代码:
public function address_save($redirect=null){ $rules = array('zip:zip:邮政编码格式不正确!','addr:required:内容不能为空!','accept_name:required:收货人姓名不能为空!,mobile:mobi:手机格式不正确!,phone:phone:电话格式不正确','province:[1-9]\d*:选择地区必需完成','city:[1-9]\d*:选择地区必需完成','county:[1-9]\d*:选择地区必需完成'); $info = Validator::check($rules); if(!is_array($info) && $info==true) { ...省略... } else{ $this->assign("msg",array("error",$info['msg'])); $this->redirect("address_other",false,Req::args()); } }
问题出在 Req::args()
。当参数校验失败后页面会进行重定向,并将接收到的参数传递至视图中。
视图中原样输出 zip
参数内容:
./runtime/default/simple/address_other.php <label class="caption">邮政编码:</label><input class="field" type="text" name="zip" pattern="zip" value="<?php echo isset($zip)?$zip:"";?>" alt="邮政编码错误">
为什么说疑似注入呢,因为通过分析这个方法确实将恶意代码注入进了 SQL 查询。但因为本人注入战5渣,技术比较烂没用找到正确的利用姿势,所以放弃了。
// ./protected/classes/Common.php //自动登录时的用户信息 static function autoLoginUserInfo() { $cookie = new Cookie(); $cookie->setSafeCode(Tiny::app()->getSafeCode()); $autologin = $cookie->get('autologin'); $obj = null; if($autologin!=null){ ...省略... }else{ $weixin_openid = Cookie::get('weixin_openid'); if($weixin_openid != null){ $model = new Model('oauth_user'); // 关注点 $weixin_openid 参数 $oauth_user = $model->where("oauth_type='WeixinOAuth' and open_id='$weixin_openid'")->find(); if($oauth_user && $oauth_user['user_id']!=''){ ...省略... } } } return $obj; }
从上面的代码可以看到, $weixin_openid
参数是从 cookie
中获取。我们看看 Cookie::get()
函数:
// ./framework/lib/util/cookie_class.php // 取得cookie值 public static function get($name) { // 这里的if是要 $_COOKIE['safecode'] 中的参数是 1 即可。 if(self::checkSafe()==1) { // $per = 'Tiny_'; if(isset($_COOKIE[self::$per.$name])) { $cryptCookie = $_COOKIE[self::$per.$name]; $cookie= Crypt::decode($cryptCookie,self::getSafeCode()); $tem = substr($cookie,0,10); if(preg_match('/^[Oa]:\d+:.*/',$tem)) $cookie = unserialize($cookie); return $cookie; } return null; } if(self::checkSafe()==0) self::clear($name);// Tiny::msg('非法窃取COOKIE,系统将终止工作!',0); else return null; }
可以看到,这里用到了 Crypt
类对值进行算法解密处理,最终调用反序列化函数后将值传递给 $cookie
。
这里只要找到加密方式,并对恶意代码进行一次处理随后传递至 cookie
中的 Tiny_autologin
参数即可。
所以我们构造一段代码,将 Cookie::set()
函数里面的值返回出来即可。
// ./framework/lib/util/cookie_class.php public static function set($name,$value='',$time='86400',$path='/',$domain=null) { if($time<=0) $time = -3600; else $time = time() + $time; setCookie('safecode',self::cookieId(),$time,$path,$domain); if(is_array($value) || is_object($value)) $value=serialize($value); $value = Crypt::encode($value,self::getSafeCode()); //setCookie(self::$per.$name,$value,$time,$path,$domain); // 注释该行 return $value; } // ./protected/classes/Common.php //自动登录时的用户信息 static function autoLoginUserInfo() { $str = '\' or 1=1-- '; $poc = Cookie::set('weixin_openid',$str); echo $poc;exit(); /*...后面的代码先注释或忽略...*/ }
输出加密后的字符串:ddb494c3baUwYICFJVAwJSBVUACQFWB1MGVQcGVlUCAlhUAApaDAUQF1tARQkLU0sVFQ
现在我们用它来测试试试看,是否能被正确解密:
好了,我们去除调试用的 var_dump($weixin_openid);exit();
,看看是否被带入到SQL中:
至于后面怎么利用,请原来我这个辣鸡水平低~ 咳咳~
你在查看源代码的时候后会发现,这个 cms 大量使用了序列化和反序列函数,如果你登录了后台,并且想留个后面什么的,用序列化蛮方便的。
当然,前台我已基本上分析完了,有反序列化的地方但并不能形成漏洞。
很失望。
该 CMS 对上传已经做了很好的安全限制,但它支持用户上传 gif
文件,结合文章中所述的 POC
测试此处风险确实存在。
/** * 生成图像 * * @access private * @param mixed $type 图片类型 * @param mixed $filename 文件名 * @return mixed */ private function createImage($type,$filename) { //1 = GIF,2 = JPG,3 = PNG switch($type) { case 1: $im = imageCreateFromGif($filename);break; // 代码运行至此处,存在DOS风险 case 2: $im = imageCreateFromJpeg($filename);break; case 3: $im = imageCreateFromPng($filename);break; default: { $im = imageCreateFromJpeg($filename);break; } } return $im; }
可以看到, poc.gif
图片上传后,导致超出了服务最大等待时间,使页面 504
。
不使用 imagecreatefromgif()
处理 .gif
图片,或升级最新版本可以可以防御。
详细参看:
http://blog.orange.tw/2018/01/php-cve-2018-5711-hanging-websites-by.html
后台里面的问题我就那这一个出来说吧:
如图中所示,这个用户的金额是 0.00
,我们先登录后台管理员账号,并给该账号充值 200
。
找出充值成功的请求,生成 csrf
攻击重放页面:
好,现在我们用浏览器打开保存的HTML页面,打开后点击确认按钮可以看到如下提示:
回到账号充值页面,看看现在这个账号金额是多少:
思考一下
单独拿这个问题提出来说,是因为这里可以形成一个组合漏洞。
上面有个反射 XSS 漏洞,如果恶意用户伪造 javascript 脚本对账号进行充值,随后去诱导客服进行点击。
当当当~ 脑补攻击+1。
后台对用户进行充值时,没有加入表单来源认证,未区分本次请求是管理点发出,还是恶意用户伪造。
* 本文属CE安全网投稿文章 未经允许 不得转载 ! 作者ID:daomeng *