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.
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
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:
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
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.
|09/09/2019||First contact with and vulnerability report to vendor|
|09/09/2019 + a few hours||Acknowledgment, confirmation and commit to correct patch|
|09/18/2019||Release of PimCore 6.2.1|
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.