Sqlmap – crawl and discover SQL injections

September 7th, 2014

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

python sqlmap.py -u http://example.com --forms --batch --crawl=10 --cookie=jsessionid=12345 --level=5 --risk=3

Explanation

-u = URL

--forms = Parse and test forms

--batch = non interactive mode, usually Sqlmap will ask you questions, this accepts the default answers

--crawl = how deep you want to crawl a site

--cookie = put cookie in here if you want to do an authenticated scan

--level = different levels of tests, 1 is default and 5 is the most

--risk = different risk of tests, 1 is default and 3 is the most

Burp extension environment for Python

December 7th, 2013

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.

Burp suite tip / tutorial: History logs at the top

August 31st, 2013

When performing an assessment of a web application I’ll spend most of my time in the History tab under the Proxy tab quite a bit. By default Burp will append the latest request to the bottom of that History log which means that I have to keep scrolling down to see my latest request to the application. This can be annoying and it’s better if my latest request were at the top of the History log. Luckily this is an easy fix with the proper sort in the History tab, simply click on the first column which will keep your latest request at the top.

Burp suite tip / tutorial: renaming tabs

June 29th, 2013

This will be a quick and simple tip that you may not have been aware of, you can rename tabs within Burp. A friend of mine who works out of Raleigh turned me onto this. I find new sometimes obvious and hidden features in Burp all the time and this is one of them.

I find this feature handy especially in a large application as I can easily keep track of what I’m testing.  I use the tab renaming on the Repeater and Intruder functionality. In order to rename a tab simply double click the tab which will allow you to edit the tab.

Repeater before

Repeater after

Intruder before

Intruder after

Hope this simple tip helps you perform better application pen testing.

Burp suite tutorial / tip: determining cookie functionality

April 1st, 2013

When testing web applications you may come across an application that passes a ton of cookies along with each request. Cookies are used to maintain state within the application and typically only one cookie is needed within the application. There are times when other cookies are used as well and when testing web applications it may be difficult to determine what cookie is associated with session and functionality. Hopefully my technique of determining cookie functionality will also help others as well. Let’s get started with an example. I’m going to take a look at ubuntu forums as an example.

So configure burp to capture traffic and make a request to Ubuntu forums. Below is the screen shot of Burp making the first couple of requests to ubuntuforums.org.

Here we see that simply going to the forum home page without authenticating we get two cookies “bb_lastvisit” and bb_lastactivity”. We’re lucky in some sense as these cookies are fairly descriptive, often times cookies have nondescript names which makes it even more difficult to understand their functionality. Now let’s authenticate and see what other cookies come into play.

Now we have two additional cookies (bb_sessionhash and IDstack) that get submitted with each request. At this point it’s a safe bet to say that either IDstack or bb_sessionhash is responsible for handling session to ubuntu forums. One of the quick and easy ways to determine which cookie is truly used for session is to intercept a request that requires authentication, manually delete that cookie and see if you get kicked out of the application. Below is a screenshot of me performing that action.

In this example I clicked on my profile because some portions of the profile require authentication to view. So I deleted the IDstack cookie to see if it had any affect on session. After forwarding the request it did indeed bring me to my profile so the IDstack cookie isn’t responsible for handing the session. We can see this in the browser as shown in the screenshot below.

Next let’s try the getting rid of the bb_sessionhash cookie via the same method.

After the bb_sessionhash cookie is removed we do indeed loose the authenticated features of the “My Profile” page as seen below.

So now we have identified the cookie that maintains session for this application. It’s also a good idea to delete all the cookies except for bb_sessionhash or your particular cookie in question. I did go ahead and delete all the cookies except for bb_sessionhash and I maintained session so the other cookies have nothing to do with session in this instance. In this scenario you can wipe your hands clean knowing that you’ve correctly identified the cookie that properly handles the session but sometimes other cookies will appear within the same application when you stumble across other functionality. One example of this is when a web application has some reporting piece to it. I’ve seen where the reporting functionality may be a bolted on third party application that uses it’s on session handling which would call another cookie. Because of this I like to only pass the cookie that handled the initial authentication and see if any other functionality, a la reporting, gets broken with only the one cookie being passed. So what I like to do is set up a intercept rule that will only pass the initial authentication cookie and monitor what gets broken as I walk the application. To setup this rule go into the Options tab within the Proxy tab and create a “Match and Replace” rule to perform this. I add a rule with type of “Request header” and then paste the entire cookie line into the “Match” field then I only place the session handling cookie in the “Replace” field which in this case is the bb_sessionhash cookie. A screenshot of this rule can be seen below.

After this every single request will only contain the cookie you’ve identified as the one belonging to the main session. If you look in the history tab and view a request after you’ve made the rule you’ll see where this comes into play as seen in the screenshot below.

Now you’ve successfully isolated one cookie that deals with initial authentication and while you’re walking the app and you stumble across some broken functionality it may be because another cookie got introduced into the application. Hopefully this rule will help you identify other cookies that get introduced into the application. Also hopefully this will keep you mind open to other rules that you can make regarding sessions within the application.

Please leave feedback and let me know if this was helpful and if you know of any other good burp suite tips please leave feedback on that as well.