What does this SQL injection do?

Question

In short, through an old asp site, I ran someone who found an unfiltered URL parameter and was able to run this request. I'm trying to figure out what it is, though ...

The request should look like this:

select * from reserve where id = 345 

the one that was running was:

 select * from reserve where id = 345 and ascii(substring((select concat(user,0x3a,password,0x3a,host) from mysql.user limit 0,1),17,1))=53 

I'm really not sure if this will work out. Any input?

Answer 1

Perhaps this depends on whether the web application accesses the database as root . Removing the ascii(substring()) parts ascii(substring()) returns the following when launched as root:

 mysql> select concat(user,0x3a,password,0x3a,host) from mysql.user limit 0,1; +--------------------------------------+ | concat(user,0x3a,password,0x3a,host) | +--------------------------------------+ | root:<rootpw-hash>:localhost | +--------------------------------------+ 

After a successful trial, they may try to get the contents of mysql.user , from which they can begin to crack passwords against rainbow tables.

Answer 2

SQL tries to read user data from the My-Sql user table, which usually contains a list of users and hosts that are allowed access to this my-sql server.

It seems to me that perp is trying to trick mysql into dropping the contents of the user table so that they can record the password hashes offline and dcrypt them to find valid logins.

If your web application uses a login that will allow access to the mysql user table, this is a serious security flaw, if it uses a login that only permits the tables required for the application, then no information can be obtained.

Security Council . When setting up any database, it is vital that the application uses this with the login / access role, which provides it ONLY what it needs.

If your application only ever needs to read data and never modify it, then it should never have any privileges other than reading. You always need to double-check this, because most database systems will by default create user roles for a given database with full read, create, and modify access.

Always create a specific user, just for this db and / or collection of tables, and always provide that user with the absolute minimum that is required if your application is then hacked by attacking a script with several sites, most of them are going to gain access too - this is one specific database.

Answer 3

The second part of the condition is really strange: it searches for mysql credentials and processes them as follows:

• concat (user, 0x3a, password, 0x3a, host) will be something like 'someUser: hisPass: localhost'
• the specified string will be split into smaller
• the specified string is converted to ascii code (you can learn this from legacy languages ​​like ord ())
• conversion result is compared with 53 integer

I believe that the first part of the WHERE statement ( id = 345 ) will always return true , and the second is too specific, so the whole query will probably return an empty result all the time.

Answer 4

the request is apparently one of a set of them:

• by changing the starting position of the character and substring, and you can find out all the usernames and the corresponding password hashes (when the page looks as expected, you have a char matching)
• lets you know that the current user has access to the mysql schema.

Answer 5

Exploiting a sql injection does not necessarily immediately display the result of a query on the screen of an attacker, often the result is either an error or an error, or maybe the injection causes a measurable delay (for an attacker). thus, an attacker can get 1 bit of information per request.

By sending a lot of queries, iterating over string positions, performing a binary search on characters - or, as in this case, a linear search (which may indicate that the attacker does not understand what he is doing, but he will get in the end), he will be able to find all characters in the mysql root user password. (Which can be rude offline).