GLPI 0.90.4 SQL Injection

GLPI version 0.90.4 suffers from a remote SQL injection vulnerability.

MD5 | c69a23b9f7146e1db3b123582497e405

# Exploit Title: Multiple SQL injection vulnerabilities in GLPI 0.90.4
# Date: 2016/09/09
# Exploit Author: Eric CARTER (in/ericcarterengineer - CS
# Vendor Homepage:
# Software Link:
# Version: 0.90.4
# Tested on: GLPI 0.90.4 running on a Debian 7, Apache 2.2.2, MySQL 5.5.49
# CVE : CVE-2016-7508

Multiple SQL injection vulnerabilities in GLPI 0.90.4 allow an
authenticated remote attacker to execute arbitrary SQL commands by
using the [ELIDED] character when the database is configured to use
asian encoding (BIG 5).

> [Affected Component]
The file ./inc/dbmysql.class.php defines the encoding the database
should use. This files uses the "SET NAMES" function which offers the
possibility to use a specific encoding.

> [Attack Type]

> [Impact Code execution]

> [Impact Escalation of Privileges]

> [Impact Information Disclosure]

> [Prerequisite]
The administrator of GLPI must have defined the variable
$dbenc='big5' in ./config/config_db.php to support asian encoding. It
will then be possible to do SQL injection in almost all the forms of
the application.

> [Attack Vectors]
For the proof-of-concept, the attacker targeted the
"Surname" form input in the User profile by adding the characters
A, (\xBF\x27) before the SQL code (the request must be sent using Western
encoding) :
A,', password=61529519452809720693702583126814 -- x

Once received by the server, the request will be sanitized, giving :
A,\', password=61529519452809720693702583126814 -- x

The value will then be sent to the database with a BIG5 encoding. Here is the
critical point, as BIG5 will see the string A,\ as a single asian character
encoded on two bytes. As the single quote isn't escaped anymore, the
SQL code will be executed and will set the password of every accounts
to the value
61529519452809720693702583126814 (=MD5 hash of "ximaz" string)

Related Posts