|
我们在上一篇文章中学习了DEDECMS的模板标签、模板解析原理，以及通过对模板核心类的Hook Patch来对模板的解析流量的攻击模式检测，达到修复模板类代码执行漏洞的目的 http://www.cnblogs.com/LittleHann/p/3574694.html 通过这段时间的思考，我大概对目前CMS中主流的WEB漏洞进行了大致的分类，这里给朋友们分享一些我的想法:
按 Ctrl+C 复制代码
按 Ctrl+C 复制代码
以上的思路，我会在今后的文章中逐一和大家一起学习，并努力找到一种修复CMS漏洞的底层方法。 这篇文章中，我们一起来学习一下DEDECMS中涉及数据库操作的代码逻辑，并思考怎么在"关键流量节点"上进行Hook Patch，从而达到解决数据库注入类漏洞的目的 本文主要分为以下几个部分: 1. DEDECMS中数据库操作的方法、原理 2. 对数据库查询的SQL流量的攻击模式检测 相关学习资料: http://blog.sina.com.cn/s/blog_56f273130100ul0l.html http://www./dedecmsjiaocheng/201112/22944.html http://hi.baidu.com/tong_jh/item/e64b2a402fed8c11886d107e http://blog./uid-286494-id-2134474.html http://open.taobao.com/doc/detail.htm?spm=0.0.0.0.FytuX1&id=813 1. DEDECMS中数据库操作的方法、原理 在开始学习DEDECMS中数据库操作核心类原理之前，我觉得有两点要先明确一下: 1) DEDECMS严格来说是一个MVC框架，很适合网站开发者在其上进行二次开发 2) 因为DEDE从架构上是一个MVC架构，所以很多的底层操作，例如数据库操作、数据变量清洗、输入变量本地化、模板解析的关键代码都会集中在几个特定的文件中，即OOP的设计思想， 这就为我们针对不同种类的漏洞做流量分析提供很好的基础出发点 既然是基于MVC的二次开发法，我们先编写一些PHP代码，测试一下怎么使用DEDE提供的单例模式(工厂模式)数据库操作类来进行方便的数据库操作 在DEDE网站的根目录(注意，是网站的根目录)下编写test.php E:\wamp\www\dede5.7\test.php  <?php
//引入涉及数据库操作的核心类文件
require_once (dirname(__FILE__) . "/include/common.inc.php");
//遵从单例模式(工厂模式)，直接调用$dsql类进行数据库操作
//IsTable: 判断指定的表是否存在
if($dsql->IsTable('dede_admin'))
{ //1. SetQuery+Execute: 执行一个带返回结果(结果数组)的SQL语句，如SELECT，SHOW等
$sql = "SELECT value FROM dede_sysconfig where varname='cfg_mb_open'";
$dsql->SetQuery($sql);
$dsql->Execute();
//2. ExecuteNoneQuery: 执行一个不返回结果集(数组)的SQL语句，如update,delete,insert等，但它会返回mysql的执行结果，例如插入的row的ID等信息
$sql = " DELETE from `dede_mytag` WHERE aid=1";
$rs = $db->ExecuteNoneQuery($sql);
//3. ExecuteNoneQuery2: 执行一个返回影响记录条数的SQL语句，如update,delete,insert等
$sql = "UPDATE `dede_downloads` SET downloads = downloads+1 WHERE hash='$hash' ";
$rs = $dsql->ExecuteNoneQuery2($sql);
}
?>
以上的3种SQL代码执行方法就是DEDECMS中所有涉及到数据库操作所使用的方法了，其他的方法都是这3种的别名方法，即转接层。 可以看到在MVC模式下进行二次开发是很方便的，这是很多开源框架：CI、TP、主流框架WordPress的常用开发模式接下来，我们来深入源代码，学习一下 require_once (dirname(__FILE__) . "/include/common.inc.php"); 这个文件是DEDECMS中的一个核心配置文件，其中包含了很多方面的内容，我们今后学习变量覆盖类漏洞的攻防还会涉及到这个文件，今天我们重点关注的是这个文件中和数据库有关的代码 /*
引入数据库类
1. 如果在安装时选择了mysqli数据库连接方式，并且当前PHP支持了mysqli模块，则包含dedesqli.class.php文件
2. 默认情况下，包含dedesql.class.php
*/
if ($GLOBALS['cfg_mysql_type'] == 'mysqli' && function_exists("mysqli_init"))
{
require_once(DEDEINC.'/dedesqli.class.php');
}
else
{
require_once(DEDEINC.'/dedesql.class.php');
}
dedesql.class.php和dedesqli.class.php代码逻辑上是一样的，只有在关键函数的最后会加上一个字母"i"，表示是原始mysql函数的改进(improve)版本(当然严格来说，这两个文件在某些细节上还是不一样的，例如dedesql.class.php的ExecuteNoneQuery2函数就存在一个SQL注入漏洞，而dedesqli.class.php则做了有效的过滤，这些问题都是我们在本文需要解决的问题，我们的目标就是找到"所有数据库请求流量的最终的节点"，在这个节点上运用正则规则进行攻击模式检测) require_once(DEDEINC.'/dedesql.class.php'); 这个类非常庞大，里面封装了数据库Meta信息i获取、数据库操作、SQL错误执行信息记录... 我们逐一来学习一下: /*
在工程所有文件中均不需要单独初始化这个类，可直接用 $dsql 或 $db 进行操作
为了防止错误，操作完后不必关闭数据库
*/
$dsql = $db = new DedeSql(FALSE);
//用外部定义的变量初始类，并连接数据库
function __construct($pconnect=FALSE,$nconnect=FALSE)
{
//标识是否关闭数据库
$this->isClose = FALSE;
//标识是否开启安全检查
$this->safeCheck = TRUE;
//标识是否已经存在先前的数据库连接资源标识符(默认为FALSE)
$this->pconnect = $pconnect;
//标识是否需要重新进行连接(默认为FALSE)
if($nconnect)
{
//如果需要重新进行连接，调用Init进行初始化
$this->Init($pconnect);
}
}
function Init($pconnect=FALSE)
{
$this->linkID = 0;
/*
1. 这里是一个关键，程序"信任"了来自全局变量$GLOBALS中和数据库配置信息有关的数据，用以之后进行数据库连接
2. 利用全局变量覆盖+数据库连接方向劫持的绕过漏洞就是源自于这个不太安全的步骤
3. 个人觉得，这种关键信息不能从内存中去提取，应该直接从配置文件中去读取会比较安全一点
4. 另外，完全可以使用持久单例模式，一次数据库连接完成之后，之后的请求就可以复用这个连接标识符，不用再重复连接、关闭了
*/
$this->dbHost = $GLOBALS['cfg_dbhost'];
$this->dbUser = $GLOBALS['cfg_dbuser'];
$this->dbPwd = $GLOBALS['cfg_dbpwd'];
$this->dbName = $GLOBALS['cfg_dbname'];
$this->dbPrefix = $GLOBALS['cfg_dbprefix'];
$this->result["me"] = 0;
//连接数据库
$this->Open($pconnect);
}
以上就是我们在inlcude这个common.inc.php后，程序进行的数据库连接初始化工作，之后，我们就可以方便地在程序中调用 从某种程序上来说，这实现了一个工厂模式(虽然这样说可能不太准确)，但是这极大的方便了我们在DEDE的框架内进行二次开发确实不争的事实，理解了这种思想对我们理解CI、TP这样的开源框架的基本原理也是大有裨益的 接下来，我们回到刚才的话题，前面说过，在DEDE中的SQL操作只有3种，也就是说，所有的SQL请求流量最终都会通过这4个函靡允迪郑颐且黄鹄炊哉?4个函数进行一下代码审计学习，我会直接COPY原始的DEDECMS V5.7的源代码，并尽我所能去在代码中加上我的理解注释 1) SetQuery+Execute sql = "SELECT value FROM dede_sysconfig where varname='cfg_mb_open'";dsql->SetQuery($sql); //设置SQL语句，会自动把SQL语句里的dede_替换为$GLOBALS['cfg_dbprefix'](在配置文件中为$cfg_dbprefix)
function SetQuery($sql)
{
$prefix="dede_";
/*
1. 这样做的目的是为了兼容多个DEDECMS同时安装在同一个数据库中，它们可以使用不同的前缀
2. 在原始的SQL中，所有的前缀都采用一个占位符"dede_"，然后在代码执行前，根据当天配置的前缀(例如"dede_")进行替换。这是一种典型的适配器代码层的思想
*/
$sql = str_replace($prefix,$GLOBALS['cfg_dbprefix'],$sql);
//将替换后的SQL代码赋值给$this->queryString，用以之后发送给数据库
$this->queryString = $sql;
}
$dsql->Execute();  //执行一个带返回结果的SQL语句，如SELECT，SHOW等
function Execute($id="me", $sql='')
{
global $dsql;
/*
1. 这是第一个要重点注意的关键代码，我们知道，Init这个函数会从全局变量$GLOBALS中获取数据库连接信息，从而给黑客以利用本地变量覆盖来达到修改数据库连接方向的目的。
那我们要问自己一个问题了，什么时候能触发这个Init的执行条件呢？
2. 答案很明显: $dsql->isInit == FLASE的时候，那什么时候能满足这个条件呢？
3. 答案是在每次脚本请求中的第一次涉及数据库操作的时候(GetOne、Execute、ExecuteNoneQuery、ExecuteNoneQuery2中任意一种)的时候
4. 因为我们知道: PHP是一种解释性的脚本语言，每次的脚本解释执行都会有自己独立的代码空间，脚本请求之间不会互相共享内存。所以在每次的脚本请求中，$dsql这个对象初始都
是null的，$dsql->isInit的初始默认值也是FALSE，在一个脚本请求中多次出现数据库操作的时候，从第二次开始的数据库请求就不需要再重新进行数据库连接了(除非代码强制
进行重连接)
5. 这种在同一个脚本中的"持久化连接"和ADO.NET中的持久化数据库连接不是一个层次的技术，要注意区别
6. 这也给了我们一点关于漏洞挖掘的启示，如果想挖掘"利用全局变量覆盖+数据库连接方向劫持的绕过漏洞"，就必须寻找那种在脚本中第一次出现的、黑客可以控制输入参数的数据库
操作函数，这也是一种代码审计的思路
*/
if(!$dsql->isInit)
{
$this->Init($this->pconnect);
}
//如果这个连接已经关闭，则重新打开连接
if($dsql->isClose)
{
$this->Open(FALSE);
$dsql->isClose = FALSE;
}
if(!empty($sql))
{
$this->SetQuery($sql);
}
/*
1. 这个80Sec为DEDE提供的SQL语句安全检查
2. 个人愚见: 觉得这个Hook点还不够"中心化"、"底层化"，我的观点是在SetQuery这个函数进行Hook Patch，因为SetQuery是整个dedesql.class.php中所有涉及到SQL操作都
会涉及到的函数，在这个点进行流量分析，能做到更好的覆盖效果
*/
if($this->safeCheck)
{
CheckSql($this->queryString);
}
$t1 = ExecTime();
//调用PHP原生的mysql扩展接口，执行数据操作
$this->result[$id] = mysql_query($this->queryString,$this->linkID);
//记录执行时间
if($this->recordLog) {
$queryTime = ExecTime() - $t1;
$this->RecordLog($queryTime);
}
/*
记录数据库执行错误信息，方便调试，这里可能涉及到另一种利用发送附带webshell代码的错误服务器、数据库请求来将webshell注入日志中达到getshell的目的，不过这不是数据
库防御方案能解决的问题，这属于另一类解决方案了，我们之后的文章中会谈到这类漏洞
*/
if(!empty($this->result[$id]) && $this->result[$id]===FALSE)
{
$this->DisplayError(mysql_error()." <br />Error sql: <font color='red'>".$this->queryString."</font>");
}
}
2) ExecuteNoneQuery //执行一个不返回结果的SQL语句，如update,delete,insert等
function ExecuteNoneQuery($sql='')
{
global $dsql;
//这里的注意点和Execute函数是一样的
if(!$dsql->isInit)
{
$this->Init($this->pconnect);
}
if($dsql->isClose)
{
$this->Open(FALSE);
$dsql->isClose = FALSE;
}
if(!empty($sql))
{
$this->SetQuery($sql);
}else{
return FALSE;
}
//DEDE实现的一种参数化查询方法
if(is_array($this->parameters))
{
foreach($this->parameters as $key=>$value)
{
$this->queryString = str_replace("@".$key,"'$value'",$this->queryString);
}
}
//SQL语句安全检查，和之前的一样
if($this->safeCheck) CheckSql($this->queryString,'update');
$t1 = ExecTime();
$rs = mysql_query($this->queryString,$this->linkID);
//查询性能测试
if($this->recordLog) {
$queryTime = ExecTime() - $t1;
$this->RecordLog($queryTime);
//echo $this->queryString."--{$queryTime}<hr />\r\n";
}
return $rs;
}
3) ExecuteNoneQuery2 //执行一个返回影响记录条数的SQL语句，如update,delete,insert等
function ExecuteNoneQuery2($sql='')
{
global $dsql;
if(!$dsql->isInit)
{
$this->Init($this->pconnect);
}
if($dsql->isClose)
{
$this->Open(FALSE);
$dsql->isClose = FALSE;
}
if(!empty($sql))
{
$this->SetQuery($sql);
}
if(is_array($this->parameters))
{
foreach($this->parameters as $key=>$value)
{
$this->queryString = str_replace("@".$key,"'$value'",$this->queryString);
}
}
$t1 = ExecTime();
mysql_query($this->queryString,$this->linkID);
//查询性能测试
if($this->recordLog) {
$queryTime = ExecTime() - $t1;
$this->RecordLog($queryTime);
//echo $this->queryString."--{$queryTime}<hr />\r\n";
}
return mysql_affected_rows($this->linkID);
}
以上3个函数在DEDECMS中的不同数据库操作场景中出现，它们提供不同粒度的SQL操作接口，但对于代码安全审计者来说，我们关注的并不是它们的业务场景的功能，我更注重的是关键节点流量的攻击模式检测。即对SetQuery这个函数进行Hook Patch，检测所有通过它的流量。 2. 对数据库查询的SQL流量的攻击模式检测 在进行Hook Patch之前，我们首先要解决一个问题，SQL注入攻击都有什么样的攻击模式，我们该怎样把它们抽象成正则规则来进行模式匹配呢？ 这里参考了一篇博客的思路 http://blog./uid-286494-id-2134474.html 不过它和我们的应用场景还不太一样，他写的SNORT规则是基于HTTP层的流量检测，而我们这里要做的SQL Inject Hook Patch是在数据库执行层做注入检测，我们面对的是纯的SQL语法。我们必须结合SQL语法的自身情况进行分析，找到一种好的方法来区分出正常的业务SQL、以及攻击性SQL。 根据我自身的经验来说，确定一种规则不能仅仅考虑能不能有效地检测出注入SQL，还要考虑另一个方面: "误报"，我们的规则不能太严，否则会造成对正常的业务SQL造成误拦截，而这个规则的优化过程应该是一个震荡曲线，即一个不断修改、精细化的过程。大致的步骤可以是这样: 1. 根据目前手上掌握的攻击SQL，对这些语句进行"骨架抽取"，找出它们共同的正则特征 2. 编写仅仅刚好够覆盖这些特征的正则规则 3. 将这些正则规则上线测试运行，同时做好拦截、误报、漏报记录 4. 定期对日志记录进行梳理，根据误报、漏洞的情况进行小范围的正则规则修改，注意是小范围的修改，一次尽量只作刚好能解决现有的误报、漏洞问题的修改 5. 重复循环3、4的过程，不断达到误报、漏洞、准确性的一个平衡点 我目前就是在做3、4的这个循环过程，希望能在不断的攻防分析中找到一种好的SQL注入攻击模式的检测模式，分享一下我的思路，也希望有更好想法的朋友能不吝赐教，分享一些别的检测想法 /*
检测传入的SQL语句是否是攻击性SQL。即注入性检测
返回1: 有攻击性
返回0: 没有攻击性
*/
public function CheckSql($db_string)
{
/*
规则1:
最常见的注入点往往发生在where子句的and逻辑表达式后面，黑客通过在and后面的子句中添加额外的注入逻辑:
1) 在子查询中直接select系统表表来直接进行非法数据获取
2) 在子查询中或者进行盲注推理
3) 通过注释符进行提前闭合
*/
$express_1 = "/([A-Za-z])?(where)(.|\s)*?(concat|char|(chr){4,}|case|floor|#.*|--)/i";
/*
规则2:
黑客常用利用where子句的注入点，进行union select注入，以此达到爆表，爆字段的目的。典型的语法为
where 1=2 union select 1,1,1,1 from dual
*/
$express_2 = "/([A-Za-z])?(where).*(union)(\s)*(all)(\s)*select(\s)*(\d|null,(\s)*){2,}/i";
/*
规则3:
在sql查询中，有一些敏感关键字是不允许使用的
1) sleep、benchmark
2) load_file
3) outfile
4) user()
*/
$express_3 = "/[^0-9a-z@\._-]{1,}(sleep|benchmark|load_file|outfile|(user\(\).*){1,})[^0-9a-z@\.-]{1,}/i";
if (preg_match($express_1, $db_string) || preg_match($express_2, $db_string) || preg_match($express_3, $db_string))
{
//die("detected!!!");
return 1;
}
else
{
//die("good");
return 0;
}
}
解决了规则问题，我们现在可以开始我们本文的真正目的了: CMS代码漏洞修复 Hook Patch Point E:\wamp\www\dede5.7\include\dedesql.class.php -> SetQuery E:\wamp\www\dede5.7\include\dedesqli.class.php -> SetQuery //设置SQL语句，会自动把SQL语句里的dede_替换为$this->dbPrefix(在配置文件中为$cfg_dbprefix)
function SetQuery($sql)
{
$prefix="dede_";
$sql = str_replace($prefix,$GLOBALS['cfg_dbprefix'],$sql);
if($this->CheckSql($sql) == 1)
{
die("Request Error!");
}
$this->queryString = $sql;
}
public function CheckSql($db_string)
{
$express_1 = "/([A-Za-z])?(where)(.|\s)*?(concat|char|(chr){4,}|case|floor|#.*|--)/i";
$express_2 = "/([A-Za-z])?(where).*(union)(\s)*(all)(\s)*select(\s)*(\d|null,(\s)*){2,}/i";
$express_3 = "/[^0-9a-z@\._-]{1,}(sleep|benchmark|load_file|outfile|(user\(\).*){1,})[^0-9a-z@\.-]{1,}/i";
if (preg_match($express_1, $db_string) || preg_match($express_2, $db_string) || preg_match($express_3, $db_string))
{
//die("detected!!!");
return 1;
}
else
{
//die("good");
return 0;
}
}
经过测试，拿目前DEDE主流的POC进行渗透，防御效果较好，不过正如我们之前说的，这个正则规则需要一个不断地优化、修正过程。正如那句名言一样: 攻防对抗是一个长期的动态的过程，需要我们不断的去拓展思维，从攻击者、防御者两方面同时去思考。 我个人愚见: 目前虽然有乌云等漏洞批量平台不断地帮助开源WEB系统厂商去发现并修补漏洞，但总体来说，防守方还是处于一种被动防守的情况。而且比起被动防守来说，更大的问题在于，大部分的网站对自己的WEB系统出现的漏洞不具备快速的响应能力，更不用说很多中小站长在阿里云买了服务器之后，在上面装了一个DEDEV5.7之后，缺乏经常性的代码维护，导致了出现了高危漏洞的时候，这些站长没有及时修补漏洞，进行导致被黑客渗透入侵。这样的情况在阿里云ECS上的情况尤其严重。 鉴于以上的情况，我提出2点YY(仅仅是YY) 1. 参考云服务的思想，云服务商直接提供"云CMS"服务，用户可以选择需要购买什么类型的CMS(例如DEDE、ECSHOP)、版本也可以自己定制。云服务商在服务端统一维护一套WEB系统代码，进行严格的代码审计和加固，这样可以起到和堡垒主机同样的效果，通过放大单个节点的风险、从而减小防御范围面。 2. 将IDS的流量分析思想融入代码安全审计中，将目前遇到的所有CMS漏洞进行归类，找到最底层的流量节点，对这些核心文件进行Hook Patch，最终的目的是抽象出一个漏洞防御规则库，达到一劳永逸防御现有代码、以及可能出现的0DAY的威胁，因为比起对单个文件的修补，对一类漏洞，对底层代码逻辑的Hook，是可以达到提前预判的效果的 以上两点是我个人的YY，但是我觉得，未来的WEB漏洞的攻防应该有一种更加有效、有概括性的修补方案。就像windows的里程碑技术: DEP、SageSEH、ASLR等技术，都是在做归类性的漏洞修复，这些技术修复的不是某个漏洞，而是一整类漏洞，并同时很大程度上防御了很多未知的漏洞，这种优秀的思想是很值得借鉴的。 标签分类： |
|
|
