Blind SQL injection with conditional responses

In many cases of SQL injection, the application does not return the results of the injected query to the user’s browser, nor does it return any error messages generated by the database. In such a situation you can use many techniques to retrieve arbitrary data from the database. These techniques are based on the concept of using an injected query to conditionally trigger some visible behavior of the web application and then inferring required information on the basis of whether this behavior occurs.

Consider a vulnerable login function where the username and password fields can be injected into perform arbitrary queries.

SELECT * FROM Users WHERE username = ‘weiner’ and password = 'secret'

Suppose that you were unable to transmit the results of the injected queries back to the browser, You can still use a true case and a false case to observe the different behavior of the web application.

For example, submitting the following two pieces of input causes very different results.

weiner' AND 1=1 --
weiner' AND 1=2 --

In the first case, the application logs you in as the user weiner since the condition 1=1 is always a true case and it ignores the rest of the query. But in the second case, the login attempt fails, because 1=2 condition is always false.You can leverage this to control the application’s behavior by inferring the true case and false case of arbitrary conditions within the database.

Let’s solve the Lab exercise Blind SQL injection with conditional responses

Lab Exercise analysis

Vulnerability : Blind SQL injection

Vulnerable Parameter: Tracking cookie

Conditional response: ‘Welcome back’ message.

Vulnerable web application uses a tracking cookie to gather analytics about usage. All the requests to the web application includes a cookie header as follows:

TrackingId=u5YD3PapBcR4lN3e7Tj4

When a request that contains a TrackingId cookie is processed, the application determines whether the user is a known user using a SQL query like this:

SELECT TrackingId FROM tracking_table WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'

If the user is a known user, the application will display a ‘Welcome back’ message in the browser.

STEP #1

Confirm that the tracking cookie parameter is vulnerable to SQL injection.

You need to identify a noticeable behavior('Welcome back' message)in the web application in a true case and a false case of the query.

True case

SELECT TrackingId FROM tracking_table WHERE TrackingId=’XXX’ AND 1=1--

This query causes the database to go through each row of the tracking_table, evaluating whether the Tracking id ‘XXX’ is in the database and 1 is equal to 1.

Since 1=1 is always a true case, SELECT TrackingId will be evaluated. If TrackingId ‘XXX’ exists in the database, the query will return a value(TrackingId) and the application displays a 'Welcome back’ message.

False case

SELECT TrackingId FROM tracking_table WHERE TrackingId=’XXX’ AND 1=2--

Since 1=2 is always a false case, SELECT TrackingId will never be evaluated. So, whether the TrackingId ‘XXX’ exists in the database or not, the query will not return any value and the application will not display a “Welcome back” message.

We can observe that the application responds differently in a true case scenario and a false case scenario. Because of that, we can confirm that the tracking cookie parameter is vulnerable to SQL injection.

STEP #2

Confirm that the database contains a table called users.

You can use the following query to check whether there is any table called users in the database.

' AND (SELECT table_name FROM information_schema.tables WHERE table_name = 'users') = 'users'--

Above sub query will cause the database to go through each and every row of the information_schema.tables view, checking whether the table_name column has a value users in the database, if so return the value of the column table_name.

If the SELECT query returns the value users, the web application will return a ‘Welcome back’ message since 'users' = 'users' is always a true case.

Now we can say that the database contains a table called users.

STEP #3

Confirm that the username administrator exists in the users table.

You can use the following query to check whether the administrator user exists in the users table.

' AND (SELECT username FROM users WHERE username = 'administrator') = 'administrator'--

Since 'administrator' = 'administrator' is always a true case, We can get the 'Welcome back’ message. So we can confirm that the administrator user exists in the database.

STEP #4

Enumerate the password of the administrator user.

Find the length of the password.

' AND (SELECT username FROM users WHERE username = 'administrator' AND LENGTH(password > 1)) = 'administrator'--

Since the password contains more than 1 character, SELECT query returns the username of the administrator user. Since 'administrator' = 'administrator' is always a true case, the web application returns a ‘Welcome back' message.

In Order to find the length of the password, we have to send series of inputs as follows:

Therefore the length of the password is (n).

According to the above results, we can say that

1 < LENGTH(password) < 50

To find the exact length of the password, you can use the following technique.

So the length of the password is 20.

Find the characters of the password.

To determine the password of the administrator user, we have to send a series of inputs to test the password one character at a time.

' AND (SELECT SUBSTRING(password, 1, 1) FROM users WHERE username = 'administrator') = 'a'--

Since the password can be a

• Lowercase letter
• Uppercase letter
• Digit
• Special character

We need to check for all the possibilities.

Let’s get the first character of the password.

We can see that the first character of the password is k.

Let’s get the password.

Attack type: cluster bomb

This attack type is useful where an attack requires different and unrelated input to be inserted in multiple places within the request.

Number ranging: from 1 to 20

If you are a Burp Suite community edition user, This whole process will take hours to run. Instead of doing the bruteforce in Burp Suite community edition, you can do this using a python script.

You can get the python script from here.