e107 CMS is less than or equal to 2. 1. 2 elevation of privilege vulnerability analysis-vulnerability warning-the black bar safety net

ID MYHACK58:62201782676
Type myhack58
Reporter 佚名
Modified 2017-01-05T00:00:00


0x00 vulnerability background e107 CMS is a based on PHP, Bootstrap, Mysql, web site content management system, can be widely used for personal blogs, enterprise built station, in the global range more widely. 0x01 vulnerability affects version version 0x02 vulnerability analysis of the environment Operating environment:macOS10. 12. 2 + apache2. 4. 23 + PHP5. 6. 27 + Mysql5. 7. 16 e107 CMS version: v2. 1. 2 0x03 vulnerability details First of all, we from the rips of the scan report: https://blog. ripstech. com/2016/e107-sql-injection-through-object-injection/can roughly know the entire vulnerability trigger is the use of anti-serialization vulnerabilities for database data modification, further elevation of privileges. Next, we come to the whole trigger process for analysis: 1. First, we registered an ordinary user test2,原始 邮箱 地址 为 test22@1.com; we can see user_admin field is 0 for e107 CMS to user_admin field marked user permissions, 1 for admin, 0 for normal user, so test2 is a normal user; next we enter/e107/usersettings. php modify the mailbox ! 2. Deserialization vulnerability and database injection vulnerability code tracking Variable relationship comment:$_POST[‘updated_data’]is the base64-encoded value,$new_data is base64-decoded value is a serialized value,$changedUserData is deserialized the value is an array. 首先 跟进 usersettings.php 353-387 lines of code 353 $new_data = base64_decode($_POST['updated_data']); ... 387 $changedUserData = unserialize($new_data); 353 in the row the user can control the variable$_POST['updated_data']without further processing directly in the 387 line for the deserialization, and the data is assigned to$changedUserData variables, in order to further the operation. Continue to follow up$changedUserData variables 455 $changedData['data'] = $changedUserData; ... 460 if (FALSE === $sql->update('user', $changedData)) $changedUserData variables in 460 travels into the mysql class method, follow-up/e107_handlers/mysql_class. in php update function 1160 function update($tableName, $arg, $debug = FALSE, $log_type = ", $log_remark = ") { 1162 $arg = $this->_prepareUpdateArg($tableName, $arg); ... 1183 $result = $this->mySQLresult = $this->db_Query($query, NULL, 'db_Update'); Follow _prepareUpdateArg function 1083 private function _prepareUpdateArg($tableName, $arg) { 1084 ... 1085 foreach ($arg[‘data’] as $fn = > $fv) { 1086 $new_data .= ($new_data ? ', ' : "); 1087 $ftype = isset($fieldTypes[$fn]) ? $fieldTypes[$fn] : 'str'; 1088 $new_data .= "{$fn}=".$ this->_getFieldValue($fn, $fv, $fieldTypes); 1089 ... 1090 } 1091 return $new_data . (isset($arg[‘WHERE’]) ? 'WHERE '. $arg['WHERE'] : "); Follow _getFieldValue function 1247 function _getFieldValue($fieldKey, $fieldValue, &$fieldTypes) { 1248 $type = isset($fieldTypes[$fieldKey]) ? $fieldTypes[$fieldKey] : $fieldTypes['_DEFAULT']; 1249 switch ($type) { 1250 case 'str': 1251 case 'string': 1252 return "'".$ this->escape($fieldValue, false)."'"; As can be seen$changedUserData variables only to be split open, and did not do further check whether there is malicious parameters, so as long as$changedUserData contains malicious user table fields, it is possible to arbitrarily modify the data in the table value. 3. Exploit First we look at the normal test modify the mailbox data format,测试 更改 邮箱 为 22test2@1.com ! Here you can clearly see, the$new_data variable for the data to be modified to serialize the value,$changedUserData for$new_data deserialized values,data check is successful, the$changedUserData will be split, and then into the$sql->update function is executed, and then any modifications to the database data. So, how do we exploit this vulnerability chain? To do provide the right to operate, we need to update the test2 user user_admin field, and modify the$new_data variable value must be passed usersetings. php two if statement check: 358 if (md5($new_data) != $_POST['updated_key'] || ($userMethods->hasReadonlyField($new_data) !== false)) ... 366 if (md5($new_extended) != $_POST['extended_key']) From the 358 line view, we in the bag to modify the$_POST['updated_data']at the same time the need to modify off the$_POST['updated_key'], so as to meet the md5 value of the check. I use the following php code to generate update_key and updated_data / php code / $a = array('user_email'=>'2test2@1.com','user_admin'=>1); $b = serialize($a); echo 'updated_data is: '.$ b; echo 'update_key is : '. md5($b); / php code / Next, using burpsuite capture modify$_POST['updated_data']and$_POST['update_key'] note:e107 modify the mailbox will verify the password, we only modify the check the password after the data packet, as shown below:) ! Successfully deserialized: !

[1] [2] next