Hi!

While I believe I know something about SQL Injection I have not found any 
publications related to way of abuse I am going to describe here. Somewhat it 
is not new at all but it seems to work in many weird situations.

Currently all penetration testers efforts seem to be focused on "blind 
hacking". Penetration tester can get free access to SQL subsystem and execute 
any commands but not able to get any other result back than error messages 
(or even not them). There are many publications describing how to fingerprint 
databases in blind. This posting just adds one more way.

Often I have found web sites, which also include banks and other usually 
not-so-bad-security sites which are vulnerable to blind SQL Injection. 

My example uses MySQL because this seems to be most used database on the web 
and also I know it best. Meanwhile similar techniques can apply to others. In 
every SQL there is a one "feature" which is actually very nice. It allows to 
use comments in SQL clauses like this:

SELECT * FROM table /* foo */
In MySQL, there is a extension to it which allows insert MySQL specific code 
in way:

SELECT /*! SQL_NO_CACHE */ FROM table

Comments shown above treated as comments in every database except MySQL. MySQL 
takes a look inside of comments and may change his behaviour. For example, 
this gets executed only, if MySQL is version 4.0.0 or higher:

SELECT /*!40000 SQL_NO_CACHE */ FROM table

It seems bit unusable but in many situations I have found it working through 
SQL injection holes when other techiques are not very useful. And this can be 
extremely useful for penetration tester to find out database in use and his 
version in blind:
Just trying
http://foo/web.php?table=38  I get normal screen
http://foo/web.php?table=38/*%20s*/ I get normal screen
http://foo/web.php?table=38/*!%20s*/ I get different screen because syntax 
error in comments - WOW MySQL is in use!
http://foo/web.php?table=38/*!30000%20s*/ same. MySQL is at least 3.x.x
http://foo/web.php?table=38/*!40000%20s*/ same. MySQL is at least 4.x.x
http://foo/web.php?table=38/*!50000%20s*/ Normal screen. MySQL is below 5.x.x
http://foo/web.php?table=38/*!40020%20s*/ Normal screen. MySQL is below 4.0.20
http://foo/web.php?table=38/*!40017%20s*/ broken screen. at least 4.0.17
http://foo/web.php?table=38/*!40018%20s*/ Normal screen. MySQL is below 4.0.18

We can conclude that MySQL running on site is 4.0.17.

Stupid? Yes. But it works really often. This is useful information because 
then we may know if we have interest to database or not. In MySQL for example 
all series (3.x.x,4.x.x and 5.x.x) have VERY different functionality. It is 
good to get information about it so easily. 

Another, independent idea. This works on most systems without change. Look at 
default behaviour of MySQL database engine:

mysql> select 9e0;
+-----+
| 9e0 |
+-----+
|   9 |
+-----+
1 row in set (0.02 sec)

mysql> select 9e2;
+-----+
| 9e2 |
+-----+
| 900 |
+-----+
1 row in set (0.00 sec)

Most language interpreters are trying to guess something about their input. I 
have seen cases when input gets validated against length and passed. So I can 
freely pass 9e9 to some database query in backend. PHP guys often suggest 
using functions like is_int($_GET['foo']). Yes, it is int! and it is 3 chars 
long. But it may take your database server down. I had nice penetration 
testing case when there was nearly impossible to get anny error message from 
the system. Finally I managed to send some 9e999 somewhere as input which 
leaded message similar "PHP timeout of 30 seconds in somehing.inc". Who works 
for penetration testing knows how important is any information about system 
internals. I was able to download this INC file which leaded to data leak.

About me:

Running company which does some specialized software for secure web 
applications. We also sometime do penetration testing and security 
consulting. In past I have developed e-banking solutions to different big 
banks, worked for MySQL AB as security man and have consulted Fortune 500 
companies.


Disclaimer: This is not related to MySQL in any way. Bug is in programmers who 
still haven't learned how to treat user input. magic_quotes in PHP just do 
mess giving false sense of security. Don't blame me on that. I am just a 
messenger.