Overview

The traditional in-band method in INSERT, UPDATE injections would be by fixing the query. For example in INSERT statements one can simply fix the query, comment out the rest and extract the data once it is echoed out by the application. Same goes with the UPDATE statement, but only if the query has more than one column we can fix the query. What if we face a situation where UPDATE or INSERT has one column or simply we don’t know the exact query to fix? What if mysql_error() is not echoed out?
Let’s look at the following scenario. For simplicity’s sake let’s not make things complex. The updated username is also echoed back to us. How can we inject in this scenario?

$query = "UPDATE users SET username = '$username' WHERE id = '$id';";

The parameters are as follows for the update query.

username=test&id=16 

Recently I was researching on different in-band and out-of-band techniques we can apply in these situations.
To understand my technique let’s look at how MySQL handles strings. Basically a string is equal to ‘0’ in MySQL. Let me prove it.

mysql> select 'osanda' = 0;
+--------------+
| 'osanda' = 0 |
+--------------+
|            1 |
+--------------+

mysql> select !'osanda';
+-----------+
| !'osanda' |
+-----------+
|         1 |
+-----------+

What if we add digits to a string? It would be same as adding a value to 0.

mysql> select 'osanda'+123;
+--------------+
| 'osanda'+123 |
+--------------+
|          123 |
+--------------+

(more…)

Overview

Out-of-band injections are very well researched when it comes to MSSQL and Oracle. But in MySQL I noticed that this topic is not well researched. I thought of researching about this topic based on my experiences in SQL injections. For this purpose we can take advantage of functions such as load_file() and select … into outfile/dumpfile. Apart from that we can also steal NetNTLM hashes and perform SMB relay attacks. All this is possible only in MySQL under Windows.

What is Out-of-Band Injection?

These attacks involve in alternative channels to extract data from the server. It might be HTTP(S) requests, DNS resolutions, file systems, E-mails, etc depending on the functionality of the back-end technology.

Limitations in MySQL

In MySQL there exists a global system variable known as ‘secure_file_priv’. This variable is used to limit the effect of data import and export operations, such as those performed by the LOAD DATA and SELECT … INTO OUTFILE statements and the LOAD_FILE() function.

• If set to the name of a directory, the server limits import and export operations to work only with files in that directory. The directory must exist, the server will not create it.
• If the variable is empty it has no effect, thus insecure configuration.
• If set to NULL, the server disables import and export operations. This value is permitted as of MySQL 5.5.53

Before MySQL 5.5.53 this variable is empty by default, hence allowing us to use these functions. But in the versions after 5.5.53 the value ‘NULL’ will disable these functions.
To check the value of this variable you can use any of these methods. The ‘secure_file_priv’ is a global variable and it’s a read only variable, which means you cannot change this during runtime.

select @@secure_file_priv;
select @@global.secure_file_priv;
show variables like "secure_file_priv"; 

(more…)

Overview

Starting from MySQL 5.5 and above the default storage engine was known as the InnoDB. In MySQL versions 5.5 and above if you do a “select @@innodb_version” you can see the version of the InnoDB, which is almost same as your MySQL version.

But in MySQL 5.6 and above I noticed 2 new tables by InnoDB. “innodb_index_stats” and “innodb_table_stats”. Both these tables contains the database and table names of all the newly created databases and tables.
The MySQL documentation explains these two tables as follows.

The persistent statistics feature relies on the internally managed tables in the mysql database, named innodb_table_stats and innodb_index_stats. These tables are set up automatically in all install, upgrade, and build-from-source procedures.

For injection purposes let’s take the “innodb_table_stats” table. Unfortunately InnoDB doesn’t store columns.

If you simply do “show tables in mysql” you can view this from your localhost.
(more…)