We’re going to need a target site for this so I’m going to use a vulnerable web application I’ve pulled down from pentesterlab.com.
For reference, this is the From SQLi Injection to Shell exercise you can find here: http://pentesterlab.com/exercises/from_sqli_to_shell/
Spin the webserver up in your favorite virtual environment; I use VMWare, but this works just as well in VirtualBox. Just boot the LiveCD in an empty virtual machine and you’ll be greeted with a command prompt.
Type “ifconfig” and press enter. This will present you with network information for the virtual machine.
Make a note of the IP Address assigned to the eth0 interface. The IP will most likely be different depending on your virtual environment; it is most often assigned by the environment’s DHCP server.
Now head back to BurpSuite and make sure the IP address is in your target scope.
Let’s see what the site looks like by navigating to the page in our browser.
If you see this page, you’re in business. Now make sure that Burp is intercepting requests and let’s get started with Repeater.
Click on the “Home” link at the top and make sure you capture the request and response in BurpSuite.
Okay, let’s take a more in-depth look at Repeater.
Repeater can seem a little daunting at first glance since it looks like you have to craft a request to the server from scratch. But never fear! BurpSuite makes it easy to throw requests into Repeater from the proxy, and that’s exactly how I use it when doing assessments. First, let’s send a request to the server by clicking on a link that will give us some good fodder for manipulation. Let’s go to one of the blog pages. Click the “test” link in the navigation bar and take a look at the request.
You’ll notice we have the parameter “id” to tamper with in this request. Now we could tamper with the parameter, send the request to the server, see the response in the browser, go back, rinse and repeat, but that can be extremely time consuming. As an alternative, we can send this exact request to Repeater by right-clicking anywhere in the request and clicking “Send to Repeater”.
You should notice that your Repeater tab begins flashing orange.
Go ahead and click on the tab; you’ll see your entire request copied over.
If you click “Go”, you can see the response rendered to the right.
Now you can tamper with the request to your heart’s content. Continue to click “Go” to see how the response changes based on your input.
Let’s see what adding a single quote might get us. Add a single quote after the number 1 and click “Go”.
You will notice this site is vulnerable to SQL injection, and by adding the single quote we are able to see a SQL error on the page. You can also click the “Render” button in the response tab to see a rough HTML render of the page.
The render function is not a full-fledged browser so it may render a bit wonky. If you don’t see the error immediately, scroll around in the Response window. On this particular web application, Burp renders the content to the right of the Title.
You’ll notice that this error is also visible on the HTML portion of the page.
Now that we know the application is vulnerable to SQL injection, we can use Repeater to continue to send requests. We don’t have to continually go through the proxy to see if we can go further down the rabbit hole.
Explaining the SQL injections I’m using in this guide is beyond the scope of this article, but I encourage you to go through the manual provided on pentesterlab to better understand what we’re doing here. For now, let’s use one of the examples from pentesterlab’s guide as an entry point and see how the response differs.
SPOILER ALERT! I’m using a portion of the guide on page 29 of the “from_sqli_to_shell.pdf” file included on pentesterlab.com that provides a payload for us to use. If you want to figure the injections out on your own, please read through the SQL injection guide provided in the pentesterlab.com link and use Burp along the way to help with your testing.
Here, instead of a single quote, I’m inserting a simple SQL statement as suggested:
This attempts to list all of the table names from the information_schema.
You’ll see we get the same error the guide mentions.
Let’s try the next step the guide suggests.
Using a new injection, we are able to continue to get information from the server.
I won’t be going through the entire guide on pentesterlab.com (They do a great job already!); Repeater simply provides another avenue to achieve the same results. You can see how using Repeater can speed up the process by giving you a rapid fire way to manually test each request without going through the browser every single time.
It goes without saying that this can be used for more than just parameter tampering. You can edit any portion of your request to the server over and over again, providing a great way to manipulate parameters, headers, or any part of the HTTP request. PLUS if you ever need to go back, Burp gives you some nifty little buttons at the top of Repeater to move between your previous requests.
I hope this guide helps to get your assessments up to lightning speed and makes your request manipulation a little bit easier.