Drive By RCE Exploit in Pimcore 6.2.0

TL;DR overview

• Pimcore 6.2.0 contains a command injection vulnerability where unsanitized user input from a JSON parameter is embedded directly into a shell command that calls the exiftool binary.
• A separate SQL injection in the classification store feature allows injection into SQL IN clauses via PHP's `implode()` without any sanitization or prepared statement protection.
• Both vulnerabilities can be exploited via CSRF, enabling a drive-by attack where an unauthenticated attacker tricks an administrator into triggering full remote code execution.
• Both issues were fixed in Pimcore 6.2.1 within nine days of initial disclosure.

We analyzed Pimcore 6.2.0 and identified multiple critical vulnerabilities including a command injection vulnerability and SQL injection vulnerability which both can be exploited into a full remote code execution. Both vulnerabilities were fixed in Pimcore 6.2.1.

From Exif Data To Code Execution

Exiftool is a linux program which allows manipulation of image meta data called exif data. Whenever an image is processed by PimCore a shell command is executed to run the exiftool script with the image filename as a parameter. For this purpose a JSON object is passed through a GET-variable which can be controlled by an attacker to inject straight into a shell command.

vendor/pimcore/pimcore/bundles/AdminBundle/Controller/Admin/AssetController.php

1060    public function downloadImageThumbnailAction(Request $request)
1061    {
1062        /*...*/
1063        $config = $this->decodeJson($request->get('config'));
1064        /*...*/
1065        $thumbnailConfig->setFormat($config['format']);
1066        /*...*/
1067        $exiftool = \Pimcore\Tool\Console::getExecutable('exiftool');
1068        if ($thumbnailConfig->getFormat() == 'JPEG' && $exiftool 
1069        && isset($config['dpi']) && $config['dpi']) {
1070            \Pimcore\Tool\Console::exec($exiftool . 
1071            ' -overwrite_original -xresolution=' . $config['dpi'] . 
1072            ' -yresolution=' . $config['dpi'] . ' -resolutionunit=inches ' . 
1073            escapeshellarg($thumbnailFile));
1074    }

In line 1063 of the downloadImageThumbnailAction() method the $config parameter, storing a JSON object, is received from the HTTP request, decoded and stored into the $config variable. After validating that the image is a JPEG and the exiftool script is installed on line 1068, the $config['dpi'] variable is embedded unsanitized into the OS command and executed on line 1070. Although the $thumbnailFile variable is correctly sanitized by passing it through escapeshellarg(), the developers of PimCore have not applied this function to the dpi key of the $config parameter.

Preparing an Array: SQL’s IN Keyword

Although Pimcore is making use of prepared statements all over the application, we could confirm multiple SQL injections detected by our RIPS scanner requiring the role of a back end user having access to the objects section. One of those flaws comes from the abstract database layer which fails to provide a direct method to safely embed an array into a SQL query. Often developers feel the urge to let a user provide a list or an array of ids which shall be deleted, updated, or selected. To solve this problem they make use of SQL’s IN keyword. We will now see an example on how this can go wrong:

vendor/pimcore/pimcore/bundles/AdminBundle/Controller/Admin/DataObject/ClassificationstoreController.php

921    public function addCollectionsAction(Request $request)
922    {
923        $this->checkPermission('objects');
924        $ids = $this->decodeJson($request->get('collectionIds'));
925        /*...*/
926        if ($ids) {
927            $db = \Pimcore\Db::get();
928            $query = 'select * from classificationstore_groups g, 
929                classificationstore_collectionrelations c where colId IN (' 
930                . implode(',', $ids)
931                . ') and g.id = c.groupId';
932            /*...*/
933            $groupsData = $db->fetchAll($query);

The addCollectionsAction() method can be called through routing directly. User input is received through the collectionIds parameter on line 924. The array of ids is then sent to implode(), transforming the array into a comma separated string of its values. The builtin function implode() does neither sanitize nor validate and therefore the resulting string should not be embedded directly into the SQL query, which is done on line 930 leading to a SQL injection.

In contrast, modern database abstraction layers build a wrapper around PDO’s prepare() method. They will prepare a SQL query containing as many ? placeholders as there are values in the array, and pass the potentially malicious array of the user as an argument to the execute() method of PDOStatement instance.

Forging a Drive By Exploit

A missing CSRF token enables an attacker to exploit the vulnerabilities via CSRF which results in a drive by exploit where an administrator is lured onto a malicious page embedding a form which is auto submitted to send a request to the web page, including the cookies of the administrator, allowing the exploitation of the remote code execution. To exploit the SQL injection, a more sophisticated attack allows extraction of data via side channels.

Timeline

Summary

The intrinsic vulnerabilities described in this blog post sketch the imbalance between attackers on the one hand - requiring only a single point of failure - and the defenders on the other hand who miss a single flaw in the system leading to a full compromise. The threat of CSRF vulnerabilities is often underestimated, however, in targeted attacks launched by determined adversaries they pose an attractive step stone for network intrusion and social engineering. In this specific case we would like to thank the Pimcore developers and gladly appreciate their security awareness due to their instant response and fix for the the issues.