从escapeshellcmd bypass说起到宽字节注入

发表于 2015-03-01 | 分类于 mysql | | 阅读次数

1 php 多字节绕过escapeshellcmd

escapeshellcmd()对shell元字符过滤加反斜杠；
反斜线（\）会在以下字符之前插入： #&;`|*?~<>^()[]{}$\, \x0A 和 \xFF，但在php5.2.5及之前存在通过输入多字节绕过escapeshellcmd的问题。5.2.6 已经修复了该问题。

执行 escapeshellcmd(“echo “.chr(0xc0).”;id”);
加上反斜杠之后，也就是echo \xc0\x5c;id,在中文环境中\xc0\x5c是会被认为是gbk字符的。

>>> hex(ord('\\'))
'0x5c'
>>> s='\xc0\x5c'
>>> print s.decode('gbk').encode('utf8')
繺
>>> s.decode('gbk').encode('utf8')
'\xe7\xb9\xba'

\被吃掉之后于是就变成了echo 繺;id 了。
gbk是宽字节，两个字节，gbk字符范围：8140-FEFE，首字节在81-FE直接，尾字节在40-FE之间，显然5C在尾字节中。考虑0xbf;id,escape之后就变成了0xbf5c;id，0xbf5c是一个合法的GBK编码，那就变成了[0xbf5c];id了。而utf8表示中文一般三个字节。
同样受影响的还有escapeshellarg()，源码中的处理是一个字节一个字节来处理的。这种漏洞应该有一定普遍性，在当时来说。下面我们看下修复的源代码：

char *php_escape_shell_cmd(char *str) {
     register int x, y, l;
     char *cmd;
     char *p = NULL;
    
     TSRMLS_FETCH();
     l = strlen(str);
     cmd = safe_emalloc(2, l, 1); //申请了2倍字符
    
     for (x = 0, y = 0; x < l; x++) {
          int mb_len = php_mblen(str + x, (l - x));
          //这一段是5.2.6新加的，就是在处理多字节符号的时候，当多字节字符小于0的时候不处理，大于1的时候跳过，等于1的时候执行过滤动作
          /* skip non-valid multibyte characters */
          if (mb_len < 0) {
               continue;
          } else if (mb_len > 1) {
               memcpy(cmd + y, str + x, mb_len);
               y += mb_len;
               x += mb_len - 1;
               continue;
          }
          switch (str[x]) {
               case '"':
               case '\'':
#ifndef PHP_WIN32
                    if (!p && (p = memchr(str + x + 1, str[x], l - x - 1))) {
                         /* noop */
                    } else if (p && *p == str[x]) {
                         p = NULL;
                    } else {
                         cmd[y++] = '\\';
                    }
                    cmd[y++] = str[x];
                    break;
#endif
               case '#': /* This is character-set independent */
               case '&':
               case ';':
               case '`':
               case '|':
               case '*':
               case '?':
               case '~':
               case '<':
               case '>':
               case '^':
               case '(':
               case ')':
               case '[':
               case ']':
               case '{':
               case '}':
               case '$':
               case '\\':
               case '\x0A': /* excluding these two */
               case '\xFF':
#ifdef PHP_WIN32
               /* since Windows does not allow us to escape these chars, just remove them */
               case '%':
                    cmd[y++] = ' ';
                    break;
#endif
                    cmd[y++] = '\\';
                    /* fall-through */
               default:
                    cmd[y++] = str[x];
          }
     }
     cmd[y] = '\0';
     return cmd;
}

这个bypass已经成为过去时了，但是还是有很大的借鉴意义，就是宽字节注入，这种情况不仅仅发生命令注入时，更多的时候在sql注入，下面来分析一下宽字节注入如下三种情况，都是由于宽字节的问题导致的。

2 宽字节sql注入

1，一种情况 iconv转换，addslashes之后从gbk转到utf8

$user = $_POST[ 'username' ];
$user = addslashes($user);
$user = iconv("gbk", 'utf8', $user);
$pass = $_POST[ 'password' ];
$pass = md5( $pass );
$qry = "SELECT * FROM `users` WHERE user='$user' AND password='$pass';";
print_r($qry);
$result = @mysql_query($qry) or die('<pre>' . mysql_error() . '</pre>' );
var_dump($result);

处理过程如下：
%bf%27—-（addslashes）->%bf%5c%27—–（utf8）—->縗’ 这样单引号就放出来了，大体流程是%bf%27经过addslashes之后变成了%bf%5c%27，再经过iconv从gbk转换为utf8的时候，变成了%e7%b8%97%27，也就是縗’。利用的前提是设置了set names utf8。

2，在php中使用mysql_query(‘set names gbk’),指定了客户端，连接层，结果为gbk编码。构造数据%bf%27，过程和第一种情况类似
%bf%27—(addslashes)–>%bf%5c%27—(set names gbk)—>縗’

3，iconv转换从utf8到gbk，set names字符集为gbk，构造数据如下%e9%8c%a6带入反斜杠\,注释掉单引号
大体数据流程：%e9%8c%a6—–(utf8)—-%e5%5c—-(addslashes)—>%e5%5c%5c

>>> s = '\xe9\x8c\xa6'
>>> s.decode('utf8')
u'\u9326'
>>> s.decode('utf8').encode('gbk')
'\xe5\\'

总之一条，都是打的%5c的注意，要么转义后转utf8吃掉%5c,要么转utf8后再转义放出%5c

参考：
http://seclists.org/bugtraq/2008/May/61
http://www.sektioneins.de/en/advisories/advisory-032008-php-multibyte-shell-command-escaping-bypass-vulnerability.html
http://php.net/ChangeLog-5.php
http://php.net/releases/

Php比较操作符带来的安全问题

发表于 2015-01-01 | 分类于 Php | | 阅读次数

1 比较操作符

php的比较操作符有==（等于）松散比较，===（完全等于）严格比较，这里面就会引入很多有意思的问题。在松散比较的时候，php会将他们的类型统一，比如说字符到数字，非bool类型转换成bool类型，为了避免意想不到的运行效果，应该使用严格比较。如下是php manual上的比较运算符表：

例子	    名称	    结果
$a == $b	等于	    TRUE，如果类型转换后 $a 等于 $b。
$a === $b	全等	    TRUE，如果 $a 等于 $b，并且它们的类型也相同。
$a != $b	不等	    TRUE，如果类型转换后 $a 不等于 $b。
$a <> $b	不等	    TRUE，如果类型转换后 $a 不等于 $b。
$a !== $b	不全等	    TRUE，如果 $a 不等于 $b，或者它们的类型不同。
$a < $b	小与	    TRUE，如果 $a 严格小于 $b。
$a > $b	大于	    TRUE，如果 $a 严格大于 $b。
$a <= $b	小于等于	TRUE，如果 $a 小于或者等于 $b。
$a >= $b	大于等于	TRUE，如果 $a 大于或者等于 $b。

2 安全问题

2.1 hash比较缺陷

php在处理hash字符串的时候会用到!=,==来进行hash比较，如果hash值以0e开头，后边都是数字，再与数字比较，就会被解释成0*10^n还是为0，就会被判断相等，绕过登录环节。

root@kali:~/tool# php -r 'var_dump("00e0345" == "0");var_dump("0e123456789"=="0");var_dump("0e1234abc"=="0");'
bool(true)
bool(true)
bool(false)

当全是数字的时候，宽松的比较会执行尽力模式，如0e12345678会被解释成0*10^12345678,除了e不全是数字的时候就不会相等，这能从var_dump("0e1234abc"=="0")可以看出来。

2.2 bool 欺骗

当存在json_decode和unserialize的时候，部分结构会被解释成bool类型，也会造成欺骗。json_decode示例代码：

$json_str = '{"user":true,"pass":true}';
$data = json_decode($json_str,true);
if ($data['user'] == 'admin' && $data['pass']=='secirity')
{
    print_r('logined in as bool'."\n");
}

运行结果：

1 2	root@kali:/var/www# php /root/php/hash.php logined in as bool

unserialize示例代码：

$unserialize_str = 'a:2:{s:4:"user";b:1;s:4:"pass";b:1;}';
$data_unserialize = unserialize($unserialize_str);
if ($data_unserialize['user'] == 'admin' && $data_unserialize['pass']=='secirity')
{
    print_r('logined in unserialize'."\n");
}

运行结果如下：

1 2	root@kali:/var/www# php /root/php/hash.php logined in unserialize

2.3 数字转换欺骗

$user_id = ($_POST['user_id']);
 if ($user_id == "1")
 {
     $user_id = (int)($user_id);
     #$user_id = intval($user_id);
     $qry = "SELECT * FROM `users` WHERE user_id='$user_id';";
 }
 $result = mysql_query($qry) or die('<pre>' . mysql_error() . '</pre>' );
 print_r(mysql_fetch_row($result));

将user_id=0.999999999999999999999发送出去得到结果如下：

Array
(
    [0] => 0
    [1] => lxx'
    [2] => 
    [3] => 
    [4] => 
    [5] => 
)

本来是要查询user_id的数据，结果却是user_id=0的数据。int和intval在转换数字的时候都是就低的，再如下代码:

if ($_POST['uid'] != 1) {
 $res = $db->query("SELECT * FROM user WHERE uid=%d", (int)$_POST['uid']);
 mail(...);
} else {
 die("Cannot reset password of admin");
}

假如传入1.1，就绕过了$_POST[‘uid’]！=1的判断，就能对uid=1的用户进行操作了。另外intval还有个尽力模式，就是转换所有数字直到遇到非数字为止，如果采用:

if (intval($qq) === '123456')
{
    $db->query("select * from user where qq = $qq")
}

攻击者传入123456 union select version()进行攻击。

2.4 PHP5.4.4 特殊情况

这个版本的php的一个修改导致两个数字型字符溢出导致比较相等

1 2	$ php -r 'var_dump("61529519452809720693702583126814" == "61529519452809720000000000000000");' bool(true)

3 题外话：

同样有类似问题的还有php strcmp函数,manual上是这么解释的，int strcmp ( string $str1 , string $str2 ),str1是第一个字符串，str2是第二个字符串，如果str1小于str2，返回<0,如果str1>str2,返回>0,两者相等返回0，假如str2为一个array呢？

$_GET['key'] = array();
$key = "llocdpocuzion5dcp2bindhspiccy";
$flag = strcmp($key, $_GET['key']);
if ($flag == 0) {
    print "Welcome!";
} else {
    print "Bad key!";
}

运行结果：

1
2
3

root@kali:~/php# php strcmp.php
PHP Warning:  strcmp() expects parameter 2 to be string, array given in /root/php/strcmp.php on line 13
Welcome!

参考：
1，http://phpsadness.com/sad/47
2，http://php.net/language.operators.comparison
3，http://indico.cern.ch/event/241705/material/slides/0.pdf

廖新喜

分享些安全编码，漏洞分析

RSS

GitHub Twitter Weibo