Blind SQL injection with Acunetrix Vulnerability Scanner

Question

I'm trying to analyse the test results for blind SQL injection using Acunetrix Vulnerability Scanner.

URL encoded POST input address was set to 
if(now()=sysdate(),sleep(0),0)/*'XOR(if(now()=sysdate(),sleep(0),0))OR'"XOR(if(now()=sysdate(),sleep(0),0))OR"*/

Tests performed: 
if(now()=sysdate(),sleep(6),0)/*'XOR(if(now()=sysdate(),sleep(6),0))OR'"XOR(if(now()=sysdate(),sleep(6),0))OR"*/ => 12.062 s

HTTP headers sent to POST were:
address=if(now()%3dsysdate()%2csleep(0)%2c0)/*'XOR(if(now()%3dsysdate()%2csleep(0)%2c0))OR'%22XOR(if(now()%3dsysdate()%2csleep(0)%2c0))OR%22*/&

If we supply any value to address variable data is getting inserted to tables. Is there any way to modify the header data for the address variable so that instead of storing data, we can retrieve the data and perform select operations and get to know about the internal schema?

It would also be really helpful if someone could help me in understanding the internals behind this statement:

if(now()=sysdate(),sleep(0),0)/*'XOR(if(now()=sysdate(),sleep(0),0))OR'"XOR(if(now()=sysdate(),sleep(0),0))OR"*/

Answer 1

The statement

if(now()=sysdate(),sleep(6),0)/*'XOR(if(now()=sysdate(),sleep(6),0))OR'"XOR(if(now()=sysdate(),sleep(6),0))OR"*/

basically tries three different injection points at once.

1. The direct one

    if(now()=sysdate(),sleep(6),0)/*...*/

If the input would be directly interpreted (without any escape characters) this sql would be triggered. The rest of the input string would be commented out.

2. Single quotation marks '..'

    ..'XOR(if(now()=sysdate(),sleep(6),0))OR'..

If the input is encapsulated in the statement with single quotation marks, the characters at the beginning and the end will break out of the context and the sql between them will be interpreted.

3. Double quotation marks ".."

    .."XOR(if(now()=sysdate(),sleep(6),0))OR"*/

Same as with the single quotation marks but works for inputs that are encapsulated in double quotation marks.

What the query might look like

If it is PHP that builds this MySQL statement, it might look like one of the following ones (depending on the case that triggers it):

sql = "INSERT INTO tbl_addresses (address,user) VALUES("+$_POST["address"]+",..)"
sql = "INSERT INTO tbl_addresses (address,user) VALUES('"+$_POST["address"]+"',..)"
sql = "INSERT INTO tbl_addresses (address,user) VALUES(\""+$_POST["address"]+"\",..)"

How it works

The statements are the same for each injection case.
It first compares if the return value of the "now" function matches that of the "sysdate" function. If that is the case (and it should be), the "sleep" function will be called with a time of either 6 or 0 seconds, resulting in the delay that you observed.

It is possible to exploit this as a purely blind SQL injection. A tool like sqlmap will help you with that, as it would take quite a lot of time if you do it by hand.
What it will basically do (in simplified form), is issue statements like:

if ( nth_character_of(password) == "a" , sleep(6), 0)

Where "nth_character_of" will be a database specific function that picks a character from a string and "password" will be a query that returns whatever value you want to retrieve from the database. It will also use an optimized method to find the correct characters.
If sqlmap experiences a delay it will know that the compare was correct and iterate further.

Narrowing it down

You can try to supply each of the three injection cases separately and have a look which one results in the delay. This way your injection string becomes much shorter and easier to modify and understand.

What you could try

If the value is indeed returned in the frontend, as you said in a comment under another answer, that SQL injection is not purely blind.
You might be successfull trying to insert your value directly like that:

version()/*'+version()+'"+version()+"*/

to retrieve the version in the frontend or with your query in all three places like:

(select password from users LIMIT 1)/*'+(select password from users LIMIT 1)+'"+(select password from users LIMIT 1)+"*/

The one with the custom query might not work depending on the encoding that in needed in this specific application but it is worth a try.

Answer 2

[NOTE: see comment thread - there is actually sql injection here, as demonstrated by the 12 second round trip time]

If that statement is actually being inserted into the address column, then you likely do not have a sql injection there - at least not one exploitable by that particular string.

It looks like it is trying to cause a pause in execution that is detectable by the exploit framework - because it is blind (not data returned back), it is difficult to tell from the outside if it is working. That's why the sleep.

However, an injection happens not when data is put in the right place (if someone puts this in the address field, you'd expect it to end up in the address column), but when the data is instead interpreted as code. From what you are saying, that isn't happening. Please clarify if I misunderstood.