Encoding SQL injection attacks is nothing new and automated tools like SQLmap will more than likely find flaws via this method.  That being said I was combing through some of my old docs and found what I think is a decent explanation how this type of attack leads to SQL injection.

I’ll be demonstrating this on an app called GetBoo that is installed on the OWASP broken web app project so feel free to download the virtual image they provide and begin playing with GetBoo and other similar broken applications.  Inside GetBoo we look for some SQL injection, unauthenticated vulnerabilities are always best if you can find them. Going to the home page of GetBoo we see there are comments posted to a bookmark. Hovering over the comment link and also clicking on the comment link takes us to http://172.16.114.218/getboo/comment.php?bID=2, keep in mind your IP address will be different. In Burp let’s send this request to repeater so that we can analyze if the bID parameter is vulnerable to SQL injection. First thing we’ll want to do is throw in the classic single quote, doing this responds back with a 500 server error.

This does not mean the application is vulnerable to SQL injection but it is an indicator that the application can’t handle the single quote without failure. Let’s look at a request that handles the single quote just fine, at the home page you can click on “Popular Tags”, after that click on sort by “Popularity”. Send that request to repeater in Burp and instead of “popularity” for the sort parameter place a single quote in for the value of sort. You will notice that the application handles the request just fine with a 200 OK status.

The other classic SQL injection string ‘ or 1=1 also gives us a 500 error, most of those classic ‘ or 1=1 attacks are followed by a – which is a comment in Microsoft SQL server. In this example we’re running MySQL so if we wanted to follow it up with a commend it would look like ‘ or 1=1#.

Still getting a 500 error. Let’s try another technique which is to finish out or complete the request with a single or double quote after a valid parameter value.

So finishing off the request with a single quote and appending the and 1=1 still results in the same error. You can try the same attack without the single quote to see the affect as well.

Just because we get a 200 OK doesn’t mean that our SQL injection was successful, if you put other meaningless data besides 1=1 you may not notice a change.

Here we see it doesn’t matter what we append after a valid value for the bID parameter because the application is simply ignoring anything after, so this isn’t going to lead us down the path to SQL injection at least for this particular parameter so somehow we need to focus on finishing off the query with either the single quote or another technique.

With GetBoo installed locally you can gain access to the Mysql database logs which is extremely helpful when trying to debug a successful SQL injection attack of course in the real world this is unlikely to happen but if you want to perform better testing on your application then giving application testers access will go a long way.

Let’s go back to our single quote attack and see the output from the database query.

Here we see that it is keeping the request as we sent it. In this case if the attack string bID=2’ and 1=1 is sent you get the same output from the Mysql database logs, this means the application is discarding anything after the single quote. One way of getting around that may be to encode your attack string. This time we will URL encode our attack string, so instead of the request being bID=2’ and 1=1 it will now be bID=2 %27%20%61%6e%64%20%31%3d%31. Once we run that the following shows up in the Mysql logs.

Encoding the attack made all the difference although we still get a 500 error when making the request so we’ll need keep hammering away.

Not all is lost though because notice in the Mysql output that a single quote is appended on the 1=1 even though we didn’t specify a single quote at the end of the attack. So instead of using numeric values we need to use strings and quote those strings but leave off the final quote as the application will put that in place for us. So in this case we can use the attack string bID=2’ and ‘blah’=’blah and the URL encoded value is bID= %32%27%20%61%6e%64%20%27%62%6c%61%68%27%3d%27%62%6c%61%68.

Great success we were able to get a meaningful 200 response to our attacks. In the output from Mysql we can see that it properly parsed our attack as a valid SQL statement.

Now that we confirmed that we’re actually making proper database requests we can begin to pilfer the contents of the database.

Just a quick tip I don’t see documented a bunch of places, when you want to feed metasploit a list of targets in a file you need to use the following syntax.

Below is a screenshot for context.

Just a quick one liner, you can also incorporate this into a huge sweep of the network which will hopefully identify MySQL databases with weak or default credentials.

I use these command line switches to automate the process, I’ve had some good results.

Explanation

This post will explain how to setup Burp so that you can use Python to write Burp extensions. Burp has an API that allows for extensions which add to the functionality of Burp. The Burp suite itself is written in Java so Burp natively supports Java extensions but through Jython you can now use Python scripts to build extensions. This comes in handy if you are more comfortable using Python day to day.

The first thing you’ll need to do is download Jython, I downloaded the traditional installer which will end in a JAR extension. In order for the installer to work you’ll need to have already installed the Java runtime environment (JRE). Now double click the JAR file to install.

I chose the standard installation type.

Next it should hopefully recognize where your JRE is installed.

Hopefully you get to the last window during the install process that says congratulations.

Now that Jython is installed correctly we need to fire up Burp and configure it to use Jython for our Python scripts. Once in Burp go to the Extender tab then the Options. There you will see a section labeled “Python Environment”, simply point to the location of your Jython JAR file. I accept the defaults during install and my location was C:\jython2.5.4rc1\jython.jar. See screen shot below.

After this we are ready to load our first Python extension to Burp. Go back to the Burp extension page and download the HelloWorld zip fie which contains a Python example. Under the Extensions tab you can click “Add”, choose the Python extension type and simply pick the HelloWorld.py example. After loading the extension you should see the window below.

You’ll also see some errors generated in the Errors tab.

This is normal as the HelloWorld.py example is meant to show you what errors would look like as well. There you have it you have just loaded your first Python extension in Burp. Hopefully I will follow up with extensions I find useful and how they can help in performing application security assessments. Feel free to contact me or leave feedback.