Using Burp to Exploit Blind SQL Injection Bugs

In the Using Burp to Detect Blind SQL Injection Bugs article, we examined a few possible means of detecting blind SQL injection vulnerabilities. In this article we go one step further and exploit the vulnerability we discover in the Boolean Condition Injection section of the preceding article. Additionally we explain how to use SQLmap with Burp and escalating a database attack to achieve command injection.

Using Burp Intruder to Exploit Blind Bugs

Previously we had detected a blind SQL injection bug in a intentionally vulnerable training web application.

In the example we are looking for the pin number that corresponds with the cc_number in the screenshot.

To find the pin we could alter the number in the SQL statement and wait for the application to produce a positive "True" response.

To help speed up this task, we can use Burp Intruder to automate the process.

Right click anywhere on the request and click "Send to Intruder".

 

In the Intruder "Positions" tab, use the buttons on the right of the panel to clear any existing payload position markers and add markers around the pin number.

 

In the Intruder "Payloads" tab, set the appropriate payload type and payload options.

In this example we wish to inject each possible pin number from 0000-9999.

Then click the "Start attack" button in the top right of the Intruder console.

 

Starting the attack will open the "Intruder attack" window.

We can use the Grep - Match function in the "Options" tab.

We are looking for an indication that the application has procuced a "True" response.

In this example a "True" response would be signified by the application showing us the "Account number is valid" message.

 

After applying the "Grep - Match" we can see that the payload "2364" produces a "True" response from the application.

 

We can confirm the payload is correct and that we have found the correct pin number by submitting the payload in to the form on the page.

 

Injecting System Commands Via SQL Injection

A successful exploit of a SQL injection vulnerability often results in the total compromise of all application data.

You may suppose, therefore, that owning all the application's data is the finishing point for a SQL injection attack. However, there are many reasons why it might be productive to advance your attack further.

One of the most dangerous methods of escalation is command injection.

In this example we explain the xp_cmdshell function in Microsoft SQL Server.

 

As shown above, it is essential to understand the database you are attacking when attempting to escalate a vulnerability, as every database contains various ways to escalate privileges.

xp_cmdshell allows users with DBA permissions to execute operating system commands in the same way as the cmd.exe command prompt.

 

You should first confirm the presence of an SQL injection vulnerability using one of the methods prescribed in the previous tutorial.

 

You can then attempt to use a stored procedure to execute operating system commands.

 

 

However, most instances of Microsoft SQL Server encountered on the Internet will be version 2005 or later. These versions contain numerous security features that lock down the database by default, preventing many useful attack techniques from working.

However, if the web application's user account within the database has sufficiently high privileges, it is possible to overcome these obstacles simply by reconfiguring the database.

If xp_cmdshell is disabled, it can be re-enabled with the sp_configure stored procedure.