Introduction – application enumeration As security auditors, we daily encounter solutions whose exact structure or logic is unknown to us. Therefore, one of the first and fundamental steps in conducting a security audit is the process of gathering information about the solution being tested. In this case, the story concerns a web application.

While enumerating available resources in the tested application using the ffuf tool, we managed to locate the /panel/ directory. Further attempts to identify the contents of this directory revealed the presence of a download_file.php file, which returned a blank page in the browser. A simple attempt to provide a basic parameter in the form of an HTTP GET id revealed that the application successfully processed it, returning the difference in the response, as demonstrated below.

• Example HTTP request: • Application response: At this stage, we managed to locate an endpoint accessible to the application without authorization, which returns appropriate content depending on the value sent for the GET id parameter.

It will later be revealed that this is a feature of the administration panel that allows privileged accounts in the system to download files. Further analysis – locating the Blind SQL Injection vulnerability Manipulation of the GET id parameter revealed that, depending on the submitted identifier, the application returns the contents of the assigned file. Further testing determined that including additional SQL logical syntax such as OR or AND directly affects the returned message – bingo, thus resulting in a blind SQL injection vulnerability.

In short: Blind SQL Injection doesn't return any direct database content to the attacker nor display SQL errors. Based on the application's response, we can only determine whether the query is TRUE or FALSE. Therefore, through trial and error and repeated queries, the attack could proceed as follows:

• Is the database name ten characters or less? Answer: True or False.
• Is the first letter of the current database name "A"? Answer: True or False.
• Are there twenty or fewer tables in the database? Answer: True or False.
• And so on...

So, returning to the application being tested, the attack vector is demonstrated below.

1. Sending an HTTP request to return a TRUE message (one equals one): 2. In response, the application returns the correct file name with ID no. 1: 3. Then, for the same identifier, a query is sent to return FALSE statement (one does not equal two): 4. The application does not return the file name for the query from the previous step: At this stage, the sqlmap tool was used to automate the tedious process of querying the database. Based on the tool's results, we were able to recreate the database structure, including the PostgreSQL tables and columns used. As expected, the table containing user accounts in the application was called user.

So let's go a step further. Even though we don't see the direct results for SQL queries, there's still a chance that writing to the database is possible if it supports nested queries (stacked queries). By enumerating the database, we were able to determine where user data (including administrators) is stored, and that passwords are encrypted using the bcrypt method.

Based on the above information, the following SQL query was prepared to change the administrator password to a new one (hacked): However, this query was unsuccessful. Analysis of several failed attempts revealed that the application does not accept HTTP requests containing apostrophes or quotation marks. However, using decimal format and SQL concatenation, it was possible to create a target SQL query that was not blocked: At this stage, all that is left is to log in to the administrator account using the new password: As a result, we have been successfully logged in: After carefully reviewing the available administrative functions, it was determined that the endpoint serving as the attack vector (/panel/download_file.php) is used for internal file sharing by application administrators. ” The cherry on top” – reduntant PostgreSQL user permissions Despite gaining access to the administrator account, I decided to return to the database itself and its configuration. To better understand the audited environment, it's always worth reviewing the permissions available to the user being audited – excessive permissions could potentially lead to reading and writing to files on the HTTP server being tested, as well as the operating system itself.

For this purpose, the following SQL command was prepared to return a list of users with assigned roles in PostgreSQL: By automating the process of reading the results for the above SQL query, sqlmap tool was used which returned the following response: Therefore, the database user from which the previous database queries were executed has the following roles assigned in PostgreSQL:

• rolsuper,
• rolinherit,
• rolcreaterole,
• rolcreatedb,
• rolcanlogin.

Based on the granted permissions, we could then read files available on the system (e.g., using the pg_read_file() or COPY FROM PROGRAM functions) or potentially execute a command on the system shell (e.g., using the COPY TO PROGRAM function). Executing a command on the shell has critical security implications, allowing full access to source code, authorization credentials, and configuration files. Wrap up By effectively enumerating the files available in the tested application, it was possible to locate a path accessible without any authorization within the application. Subsequently, a simple analysis of HTTP requests revealed the presence of a Blind SQL Injection vulnerability. By exploiting the identified vulnerability, access to the administrator account on the platform was gained, and the PostgreSQL user himself was found to be operating with excessive privileges.

It is worth noting that during the analysis of the database content, it was also possible to locate the presence of authorization data for many services, including email servers, SIP servers, API platforms and passwords for PGP keys.

The above story, which took place in a real customer environment, brings the following conclusions:

• The application should thoroughly verify access attempts to all its elements, blocking access to selected application functions without presenting a valid login session (in this case, the function for downloading files from the admin panel).

• All data submitted by the user should always be thoroughly verified and filtered, especially for sensitive functions such as database queries. A safe alternative is the use of parameterized queries. It is also recommended to disable support for nested queries.

• Permissions should be assigned based on the principle of least privilege – the user should have access only to the permissions necessary for the proper functioning of the given solution, without redundant privileges.