SQL Injection whitebox approach (final part)

Dear readers, in parts 1 and 2, we worked on files and patterns identification, enabling database logging and sending requests with a custom python script.

In this 3rd and final part, we are going to check how to detect any working sql payload in the database logging file.

Recall : the default SQL database logging file chosen in our case is /var/log/mysql/mysql.log.

In web development sql queries mainly looks like:

select * from table_name where param = ‘something’ ;
select * from table_name where param like ‘%something%’ ;
select * from table_name where param = “something” ;
select * from table_name where param like “%something%” ;

In summary, the comparator starts whether by a quote or double quote, is followed by a % in a case of like operator or directly the string, ends by a quote or double quote depending on the initial character used. For these examples, successful SQL injection queries may look like :

select * from table_name where param = ‘something’’ ;
select * from table_name where param like ‘%something’%’ ;
select * from table_name where param = “something”” ;
select * from table_name where param like “%something”%” ;

We can note there is an extra quote or double quote added depending on the query written. These different ways to perform SQLi will be checked in the logging file using regex expressions.

2 expressions are going to be used :

[\'][%]?\w+\'[%]?[\']

[\”][%]?\w+\"[%]?[\”]

The first one will match any successful SQLi attempt with a single quote and the second one any successful SQLi attempt with a double quote. Both of them can be tested at https://regex101.com/ as the following pictures show:

The matches in these pictures are highlighted in blue. The full code to check the successful SQLi attempt is located at https://github.com/lucsemassa/sqli_detect/blob/main/check_sqli.py

After running the file as sudo (because sudo access is required to access the logging file) on the target system, we obtained the following result:

The successful SQLi attempt is %q_index_public'%'. As we explained in part 2, this means, the vulnerable parameter is q and the vulnerable file is named index_public.php.

In order to check the vulnerable query we have to identify the index_public.php file containing the q parameter. In our case, it is located at /var/www/html/ATutor/mods/_standard/social/index_public.php and the vulnerable query is at line 39 as the following picture shows.