{"id":45843,"date":"2022-03-23T15:59:26","date_gmt":"2022-03-23T15:59:26","guid":{"rendered":"https:\/\/packetstormsecurity.com\/news\/view\/33248\/ImpressCMS-From-Unauthenticated-SQL-Injection-To-RCE.html"},"modified":"2022-03-23T15:59:26","modified_gmt":"2022-03-23T15:59:26","slug":"impresscms-from-unauthenticated-sql-injection-to-rce","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/impresscms-from-unauthenticated-sql-injection-to-rce\/","title":{"rendered":"ImpressCMS: From Unauthenticated SQL Injection To RCE"},"content":{"rendered":"

According to the official website<\/a> ImpressCMS is an open source Content Management System (CMS) designed to easily and securely manage multilingual web sites. With this tool maintaining the content of a website becomes as easy as writing a word document. ImpressCMS is the ideal tool for a wide range of users: from business to community users, from large enterprises to people who want a simple, easy to use blogging tool. ImpressCMS is a powerful system that gets outstanding results and it is free!
The application comes with a built-in security module \u2013 Protector<\/a> \u2013 which is designed to improve the overall security of ImpressCMS websites and prevent certain web attacks such as Cross-Site Scripting (XSS) and SQL Injection. In this blog post we will see how to bypass such a security mechanism to exploit a couple vulnerabilities I discovered about a year ago, which might eventually allow unauthenticated attackers to execute arbitrary PHP code on the web server (RCE<\/a>)\u2026<\/span><\/p>\n

\u2022 Vulnerabilities analysis:<\/p>\n

Let\u2019s start to analyze the two vulnerabilities which can be exploited in tandem to bypass access control (KIS-2022-03<\/a>) and reach a script vulnerable to SQL Injection (KIS-2022-04<\/a>). Both of them are located in the \/include\/findusers.php<\/i><\/b> script, which is intended to be used by authenticated users to search for other users. However, due to the following vulnerable lines of code, it can be accessed by unauthenticated attackers as well:<\/p>\n

\ninclude \"..\/mainfile.php\";\nxoops_header(false); $denied = true;\nif (!empty($_REQUEST['token'])) { if (icms::$security->validateToken($_REQUEST['token'], false)) { $denied = false; }\n} elseif (is_object(icms::$user) && icms::$user->isAdmin()) { $denied = false;\n}\nif ($denied) { icms_core_Message::error(_NOPERM); exit();\n}\n<\/pre>\n
The \u201celseif\u201d statement at lines 24-26 will check whether the user is currently authenticated and they have administrator privileges, if so it will grant access to the script functionalities. While the \u201cif\u201d statement at lines 20-23 will do the same by solely checking the provided security token, without verifying whether the user is currently authenticated or not. This means that if an attacker provides a valid security token, then they will get unauthorized access to the script. Such security tokens will be generated in several places within the application \u2013 just grep the code searching the string icms::$security->getTokenHTML()<\/code> \u2013 and some of them do not require the user to be authenticated, like the misc.php<\/i><\/b> script, here<\/a> at line 181.<\/p>\n
Moving forward to some lines later we can see the following:<\/p>\n
 $total = $user_handler->getUserCountByGroupLink(@$_POST[\"groups\"], $criteria); $validsort = array(\"uname\", \"email\", \"last_login\", \"user_regdate\", \"posts\"); $sort = (!in_array($_POST['user_sort'], $validsort)) ? \"uname\" : $_POST['user_sort']; $order = \"ASC\"; if (isset($_POST['user_order']) && $_POST['user_order'] == \"DESC\") { $order = \"DESC\"; } $criteria->setSort($sort); $criteria->setOrder($order); $criteria->setLimit($limit); $criteria->setStart($start); $foundusers = $user_handler->getUsersByGroupLink(@$_POST[\"groups\"], $criteria, TRUE);\n<\/pre>\n
At lines 281 and 294 the \u201cgroups\u201d POST parameter is being used in a call to the getUserCountByGroupLink()<\/code> and getUsersByGroupLink()<\/code> methods from the icms_member_Handler<\/code> class, and both of them use the first argument to construct an SQL query without proper validation (assuming it is an array of integers), as shown in the following code snippet:<\/p>\n
 public function getUserCountByGroupLink($groups, $criteria = null) { $ret = 0; $sql[] = \"\tSELECT COUNT(DISTINCT u.uid) \" . \"\tFROM \" . icms::$xoopsDB->prefix(\"users\") . \" AS u\" . \" LEFT JOIN \" . icms::$xoopsDB->prefix(\"groups_users_link\") . \" AS m ON m.uid = u.uid\" . \"\tWHERE 1 = '1'\"; if (! empty($groups)) { $sql[] = \"m.groupid IN (\" . implode(\", \", $groups) . \")\"; } if (isset($criteria) && is_subclass_of($criteria, 'icms_db_criteria_Element')) { $sql[] = $criteria->render(); } $sql_string = implode(\" AND \", array_filter($sql)); if (! $result = icms::$xoopsDB->query($sql_string)) { return $ret; } list($ret) = icms::$xoopsDB->fetchRow($result); return $ret; }\n<\/pre>\n
To sum up, a remote unauthenticated attacker might be able to manipulate the executed SQL queries, and this could be exploited to e.g. read sensitive data from the \u201cusers\u201d database table through boolean-based SQL Injection attacks, without the knowledge of the tables prefix (which is randomly generated during the installation). This is possible by injecting a payload like this:<\/p>\n
\n
\n1) AND ORD(SUBSTR(u.pass,1,1)) = XX #\n<\/p>\n<\/blockquote>\n
At a first glance, this seems to be a quite limited vulnerability: first of all, users\u2019 passwords are hashed with \u201csalting\u201d, so they cannot be cracked without first disclosing the salt; another option would be leaking the admin\u2019s email address and attack the password reset mechanism, but this won\u2019t do the trick, because a random password will be generated and emailed to the user\u2026 So, here comes the question: is it possible to leverage these vulnerabilities to login into ImpressCMS as admin and escalate the attack to an RCE? And the answer is: yesss! However, we have to deal with the Protector module\u2026<\/p>\n
\u2022 Exploitation:<\/p>\n
In a nutshell, without going deeper into the details, the anti SQL Injection measures provided by the Protector module check for suspicious strings within the request parameters, such as select<\/code>, concat<\/code>, or information_schema<\/code>, and if they are found then the request will be blocked and the event will be logged. As such, we can\u2019t use something like UNION SELECT...<\/code> to complete the query and fetch data from an arbitrary table. On the other hand, ImpressCMS uses PDO<\/a> as a database driver, which allows for stacked SQL queries separated by a semicolon. So, we can inject something like this:<\/p>\n
\n
\n0); INSERT INTO i36fd6f18_users (uname, pass) VALUES (0\u00d765676978, 0\u00d732333964\u2026) #\n<\/p>\n<\/blockquote>\n
This will create a new record into the \u201cusers\u201d database table, allowing an attacker to login as an ImpressCMS administrator, which would mean game over! However, in order to do that, the attacker should first guess the database tables prefix\u2026 And this could be achieved again with a boolean-based SQL Injection attack, by injecting something like the following:<\/p>\n
\n
\n1) AND ORD(SUBSTR((SELECT table_name FROM information_schema.tables WHERE table_schema=\u2019impresscms\u2019 AND table_name LIKE \u2018%users\u2019), 1, 1)) = XX #\n<\/p>\n<\/blockquote>\n
Unfortunately, this one will get blocked by the Protector module because it contains suspicious SQL strings, so we need to find another way\u2026 And here it comes: since stacked queries are allowed, an attacker might be able to bypass the Protector module by assigning to a variable the hex representation of the query they want to execute (by using SET<\/a>), and then use the PREPARE<\/a> and EXECUTE<\/a> MySQL statements to ultimately execute the query. This means we should inject something like this:<\/p>\n
\n
\n0);
SET @q = 0x53454c45435420534c454550283129;
PREPARE stmt FROM @q;
EXECUTE stmt; #\n<\/p>\n<\/blockquote>\n
This one will not be catched by the Protector module, because the \u201csuspicious strings\u201d are hex-encoded! At this point we have all the pieces to put together the puzzle, and here are all the steps to get from unauthenticated SQL injection to RCE:<\/p>\n