In Chapter 6, Exploitation – Low Hanging Fruits, we exploited an error-based SQL Injection and now we will identify and exploit a Blind SQL Injection using Burp Suite's Intruder as our main tool.
- Browse to
http://192.168.56.102/WebGoatand log in withwebgoatas both the username and password. - Click on Start WebGoat to go to WebGoat's main page.
- Go to Injection Flaws | Blind Numeric SQL Injection.
- The page says that the goal of the exercise is to find the value of a given field in a given row. We will do things a little differently but let's first see how it works: Leave
101as the account number and click Go!.
- Now try with
1011.
Up to now, we have seen the behavior of the application, it only tells us if the account number is valid or not.
- Let's try an injection as it is looking for numbers and probably using them as integers to search. We won't use the apostrophe in this test so submit
101 and 1=1.
- Now try
101 and 1=2.
It looks like we have a blind injection here, injecting true statement results into a valid account, with a false one the Invalid account number message appears.
- In this recipe, we will discover the name of the user connecting to the database, so we first need to know the length of the username. Let's try one, inject:
101 AND 1=char_length(current_user) - The next step is to find this last request in BurpSuite's proxy history and send it to the intruder, as shown:
- Once sent to the intruder, we can clear all the payload markers and add new one in the
1after theAND, as shown:
- Go to the payload section and set the Payload type to Numbers.
- Set the Payload type to Sequential, from 1 to 15 with a step of 1.
- To see if a response is positive or negative, go to Intruder's options, clear the Grep-Match list and add Invalid account number. and Account number is valid.
We need to make this change in every intruder tab we use for this attack.
- In order to make the applications flow, select Always in the Redirections section and check on Process cookies on Redirections.
We need to make this change in every intruder tab we use for this attack.
- Start the attack.
It found a valid response on the number 2, this means that the username is only two characters long.
- Now, we are going to guess each character in the username, starting by guessing the first letter. Submit the following in the application:
101 AND 1=(current_user LIKE 'b%').We chose
bas the first letter to get BurpSuite to obtain the request, it could have been any letter. - Again, we send the request to the intruder and leave only one payload marker in the
bthat is the first letter of the name.
- Our payload will be a simple list containing all the lower case and upper case letters (from a to z and A to Z):
- Repeat steps 13 and 14 in this intruder tab and start the attack, as shown here:
The first letter of our user name is an S.
- Now, we need to find the second character of the name so we submit
101 AND 1=(current_user='Sa')to the application's textbox and send the request to the intruder. - Now our payload marker will be the "a" following the S, in other words, the second letter of the name.
- Repeat steps 18 and 19. In our example, we only used capital letters in the list since if the first letter is a capital, there is a high chance that both characters in the name are capitals also.
The second character of the name is A so the user of the database that the application uses to make queries is SA. SA means System Administrator in Microsoft's SQL Server databases.
Exploiting a Blind SQL Injection takes up more effort and time than an error-based injection; in this recipe we saw how to obtain the name of the user connected to the database while, in the SQLi exploitation in Chapter 6, Exploitation – Low Hanging Fruits, we used a single command to get it.
We could have used a dictionary approach to see if the current user was in a list of names but it would take up much more time and the name might not be in the list anyway.
We initially identified the vulnerability and revealed the messages telling us whether our requests were true or false.
Once we knew there was an injection and what a positive response would look like, we proceeded to ask for the length of the current username, asking the database, is 1 the length of the current username, is it 2, and so on, until the length is discovered. It is useful to know when to stop looking for characters in the username.
After finding the length, we use the same technique to discover the first letter, the LIKE 'b%' statement tells the SQL interpreter whether or not the first letter is b; the rest doesn't matter, it could be anything (% is the wildcard character for most SQL implementations). Here, we saw that the first letter was an S. Using the same principle, we found the second character and worked out the name.
This attack could continue by finding out the DBMS and the version being used and then using vendor-specific commands to see if the user has administrative privileges. If they do, you would extract all usernames and passwords, activate remote connections, and many more things besides
One other thing you could try is using SQLMap to exploit this kind of injection.
There is another kind of blind injection, which is the Time-Based Blind SQL Injection, in which we don't have a visual clue whether or not the command was executed (as in valid or invalid account messages); instead, we need to send a sleep command to the database and, if the response time is slightly longer than the one we sent, then it is a true response. This kind of attack is really slow as it is sometimes necessary to wait even 30 seconds to get just one character. It is very useful to have tools like sqlninja or SQLMap in these situations (https://www.owasp.org/index.php/Blind_SQL_Injection).