SQLIs still remain amongst the topmost vulnerabilities that if exploited can be the biggest nightmares for organizations. But as developers are getting more and more aware of security implications, basic SQLIs are getting much harder to find! But what about the complex ones?! Are the developers aware enough to prevent SQLIs that are time-based?
Putting up that point, I will move forward in the blog post, explaining what are time-based sqlis and how they can be easily exploited. I will also be writing about the importance of code review and how it can really ease up the process.
First of all, I want to give a special mention to codevigilant project and Anant sir for making me a part of this amazing project.
Let’s cover the basics
Heard of blind SQL injection? This variation of SQL injection happens where a true/false question has to be asked to the database which in result gives a bit different response.
Let’s understand with a small example. Suppose that there is a parameter id that is vulnerable to blind sqli.
http://example.com?id=1' AND '1'='1;
The above format gives us the output “Welcome”. However, If I change the payload to
http://example.com?id=1' AND '1'='2;
It won’t give any result. Why? because the 1 != 2 and the condition becomes false. The whole thing verifies the presence of SQLi.
Based on true-false conditions, you can build payloads that can enumerate the whole database information for you. Looking for Example? here’s one
http://example.com?id=1' AND (SELECT 'a' FROM users WHERE username='administrator')='a
Now if the user administrator exists in your database, this payload is gonna output “Welcome” [as the condition is true]. If a username is not present in db, it falsifies the result and you won’t get any output.
In a similar way, the password length for the username and the password can be brute-forced. Example payloads? here you go!
http://example.com?id=' AND (SELECT 'a' FROM users WHERE username='administrator' AND LENGTH(password)>19)='a
For brute-forcing the password, you will obviously have to take the help of Burp’s intruder.
That was blind sqli. We used a technique where triggering a database error gave a slightly different response. But what if both the true/false condition outputs the exact same response?
That’s where blind time-based SQLi gets in. With blind time-based sqli, one can incur time-based delays based on the condition set. Since SQL queries are synchronously processed by the application, delaying the SQL query will also delay the response. This allows us to infer the truth and based on response time, one can again enumerate everything from db to usernames/passwords.
If you want to do the hands-on labs, the best place to go is the portswigger sqli labs
I think that’s enough build-up for what I am going to cover next.
The 15 sqlis
As the title mentions, all the sqlis were blind time based. Since I was testing on wordpress plugins, I had the source code handy.
The patterns that usually led me to sqli were $_GET[‘id’] or $_POST[‘id’] being directly used in the query statement, without any prepared statements. These statements were sometimes Insert, Update. But majorly, I found blind time-based sqlis on the delete/remove functionality.
3 simple payloads that I used
- id=1-sleep(10) –> To confirm the presence of blind time-based sqli
- id=1-IF(1=1,SLEEP(10),0) —-> To check if the conditional statements are working fine
- id=1-IF(MID(VERSION(),1,1)=5,SLEEP(1),0) —> To confirm the database version
I have included one of the screenshot from the poc that that depicts a blind time-based sqli on the delete/trash functionality.
You can find similar PoC screenshots of time-based blind sqli here
Takeaways?
- If you have the source code and you are sure that it has straight sqli, never just give up on testing.
- Never forget to test for blind time-based sqli. You will get them in scenarios that you have never expected.
That’s all for this blog post. I hope you enjoyed reading it. Let me know about any feedback that you may have.
See you in the next one. Until then, happy hunting. š
