e107 2.1.2: SQL Injection through Object Injection23 Dec 2016 by Hendrik Buchwald
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.
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.
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.
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.
Namely, the data is used in a SQL UPDATE query. This query is build by using the
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
|2016/11/18||First contact with vendor|
|2016/11/21||Send details to vendor|
|2016/11/27||Vendor pushes fix for most critical vulnerabilities to repository|
|2016/11/29||Vendor starts patching the less-severe vulnerabilities|
|2016/11/29||Coordination with vendor about release of blog post|
|2016/12/13||Rechecked status with vendor about release date|
|2016/12/23||Vendor releases fixed version 2.1.3|
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.
Follow us on Twitter to be notified when the next gift of our advent calendar is opened!
APAV Time Table
Disclaimer: The information provided here is for educational purposes only. It is your responsibility to obey all applicable local, state and federal laws. RIPS Technologies GmbH assumes no liability and is not responsible for any misuse or damages caused by direct or indirect use of the information provided.