Critical Mautic Vulnerability (CVE-2024-47051) Enables Arbitrary File Uploads

Overview

The SonicWall Capture Labs threat research team became aware of a critical arbitrary file upload in Mautic, assessed its impact, and developed mitigation measures. Mautic is an open-source marketing automation project, and its developers claim it is used by over 200,000 organizations. Mautic versions before 5.2.3 allow low-privileged authenticated threat actors with permissions to manage assets to upload malicious files, which can lead to remote code execution, earning a critical CVSS score of 9.1.

We encountered a “403 Forbidden” response when trying to access the uploaded malicious file in our Docker-based testbed running Mautic version 5.2.1. This response was due to the default security measures in the Apache .htaccess file, which restrict access to .php files, allowing only index.php and upgrade.php. Assuming this is the standard configuration, it reduces the severity of the vulnerability for Docker installations. However, manual installations might still be susceptible to code execution if they are configured to allow access to .php files. Regardless of the installation method, the vulnerable version of Mautic permits attackers to upload malicious files. Therefore, we strongly encourage users to upgrade their instances to the latest fixed version as outlined in the vendor advisory.

Technical Overview

This vulnerability arises due to a logical flaw in the sanitization process of the file upload functionality, when a user adds/edits the asset. The file upload function is defined as public function newAction and public function editAction, respectively, for the add/edit action. The code snippet, as seen in Figure 1, defines the logic to handle the uploaded file and calls the culprit functions preUpload() and upload(), which write the file on the disk.

The function preUpload(), as seen in figure 2, defines the filename and extension of the final file, which is going to be written on the disk. It generates the filename as a SHA1 sum and then comes the interesting part of deciding the extension of the uploaded file. Initially, it tries to use the function guessExtension() from the symphony to decide the extension based on the MIME types, and it fallbacks to use the extension of the originalFileName parameter (user controllable) if it gets an empty response from the guessExtension() function. In a potential attack scenario, if an attacker modifies the extension of the originalFileName parameter in the request as .php after uploading a file with php content using any allowed file extension such as jpg, then guessExtension() returns NULL. Since the extension in the originalFileName parameter is modified as .php, it will define the extension variable as .php.

Finally, the upload() function, as seen in figure 3, saves the file on the disk using the filename and extension provided by preUplaod() function in the defined upload directory (media/files/ by default) and deletes the temporary file, bypassing the restrictions provided by the allowed_extensions configuration variable.

Triggering the Vulnerability

Leveraging the vulnerability mentioned above requires the attacker to meet the below prerequisites.

1. The attacker must have network access to the target vulnerable system with the permission to manage assets.
2. The attacker must upload a malicious php file with any allowed extensions such as .jpg
3. The attacker must intercept and modify the originalFileName with a .php extension when sending the save asset request.
4. The attacker must access the uploaded php file to execute the code.

Exploitation

Exploitation of this vulnerability allows a remote threat actor to upload an arbitrary file on the vulnerable installation, which may lead to remote code execution. We set up a docker-based Mautic v5.2.1 to test the exploit.

To begin the exploitation, the attacker needs to create a new asset by visiting “Components > Assets” section within the UI and upload a file containing php code with an allowed extension. For instance, we uploaded shell1.png with php code in content, as seen in Figure 4. Since the .php extension is not in the allowed_extensions by default, we used the .png extension so the application allows the file to be uploaded.

Here, the value of tempId=tmp_67c9e82864add and tmpFileName=67c9eae0e0a16.png indicates that the uploaded file will be temporarily stored inside the tmp directory at media/files/tmp/tmp_67c9e82864add/67c9eae0e0a16.png, as seen in Figure 5.

Next, we need to click on the save button to write the actual file on the disk. The request to save the file looks like Figure 6. Since this request uses the preUpload() function, as seen in Figure 2, to determine the file extension, we have modified the parameter asset[originalFileName] with the .php extension. It allowed us to bypass the restriction imposed by the allowed_extensions and save the resulting file with the php extension, as seen in Figure 6.

The final resulting filename can be retrieved from the “Details” section of the uploaded asset, as seen in Figure 7. The arbitrary file can be uploaded similarly using the edit assets functionality, as the underlying functionality remains the same.

Additionally, the arbitrary file/directory deletion vulnerability can be exploited by editing any existing asset and modifying the request, as seen in Figure 9. It abuses the temporary file deletion functionality of the upload() function shown in Figure 3.

In the above request, the values of the parameters, asset[tempName] and asset[tempId], are modified in a way that it will delete the /tmp/poc directory, as seen in Figure 10. Please note that the user www-data must have read-write permissions to the target directory and file to leverage this vulnerability. Similarly, this vulnerability can also be exploited by modifying the add asset request.

SonicWall Protections

To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:

• IPS: 20803 Mautic Arbitrary File Upload
• IPS: 20805 Mautic Arbitrary File Upload 2
• IPS: 20806 Mautic Arbitrary File Deletion

Remediation Recommendations

Although the working POC is not released by the original researcher as well as we were not able to execute the code in our test environment, given the possibility of misconfiguration allowing the access to php scripts, the users are strongly encouraged to update their instances to void the risk, as mentioned in the vendor advisory.

Relevant Links

• Vendor advisory
• Information provided by the vulnerability reporter