The 23rd gift in our advent calendar presents security issues in e107, a content management system that is in development since 2013. Among others, we identified a critical issue that allows any user to update his permissions and to extract sensitive information from the database by exploiting a PHP object injection vulnerability.

RIPS Analysis

The e107 CMS consists of 317,356 lines of code and was analyzed in about 2 minutes. Many of the vulnerabilities found by RIPS are exploitable, despite a few exceptions. The main reason for this is that e107 contains a lot of unused code from previous releases and thus not all affected functions are reachable. Most of the SQL injection vulnerabilities are caused by missing quotes. The input gets escaped properly, but since it is not surrounded by quotes this is not sufficient and the SQL query can be modified.

The truncated analysis results are available in our RIPS demo application. Please note that we limited the results to the issues described in this post in order to ensure a fix is available.

Case Study

PHP Object Injection to Privilege Escalation

e107 suffers from a PHP object injection vulnerability, i.e. user input is passed to the function unserialize(). The MD5 sum of the user input is checked in line 354, but there is no secret involved and thus an attacker can simply calculate the value himself. The correct approach would have been to use a keyed-hash message authentication code (HMAC) to prevent modifications by malicious users that do not possess the secret key.

usersettings.php

353354355356357

$new_data = base64_decode($_POST['updated_data']);
if (md5($new_data) != $_POST['updated_key'] || ($userMethods->hasReadonlyField($new_data) !== false)) {
    exit();
}
$changedUserData = unserialize($new_data);

Unlike in our Expression Engine post, an attacker does not have to use property oriented programming to reach sensitive code that can be exploited. The return value of unserialize() is stored in the variable $changedUserData that is then used directly in further sensitive operations.

usersettings.php

453454455

$changedData['data'] = $changedUserData;
$changedData['WHERE'] = 'user_id='.$inp;
if (FALSE === $sql->update('user', $changedData))

e107_handlers/mysql_class.php

11601161116211631164

function update($tableName, $arg, $debug = FALSE, $log_type = '', $log_remark = '') {
    $table = $this->db_IsLang($tableName);
    $arg = $this->_prepareUpdateArg($tableName, $arg);
    $query = 'UPDATE '.$this->mySQLPrefix.$table.' SET '.$arg;
    $result = $this->mySQLresult = $this->db_Query($query, NULL, 'db_Update');

Namely, the data is used in a SQL UPDATE query. This query is build by using the _prepareUpdateArg() method.

e107_handlers/mysql_class.php

108310841085108610871088108910901091

private function _prepareUpdateArg($tableName, $arg) {
    ⋮
    foreach ($arg['data'] as $fn => $fv) {
        $new_data .= ($new_data ? ', ' : '');
        $ftype = isset($fieldTypes[$fn]) ? $fieldTypes[$fn] : 'str';
        $new_data .= "{$fn}=".$this->_getFieldValue($fn, $fv, $fieldTypes);
        ⋮
    }
    return $new_data .(isset($arg['WHERE']) ? ' WHERE '. $arg['WHERE'] : '');

124712481249125012511252

function _getFieldValue($fieldKey, $fieldValue, &$fieldTypes) {
    $type = isset($fieldTypes[$fieldKey]) ? $fieldTypes[$fieldKey] : $fieldTypes['_DEFAULT'];
    switch ($type) {
        case 'str':
        case 'string':
            return "'".$this->escape($fieldValue, false)."'";

All values are escaped by _getFieldValue() in line 1088 of the method _prepareUpdateArg(). However, with the help of the object injection, an attacker is able to specify arbitrary array keys and those are not sanitized in any way. This allows the attacker to modify the UPDATE query that is performed on the user table and to set arbitrary values. It is possible to change permissions of accounts, set new passwords, read information from other tables, and to inject JavaScript in the database for persistent cross-site scripting attacks. In short, the attacker has full control over the application.

Time Line

Summary

The lesson learned by this vulnerability is that one should never trust array keys in PHP. Despite, these should be treated with care as any other variable. The security issue could be detected successfully by RIPS due to its precise array handling and its comprehensive analysis of PHP object injection vulnerabilities. We would like to thank the e107 team for the very professional collaboration. They responded fast and worked hard until the very last minute in order to provide a fixed version. We urge all users to update to the latest version.

APAV Time Table