无框架的php cms审计,通读审计之DOYOCMS

原标题：通读审计之DOYOCMS

前言

首先大家看到我文章的标题，我这里所谓的“通读审计”就是把整个代码审计过程一字不差的记录下来。因为审计过很多CMS，也看过很多代码审计文章，大多数都是把漏洞点提一下然后文章结束，对于不懂MVC的审计者来说，看其他人代码审计文章，很多细节问题搞不明白(因为我自己也是从那里过来的)，所以读起来不是太舒畅，自己学习起来也有点吃力，尤其到MVC框架一块。然后这把就是给大家分享一下我个人的整个代码审计过程，以及如何发现漏洞，如何自己构造语句等等。这次审计的cms是DOYOCMS建站系统，因为我们学校使用的该系统，就随便拿一套过来记录吧。也是给自己做个记录，给大家分享个人经验。

一、MVC的了解

这里就不再废话了，直接就开始吧。

Index.php第二行，上来直接require进来一个config.php，我们来看一下该文件到底做了哪些操作。

OK，config.php文件定义了一些常量以及数据库信息。

Index.php第三行。

$doyoConfig[ 'view'][ 'config'][ 'template_dir'] = APP_PATH. '/template/'.$doyoConfig[ 'ext'][ 'view_themes'];

如下图的变量值赋给

$doyoConfig[ 'view'][ 'config'][ 'template_dir']

Index.php的第四行的

require(DOYO_PATH. "/sys.php");

把config.php的两个定义常量

define( "APP_PATH",dirname( __FILE__));

define( "DOYO_PATH",APP_PATH. "/include");

的DOYO_PATH与sys.php拼接起来并且包含(包含include/sys.php)

我们看一下包含进来的sys.php文件进行了哪些操作

Sys.php的第四行包含进来一个Functions.php文件。从文件名上来看来猜测是包含来的一些方法吧。

打开看一下

好，确定包含方法。回到sys.php文件继续通读

Sys.php文件的第五行

$GLOBALS[ 'G_DY'] = spConfigReady( require(DOYO_PATH. "/inc.php"),$doyoConfig);

Require进来inc.php文件并且使用spConfigReady函数处理(之前提到的functions.php方法文件还记得吧)

跟进spConfigReady方法

可以看到第218行进行判断传入进来的$useconfig是否为数组，如果为数组进行遍历该数组，并且把传递过来的$useconfig保存到$preconfig内(合并数组)。

从他调用该方法中给形参1传递一个require进来的文件可以判断。该文件直接return一个数组。

打开包含进来的require(DOYO_PATH.”/inc.php”)文件来看一番

直接return一个数组

好，把inc.php文件return的数组与之前在index.php中定义过的$doyoConfig['view']['config']['template_dir']保存到全局变量$GLOBALS['G_DY']

回来继续读取sys.php

在functions文件中，跟进import方法。

再来看一下传递进来的值

39-43行的

if( TRUE== @is_readable($sfilename) ){

require($sfilename);

$GLOBALS[ 'G_DY'][ 'import_file'][md5($sfilename)] = TRUE;

returnTRUE;

}

进行判断形参$sfilename是否可读，可读即包含。

OK，了解完import是用来读取文件之后，我们随着依次打开

这三个文件，看一下都有哪些操作。

哈哈，三个文件都是定义的类文件。

从字面上来看

syController：Controller的表面意思为控制器

syModel：Model的表面意思为模型

syView：View的表面意思为视图

MVC…

再回来读sys.php文件的第29-36行

判断分支给$GLOBALS['G_DY']['url']["url_path_base"]进行赋值

再读取sys.php文件的第42-50行

看到!empty($_SERVER['PATH_INFO']，是用来实现伪静态化的操作的

下面的52-58行是作为重点。

判断分支给$GLOBALS['G_DY']['url']["url_path_base"]进行赋值

再读取sys.php文件的第42-50行

看到!empty($_SERVER['PATH_INFO']，是用来实现伪静态化的操作的

下面的52-58行是作为重点。

跟进syClass与spLaunch方法

functionsyClass($class_name, $args = null, $sdir = null, $force_inst = FALSE){

if(preg_match( "/^[a-zA-Z0-9_\-]*$/",$class_name)== 0)syError( "类定义不存在，请检查。");

if( TRUE!= $force_inst) if( isset($GLOBALS[ 'G_DY'][ "inst_class"][$class_name])) return$GLOBALS[ 'G_DY'][ "inst_class"][$class_name];

if( null!= $sdir && !import($sdir) && !import($sdir. '/'.$class_name. '.php')) returnFALSE;

$has_define = FALSE;

if(class_exists($class_name, false) || interface_exists($class_name, false)){

$has_define = TRUE;

} else{

if( TRUE== import($class_name. '.php')){

$has_define = TRUE;

}

}

if( FALSE!= $has_define){

$argString = '';$comma = '';

if( null!= $args) for($i = 0; $i < count($args); $i ++) { $argString .= $comma . "\$args[$i]"; $comma = ', ';}

eval( "\$GLOBALS['G_DY']['inst_class'][\$class_name]= new \$class_name($argString);");

return$GLOBALS[ 'G_DY'][ "inst_class"][$class_name];

}

syError($class_name. "类定义不存在，请检查。");

}

二、 PHP任意文件替换漏洞

紧接着上面继续往下分析

我们打开sysession文件看一下。

自改了session存储机制。注意看write方法。写入session操作。

看到在file_put_contents写入前拼接了” ”关键字。首先我们想到php://filter进行绕过。但是我们可以看到前面拼接了一个$filedir。$filedir变量是路径信息。不可控。则php://filter无法绕过。

file_put_contents在windows下我们可以进行写入冒号文件流的格式。例如：xxx.php:.php。可以逃逸。但是生成后的文件却是空的。再进行xxx.php<<

我们没有任何机会来通过session文件来getshell

但是从另一个角度讲，file_put_contents函数是由fopen函数与fwrite函数封装起来的。使用了’w’的写入规则。

比如，这里有一个1.php。文件内容为123，当你file_put_contents(‘1.php’,’xxx’);的时候，1.php文件内容”123”会被替换为我们传入的”xxx”

再来看看程序自写的session存储机制居然没有对路径做任何过滤。

那么就比较有趣了。我们可以通过修改session的值。来进行替换任何文件。

就可以成功把根目录下的 /include/inc.php 文件内容给替换掉。include/inc.php 文件内容为网站配置。该框架中有运行。再结合之前程序写入session文件内容所定义的。可以导致网站无法正常访问。(被die暂停程序运行)。

验证漏洞结果：

三、继续观察MVC

我们再回到functions.php文件进行读取第11行

$handle_controller = syClass($__controller, null, $GLOBALS['G_DY']["controller_path"].’/’.$__controller.”.php”);

进行syClass函数处理。我们之前了解到syClass方法是用来处理类文件并包含的。

传入的第三个参数亮了。

根据我们传递的参数，则/source/$_GET[‘c’]是我们所包含的文件。我们在source文件夹下创建test.php进行验证一下

看来逻辑是没有问题的

接着我们继续往下看functions.php文件的第16行

这样来，我们整个的处理逻辑搞清楚开始挖掘漏洞

四、SSRF漏洞

当前我在functions.php这个文件。既来之，则安之。我通过危险自定义的一些方法来寻找漏洞

我从functions.php文件的第100-117行发现了

该函数传入的$url如果没有严谨的过滤，则会造成SSRF漏洞

全局搜索一下这个函数。

看到大名鼎鼎的a_sys类文件($_REQUEST[‘c’])与调用该漏洞的方法($_REQUEST[‘a’])

可是问题来了，我们所包含类文件的路径是 /source，而不是/source/admin/xxx.php

那么我们如何引入呢？不慌。

全局搜索一下哪里修改了$doyoConfig['view']['config']['template_dir']的值(该值影响包含路径)

在admin.php中重现了index.php的操作。只是略有一些不同

那么我们SSRF漏洞利用点也只能在后台了，有一定的局限性

登陆后台后

我们包含a_sys.php文件并实例化该类，然后调用template_cache方法

这里是传入的$y。我们再该文件内翻半天也不会翻到syArgs方法的。

原因很简单，继承了一个类。

这里构造方法有了和template_cache方法相同的步骤

我们之前所看过的这个类的一个syArgs方法

可是在syController中也没有找到syArgs方法，那么我们就需要看一下__call魔术方法的处理了

第48行

return syClass($name)->__input($args);

syClass我们之前了解到的功能就是进行包含syArgs这个类文件或实例化该类，随后调用__input方法，把我们__construct的$this->a=$this->syArgs(‘a’,1);中’a’,1以数组的形式传递给__input方法

看一下get方法

调用了has方法，把字符串’a’传递进去了

跟进has方法

咦？多了一个成员属性$this->args

我们看一下构造方法是否初始化该属性

该类的构造方法

args成员属性是$_REQUEST进来的变量

如果我们传入的?a=template_cache，返回true

再回来看一下该分支结构

继续跟进filters方法

看到该方法是用来过滤传入数据内容的。在其中的 case 0，1,2,3,4,5,中，可以看到都对传入的数据进行过滤操作。可是在case 2中，漏洞出现了。这里涉及到array_walk_recursive函数利用问题。

看着arrays方法的代码块，好像过滤的还挺全的。不仔细想一想还真不知道。

array_walk_recursive函数并不会影响到数组本身。例如：

可以看到我们放入的 test=>’aaa，单引号并没转义。好了，现在了解到syArgs的第二个参数存在未过滤问题。

我们继续回到第102-105行的操作

再回到我们之前这一步

把我们传入的y进行实体化编码(htmlspecialchars)以及防注入(addslashes)操作，但是我们当前发现的漏洞输入SSRF类型的，所以对我们毫无影响~

好了，构造payload: admin.php?c=a_sys&a=template_cache&y=127.0.0.1:3306

验证漏洞结果：

五、SQL注入漏洞

那么我们知道syArgs(x,2)的第二个参数存在漏洞问题之后。我们全局搜索：,2)。来查找哪一地方使用了该函数。

可以看到update关键词。这东西对我们非常敏感。审计突然就像喝了红牛一样。精神杠杠的。

PS:这里if验证跟进就不再说了。直接看update。

果然，是自己封装的update语句。

那么构造

Payload:?c=a_classtypes&a=alledit&orders[]=1′ or updatexml(2,concat(0x7e,(version)),0) or’

验证漏洞结果：

*本文作者：Heihu577，转载请注明来自FreeBuf.COM返回搜狐，查看更多

责任编辑：