BURP SUITE - PART V: MAPPING THE TARGET

Today I will show you a quick overview of how you can quickly map the web infrastructure for a target website using the tools built into Burp Suite. I probably should have covered this in the beginning as it is a fairly basic task however I seem to get a lot of questions on it, so here we are. We will be focusing on the Target & Spider tabs for this tutorial. I will lay down the steps from setup to run and try to keep it in the usual easy to follow format, here goes…

We will start off as usual by configuring our browser to use proxy on localhost (127.0.0.1) and point it to port 8080 unless you have changed the default settings for Burp to listen on another port (as I have in example below – using 8181 as apache already running on 8080).

Once our browser is properly configured we can fire up Burp Suite by double clicking the jar file. Now we can start capturing our requests from the browser and playing with them within Burp. I like to turn the Interceptor off on the proxy tab so all requests flow as normal and can be easily picked up on the proxy history tab if/when/as needed. Now in order to map the target site we will first need to fire a request in our browser to the root directory of the site (i.e. http://www.targetsite.com/). Once it is run we pick up in Burp, turn off the Interceptor and get ready to start mapping things. You will now navigate to the proxy history tab to review the actual request that was sent. You will right click on the request and choose to “add item to scope”. In doing this we will be defining it as one of our target sites.

I know you can see the “spider from here” and I know it is tempting to jump ahead but if you want to have clear and easy to interpret results then hang tight for just one minute... Now that we have added the target site to our in-scope items we will further define how our spider and target settings will need to be for best results. We start with the Scope sub-tab under the Target tab. Here we can define what is to be considered in-scope. If you’re working on multiple sites or if you know two domains are linked you can add them in here as needed. This will be used to help us filter the results out from all of the other sites which will get drawn from crawling & spidering due to ads, photos, etc. You can add them as outlined above or you can copy and paste your URL links directly into this tab as needed. I should also call out that you can define or set the items to exclude from being considered in-scope. This is helpful in avoiding pages which might cause the crawler/spider to be logged out and thus result in incomplete results. The default settings are fine but this is where you can go in those pesky situations to help fine tune things.

NOTE: the sitemap sub-tab is where all of the results will be presented once the crawling/spidering begins; hang tight and we will come back to that one in a bit…

OK now that we have defined our scope we need to define the options for our crawler or spidering results. These options will define how the crawling is done, how forms are handled, etc. In the first half of the options you can define some general settings like checking for robots.txt file for added info or the crawl depth to use. You can also define the forms and how they are handled in this upper half. This allows you to fill out some basic info once and have it submitted automatically for you anytime the crawler comes across a form it will use smart technology to match as best it can. You can also have it ignore the forms altogether or go into interactive mode and have it prompt you for action on all forms it comes across. If it does have valid credentials then the crawler will obviously get a more in depth scan with more accurate results so if you have the proper credentials then enter them here if not just remember what you submit may show up in a report or in the logs so you may want to change the defaults if you’re on a paid gig ;)

NOTE: If you have a password protected shell getting uploaded to a sight and you can’t seem to find it, the application login prompt for guidance method is a good way to quickly find the link to your missing shell as you can check the links as they are found for authorization pages and then manually inspect to see if it is your shell (it works for me with high degree of success!).

The lower half of the options tab allows you to set the speed at which the spider engine will be running at. Please be aware of your own system limitations before adjusting the thread count to high – the default settings do seem to run fairly effective in most cases. You can also set header level information to be carried in the requests being made while crawling as well as choosing to unclick the HTTP/1.1 box and force communication in older less supported standards.

OK, now that we have everything properly setup for our scan we make one last edit which will make a huge difference in our results and how clear they are to interpret. We go to the Target tab and Sitemap sub-tab to activate our filters. You need to click on the grey area at the top which will expand when you click on it. In the filters section you can have it sort the results based on your liking (server response codes, by MIME types, file type, only parameterized requests - for you injectors out there, etc.). I like to setup the filters as I like them but the biggest most important one is setting to filter only in-scope items. This will block out the extra waste. If you don’t believe me try it without the filters and then try it afterwards again with filters to see how big a difference this small task makes.

It should appear as follows once the filters menu is expanded:

SPECIAL SIDE NOTE: IF you want to save the requests and/or responses from any session you need to define this from the start by clicking on the Options tab and then on the Misc. sub-tab. Here you can choose to log requests, responses, or both if you want. This is helpful if you want to manually review things after your work or if you want to pass the log results to another tool such as SQLMAP to be parsed for possible SQL injection vulnerabilities. If you choose to log anything it will prompt you to name the log file as well as defining the location for storage.

This should get you all setup. We now go back to the Target tab and the Sitemap sub-tab, where you will now see just your target site; right click on it and choose the “Spider this host” option to launch the crawling and spidering process.

Now you sit back and wait for a few minutes while Burp scanner does its thing. You can check the status of a current crawling/spider session by checking the Spider tab and Control sub-tab:

In order to see the final results simply navigate back to the Target tab and the Sitemap sub-tab and you will see all of the found links on the left hand side. You can expand folders and dynamic pages to see what is within them or what options can be passed. You can also see a list of the URL links in the right hand area as shown below:

The example above is rather simple in nature but this is an easy way for you to get a feel for what a site has going on. You can play with the options and the filters to see how it changes the results provided to you and customize to fit your need (for example, in some cases you may want to trace what other sites are communicating to see if you can exploit trust relationships and therefor might not want to filter any results in the sitemap sub-tab so that you can see everything linked). That sums up my brief overview on how you can use Burp Suite to map out a sites infrastructure in a quick and easy manner. You can use the options to your advantage to find authentication forms, lost shells you might have uploaded, or just to get a better picture of what you’re up against.  I encourage you to continue playing around with Burp Suite and all the tools it has to offer. I will continue to work on coming up with new material to share with you on how we can continue to squeeze out more usefulness out of Burp Suite tools, until next time – Enjoy!

PS - my apologies for not including these details in an earlier series for those who felt I left it out you should now have everything you need to get started and on your way with the basics J

Burp Suite - Part III: LFI Exploitation via /proc/self/environ

OK, so today I have a treat for you in the form of a short video. Since I already covered how to perform LFI Exploitation via /proc/self/environ method manually, I figured I would show you how it can be done with the Burp Suite tools. It is fairly easy to follow along in the video and it aligns with the manual process so it should come easy enough for most. The needed files are all included in my original HR Burp Suite Download Pack. Until next time, Enjoy!

Looking for a introduction to Burp Suite? Check this out!

BURP SUITE - PART II: SQL Authentication Bypass

Today I am going to extend my previous tutorial where I introduced you to Burp Suite tools so that we can now audit login forms for SQL Authentication Bypass vulnerabilities. This is a common problem found daily in the wild where PHP & MySQL are being used as the Authorization mechanism based on dynamic SQL Query's which are completed from user input supplied through login form. This can be time consuming and repetitive to conduct manually but it is relatively easy to audit - and after reading this it will be even easier, especially with Burp! I will first provide an explanation of the problem and what is going on which allows the vulnerability to be exploited followed by an example, so here goes…

As mentioned above Authentication Bypass vulnerabilities often occur due to a lack of filtering of user supplied input. If we review a quick example of code from a PHP/MySQL authentication page we will begin to see things more clearly. You can find some test samples with quick Google dork “file:php/asp inurl:admin/login”, but here is sample login to keep it easy:

<?php

$sql = "SELECT * FROM users WHERE username='" . $_POST['username'] . "' AND password='" . $POST_['password'] . "'";

response = mysql_query($sql);

?>

This code fails to filter or check the user supplied input. The target system reads like so as result:

SELECT * FROM users WHERE user='' AND password=''

Since this is not filtered or checked we will pick a username and use SQL Injection on the secondary field. Let us assume we choose the username “webadmin” and the SQL Injection:

' OR 'x' = 'x

This is now how the query looks that will get passed through:

                SELECT * FROM users WHERE user='webadmin' AND password='' OR 'x' = 'x'

This is how the target system actually reads & parses the request:

SELECT * FROM users WHERE user='webadmin' AND TRUE

The ultimate goal here is to use our SQL injection to alter the SQL query so that it is fooled into letting us in. This works as you can see above as ‘x’ is always going to be equal to ‘x’ so it will always return as TRUE, and thus the system will grant us webadmin user access to walk right in through the front door without any real password.

Now we could use alternative injections above, like:

·         ' or '1'='1

·         ' or 'x'='x

·         ') or ('x'='x

·         ') or ('1'='1

·         …etc

Some customization may be needed to fit your specific need (Sometimes injections need to be placed in both fields; sometimes it needs more complex syntax, HEX or Char encoding may be needed, etc). You could easily build your own list, but I have gone ahead and put together a decent list to help get you started. The list can be found in the AuthBypass/auth-bypass.txt file which is included in my full download here: HR’s Burp Starter Pack.

Now with Burp Suite:

Now rather than try each potential SQL statement or injection we place all of our potential injections into a single file and then let Burp run the requests in an automated fashion. This will help to save you time, as well as allow easier parsing of the results in a systematic way. In order to do this we simply submit a bogus request with arbitrary data submitted (user: foo, pass: bar).

We then load up the request and send it to the Intruder tool to build our attack. We clear the default injection points and specifically set them around our password field or both user and password fields. You will choose the Sniper or Battering Ram attacks for this method, depending on how you want to test the form. You will then need to set the payload to run your auth-bypass.txt file. You can add some additional inspection items to the grep field if you want. I find it is often helpful to add some basic text you might see upon failed or successful login attempts (welcome, success, failed, wrong, etc).

Once you run the Intruder tool it is time to sit back and interpret the results. You will need to check time, length, grep, etc and manually review any of the requests that appear to show a noticeable variance in responses.

Once you find one, re-test it manually in the browser to see if it works.

If it works you are in, if not keep analyzing and inspecting further.

Rinse, wash, and repeat as necessaryJ. Here is a quick video to show how things should work for those of you that needed the real time visual aid (I know I usually do):

I hope you have enjoyed another tutorial on the Burp Suite and how it can be used to perform quick and accurate audits of login forms to see if they are vulnerable to Authentication Bypass via SQL Injection. I plan to have a follow up tutorial stemming from this one which adapts the methods slightly to perform dictionary attacks against login forms. Please check back often and soon for more updates and more tutorials to come. As always and until next time, Enjoy!

Thanks,

H.R.

BURP SUITE - PART I: INTRO via SQL INJECTION

OK, so today I am going to provide you with an in depth overview and introduction to testing and attacking SQL vulnerabilities in web sites and applications with the Burp Suite toolset. The free version which I will be explaining today is a hardcore tool for the security enthusiast, and they have a PRO version with even more features than what I will be covering today for the serious or professional pentester. This article is only meant to give you an introduction to this great tool; it is not a full comprehensive guide and is purely based on my understanding of it from recent testing (be warned is it a bit long and picture intensive). I personally had a difficult time getting to know the Burp Suite and have approached the tool several times in the past only to be intimidated by it and pushed it off for a later date. The documentation provided by the Burp Suite team is helpful but also lacking in many areas, in my opinion, so I thought I would create my own guide to help others out. This tool is more targeted towards intermediate and advanced users, and will help you take your game to the next level.

Requirements:

·         Java v1.5+ installed (recommended to use latest JRE), available for free from here: http://java.sun.com/j2se/downloads.html

·         Copy of Burp Suite, available for free here: http://portswigger.net/burp/download.html

o   Free version works just fine, but the PRO packs a few extra goodies that are well worth it from what I hear

·         Make sure you can also locate and run the Brain.dll file ;)

Getting Started:

You will need to make sure you have met the prerequisites listed above, just download both. Install the Java and unpack the Burp Suite to desired location to run. In order to get Burp Suite started on most computers you can just double click the executable .jar file, if that doesn’t work for you can run it by typing this in the command prompt or terminal:

COMMAND: Java –jar burpsuite_v1.4.jar

You will be greeted with the Burp Suite GUI once this has been done, it should look something like this:

The toolset is broken down into a tabbed structure with each tab performing a different service, test, or function. Burp Suite and its tools allow you to perform manual and/or automated requests to quickly scan, enumerate, analyze, attack and exploit web sites and their applications. This is facilitated through its tabbed structure which allows you to pass the results or focus item from one toolset directly to another allowing you to build as you go. It is the culmination of all of these which make Burp Suite such a powerful toolset to have in your arsenal, but before we get started I will introduce you to each of the tools within the Burp Suite toolset and what they do…then I will show you a few examples in action. Here is a quick breakdown of the tools included and what each does:

·         First and foremost it has a local intercepting PROXY

o   This allows you to capture traffic between your browser and the target site. You can then inspect the captured traffic and pass it along to other tools in the suite for further analysis and testing. More to follow on this…

·         The application-aware SPIDER tool can be used to crawl target sites to reveal site content, underlying structure, and other functionalities.

·         The REPEATER tool allows you to manually resend individual HTTP requests

o   This is very handy tool as it allows you to make quick changes on the fly and see how the server responds, I will cover more on this later…

·         The INTRUDER tool is another one we will be focusing on today. This tool allows you to make customized payloads to be used in attacking the target. It is highly customizable and limited only by your imagination, more to come later…

·         The SEQUENCER tool comes in handy if you want to test the randomness of session tokens. This can be used to uncover weak entropy which could lead to exploiting something like Session Jacking or similar type of scenario. I won’t be covering this today, but you should be able to pick it up after this basic tutorial and then start testing on your own.

·         The DECODER tool is another handy one to have around as it can be used to decode material you may come across in your testing or it can also be used to do common tasks like converting text to HEX. This is worth playing around with as I won’t be covering it here today, but it is straight forward and simple enough to pickup

·         The COMPARER tool is designed to allow you to perform visual comparison of any two items

·         PRO VERSION:

o   Also includes an advanced web application vulnerability scanner which is very accurate in detecting all kinds of vulnerabilities that could potentially be exploited

o   INTRUDER tool is not time throttled meaning quicker test times

o   Allows for save and restore should you stop mid stride

o   Also has some additional SEARCH, Content Discovery, and Task Scheduling features which are not available in the free version

o   General feedback on the street is that it is worth it if you can afford it

OK so that gives you a basic idea of what each tool is, now I will try to show you some examples of them and how to put them to work to your advantage. I will show some examples involving testing and exploiting SQL injection vulnerabilities which can be easily modified to test for other scenarios, here goes…

Prerequisites:

·         Target Site to test

·         Burp Suite up and running

Alright so once you open up the Burp Suite you can navigate to the PROXY tab to get things setup so we can start intercepting traffic and begin our testing. You will need to click on PROXY, and then click on the OPTIONS tab. Here is where we can setup our proxy port to use for our testing. In my case I already have an Apache server running on port 8080 so I needed to change it to port 8181, if you don’t have anything running then leave as is. The edit and add buttons should allow you to change to fit your need. Just click the little box at the left “running” to enable the proxy service once you are done. You will see the ALERT tab light up bright RED if there are errors, and you will find a short note regarding what the problem encountered was. Here is what my basic settings look like:

Once proxy port is selected and services started in Burp Suite we need to configure our Browser to use it so we can capture the traffic. In most browsers you simply open up the settings, go to network connections, check the box to enable proxy support, and then tell it to use “localhost” and port “8181” (or whatever port you are running Burp Suite on, default: 8080). Then set OK, OK to save the updated settings and now you should be all set to go.

Now that we have that setup we can insert our target URL into the browser window and hit ENTER. You will see the Burp Suite tool light up and the Interceptor tab of the PROXY tab will light up RED to indicate it needs your input. The default behavior is to set the INTERCEPTOR to ON, which means it captures all traffic requests being sent and then requires user input to decide if the packets will be forwarded or dropped. You can forward and watch the page load the target site (may require a few forwards, depending on site). I find this feature helpful when you know you want it, but I prefer to turn the INTECEPTOR off and just manually crawl the site and let the traffic get captured and sent to the HISTORY tab. You can manually run through the site checking it out and the traffic will all be captured in the history tab for us to review and test when we are ready.

INTECEPTOR – Capture with default settings, user needs to forward or drop to continue:

TURN OFF the INTERCEPTOR and surf web as you normally would and everything gets sent to the HISTORY tab so you can test when you are done:

Here you can see all the traffic captured and the ticks next to those requests which might have parameters we can test or fuzz. Now that we have some requests to test, we will right click on the one we want to test and choose to send it to the REPEATER.

You will see the REPEATER tab light up bright RED to indicate it is now waiting for user action since the request has been sent to it. Now we can use the REPEATER to do some quick manual inspections. You will find the request already prepared in the RAW tab, it is also cleaned and organized if you prefer to review on the parameters, header, or hex tabs. You can find what works best for you, but my preference is to work with the raw request.

The REPEATER allows you to make any changes you want to the request and then resend it to analyze the results from the server. If you notice above it even highlights the request parameters in BLUE and possible vectors to manipulate in RED. Let us send the request by hitting the GO button (leave it as it is to establish a baseline), and then add a single quote to the after the “2” in the above request and then resend to see if the server responds any differently.

NOTE: If you don’t like searching through RAW responses you can also click on the RENDER tab of the response area (when available) and it will render the RAW code into what the browser would see.

Well what do you know; the server seems to have an issue with processing single quotes. This may or may not be vulnerability. You could continue to test this manually in the REPEATER by just continuing to edit, sending an analyzing the results, but this is where the INTRUDER tool comes into play, as we can create a few customized payloads and automate the process. In order to pass this request to the INTRUDER tool just right click the message body and choose the send to intruder option.

Again you will see the INTRUDER tab light up bright RED to indicate the tool is now awaiting user input. Before we begin with the INTRUDER I feel the need to lay down some additional clarification around what all is included in the INTRUDER and how they work. The Intruder tool is broken into four (4) tabs: target, positions, payloads, and options. The target tab is pretty straightforward, it only needs to point to your target site, desired port, and a ticker for whether or not you want to use SSL for connection. This tab is pretty much setup for you by default just by sending the request to the intruder tool, if you need or want to use SSL then click the ticker.  The positions tab is crucial to understanding; this is where we mark our requests for the intruder to do its thing with. We will identify pieces of the request where we want to inject or alter with our payload options (will make more sense after examples ahead). The tool will use the highlighting to show you were the possible attack points are. The tool uses the § symbol as start and end markers for each targeted attack position. If you want to replace the parameter value then place the §§ symbols before and after, however if you want to test altering or injecting after it then place the §§ symbols directly after the parameter value. Here are examples of both; again this will make more sense after a few examples in a minute so bear with me for now.

Replace parameter value:

Alter to Inject after the parameter value:

NOTE: You can use the clear, add, auto buttons on the right to clear and/or insert markers where needed. You can identify attack vectors pretty much anywhere you can think of: URL, Cookies, User-Agent, etc. (use the highlighting to your advantage or auto feature and then narrow down to what you want to focus on).

OK so you have identified where you want to alter/inject on…now what? How do we make it work? Don’t worry keep reading we are almost there ;) In order to finalize the settings for the INTRUDER you need to also select the attack type to use and then configure settings for the attack type so it injects our desired payload into each position during tests. Here is a breakdown of the four (4) available attack types and general idea of what each does:

·         Sniper: This attack mode lets us inject a single payload into the chosen attack positions. This takes the payload options and inserts them one by one into the chosen position and then repeats until it has tested all payload options. If multiple positions are chosen it will only apply the test to one position at a time. I will show you how to use this to test for signs of SQL vulnerabilities in a sec…

·         Battering Ram: This is similar to the Sniper attack mode in that it takes our desired payload and inserts it into the chosen attack positions. The difference here is that if more than one position is chosen it will insert the same payload into all positions at once and test, whereas the Sniper tests them one by one. This can be a handy attack type for attacking things where the same material is needed in multiple locations of the request. I personally have not used this one a lot successfully.

·         Pitchfork: This attack mode allows you to test multiple payloads based on attack position, with a max of 8 being able to be defined. This attack mode sets a different payload for each position and moves through them one by one while testing multiple positions at once, which can be extremely useful in tests as I will show in a minute.

·         Cluster Bomb: This attack mode uses multiple payloads and allows you to test each possible payload in each chosen attack position, meaning it will try payload1 in position1 and then on the next test it will try payload1 in position2, swapping out for any other payloads you have defined. This can be handy when you have different input/injections needed in multiple places.

OK so now you have an idea of what the attack modes are; let me show you a few in action so it all comes together for you. We will take what we did manually and instead this time use the INTRUDER tool to test for SQL vulnerabilities. I have created a small list of possible injections to test for SQLi, nothing overly complex:

·         '

·         "

·         /

·         /*

·         #

·         )

·         (

·         )'

·         ('

·         and 1=1

·         and 1=2

·         and 1>2

·         and 1<=2

·         +and+1=1

·         +and+1=2

·         +and+1>2

·         +and+1<=2

·         /**/and/**/1=1

·         /**/and/**/1=2

·         /**/and/**/1>2

·         /**/and/**/1<=2

Using our example we will set the attack vector to come after our parameter value. We will use the SNIPER attack mode to insert our list of payloads above.

Then we need to configure the payload, save the example I provided above as vuln-test.txt on your PC somewhere. Then navigate to the payloads tab where will set our payload to a “runtime file” and then select your file you saved to load as our payload injections.

NOTE: there is a URL encoding option at the bottom which you may or may not want to take advantage of. Also make sure you add a whitespace as I am not 100% it is included by default.

OK now we need to check out the options tab to finalize things and then we can run it. If you scroll down on the OPTION page you will find a section for grep. We can define text to search for on the results page after our payloads have been inserted. This can be very handy in interpreting the results as well as saving you some time. I use a general list of SQL error messages for this part, just hit load to select a file on your system or you can add them manually one by one. Whichever suits you best is fine. Here is a look at what is included in my error-vuln-check.txt file:

·         unknown column

·         unknown

·         no record found

·         mysql_num_rows()

·         mysql_fetch_array()

·         Error Occurred While Processing Request

·         Server Error in '/' Application

·         Microsoft OLE DB Provider for ODBC Drivers error

·         error in your SQL syntax

·         Invalid Querystring

·         OLE DB Provider for ODBC

·         VBScript Runtime

·         ADODB.Field

·         BOF or EOF

·         ADODB.Command

·         JET Database

·         mysql_fetch_row()

·         include()

·         mysql_fetch_assoc()

·         mysql_fetch_object()

·         mysql_numrows()

·         GetArray()

·         FetchRow()

·         Input string was not in a correct format

·         Microsoft VBScript

·         A syntax error has occurred

·         ADODB.Field error

·         ASP.NET is configured to show verbose error messages

·         ASP.NET_SessionId

·         Active Server Pages error

·         An illegal character has been found in the statement

·         An unexpected token "END-OF-STATEMENT" was found

·         CLI Driver

·         Can't connect to local

·         Custom Error Message

·         DB2 Driver

·         DB2 Error

·         DB2 ODBC

·         Died at

·         Disallowed Parent Path

·         Error Diagnostic Information

·         Error Message : Error loading required libraries.

·         Error Report

·         Error converting data type varchar to numeric

·         Fatal error

·         Incorrect syntax near

·         Index of

·         Internal Server Error

·         Invalid Path Character

·         Invalid procedure call or argument

·         Invision Power Board Database Error

·         JDBC Driver

·         JDBC Error

·         JDBC MySQL

·         JDBC Oracle

·         JDBC SQL

·         Microsoft OLE DB Provider for ODBC Drivers

·         Microsoft VBScript compilation error

·         Microsoft VBScript error

·         MySQL Driver

·         MySQL Error

·         MySQL ODBC

·         ODBC DB2

·         ODBC Driver

·         ODBC Error

·         ODBC Microsoft Access

·         ODBC Oracle

·         ODBC SQL

·         ODBC SQL Server

·         OLE/DB provider returned message

·         ORA-0

·         ORA-1

·         Oracle DB2

·         Oracle Driver

·         Oracle Error

·         Oracle ODBC

·         PHP Error

·         PHP Parse error

·         PHP Warning

·         Parent Directory

·         Permission denied: 'GetObject'

·         PostgreSQL query failed: ERROR: parser: parse error

·         SQL Server Driver][SQL Server

·         SQL command not properly ended

·         SQLException

·         Supplied argument is not a valid PostgreSQL result

·         Syntax error in query expression

·         The error occurred in

·         The script whose uid is

·         Type mismatch

·         Unable to jump to row

·         Unclosed quotation mark before the character string

·         Unterminated string constant

·         Warning: Cannot modify header information - headers already sent

·         Warning: Supplied argument is not a valid File-Handle resource in

·         Warning: mysql_query()

·         Warning: pg_connect(): Unable to connect to PostgreSQL server: FATAL

·         You have an error in your SQL syntax near

·         detected an internal error [IBM][CLI Driver][DB2/6000]

·         error

·         include_path

·         invalid query

·         is not allowed to access

·         missing expression

·         mySQL error with query

·         mysql error

·         on MySQL result index

·         on line

·         server at

·         server object error

·         supplied argument is not a valid MySQL result resource

·         unexpected end of SQL command

Once this is finished you can actually run the test using our HTTP request we identified earlier and now using our selected Sniper attack with vuln test payload and grep contents set. You can run the Intruder tool by clicking on the file menu at top and simply selecting Intruder>>start attack.

This will now open a new window where we can watch the test run and then interpret our results:

You can clearly see that there is a length difference on our messages containing the common SQLi offenders as well as some noticeable differences for the true false tests at the end. If you also look you will see that there are a lot of columns to the right and that some of them have checks in them. This is to signify that the grep found text from our provided list. If you click on a request you can then view the actual request and response in the below area, thus we can now clearly see which ones caused an error and what error was thrown, you can also review the rendered response to see visual differences for things like the true false examples since they might not always throw readable errors (again length can tell you a lot and act as a big hint as to where you should spend time investigating further).

OK we have found a potential SQLi vulnerability based on error messages and true false response tests. This is good start, but now what? Now we go back to the INTRUDER settings and work on altering our settings to further test and exploit. Let us now see if we can set the Intruder up to test ORDER BY to determine quick column count. Using the same request we will now position our payload to insert ORDER BY statement and test results to find column count.

SAMPLE-order-by.txt

·          ORDER BY 1—

·          ORDER BY 2—

·         +ORDER+BY+1—

·         +ORDER+BY+2—

·         /**/ORDER/**/BY/**/1—

·         /**/ORDER/**/BY/**/2--

·         …

Update our grep settings to look for “unknown column” and anything else you might like to add for determining column count. Once these changes have been made, re-run the intruder tool and review the results to see what we have found:

Great – we have found the column count to be 5! You can use the response requests to judge in addition to the request length clue. Now we will send this request back to the REPEATER, now we will use the REPEATOR to find vulnerable columns. Change the ORDER BY to UNION SELECT statement with known column count, run the request in Repeater and view the rendered results to see what columns are vulnerable:

NOTE: don’t forget to NULL or negate “-“ parameter value so the output reflects any vulnerable columns.

OK, now we see clearly that columns 1 & 2 are vulnerable. Now we can send this updated request back to the intruder for further testing and exploitation. We will now setup the Intruder to insert some basic SQL queries as payloads into our vulnerable columns to get us some basic info in return. I have put together a short list called basic.txt to use as payload, but you will need to set the attack positions to insert in place of column 1 and/or 2 (You only need one so keep it simple).

SAMPLE-basic.txt:

·         Version()

·         User()

·         Database()

·         @@hostname

·         @@basedir

·         @@datadir

·         …

Once you have payload options set, it is time to re-run once again and interpret the results. You don’t need any grep here as we will be pulling the data from the rendered server response packets directly this time.

We can keep going all the way to extraction by simply adjusting our payloads and retesting. If we want to check for the available databases we can add an additional attack vector to our existing request, modify attack mode to CLUSTER BOMB, and then change the payloads to get-dbs1.txt and get-dbs2.txt.

NOTE: we also will be changing to the CLUSTER BOMB attack mode so we can enter both payloads at the same time to get our desired results.

Once you have it setup, re-test and interpret the results:

OK, take note of the available DB names, you will need to HEX them and copy and paste them into the file called get-tables.txt as we will now use this for our next payload set to get the tables for each database found. Insert get-tables1.txt into position 1, use get-tables2.txt for payload and position 2, and insert get-tables3.txt at the end (this means we also need to add another injection/insertion attack vector to our request. It will follow immediately after position2 as we will be linking them together). The first one sets up group_concat, the second prepares the statement and the third runs through the list of database names to enumerate tables from. Re-run the Intruder test once you have it setup, no grep needed as we will be mostly using the render feature to interpret from here out.

SPECIAL NOTE: You can use the DECODER tool for HEX if you would like, just paste your text into top area and then choose the middle drop down to “encode as” and pick what you want. The converted text displays in the lower section:

See how the results differ when DB name is not in HEX value below:

OK, so now we have basic info, DBS, TABLES, we can keep going and modify slightly to get the columns. We go back to the Intruder tab and reconfigure to get columns from known tables. You will need to remember to HEX again, so go ahead and use the DECODER again –that is what it is there for! This time we need to add another attack vector to our request so we can insert our group_concat(column_name), then insert the from statement, and then we will use position 3 for inserting our table names. If you want you could add an additional position 4 to add in the needed syntax to pull tables from non-active DB (refer to some of my other basic SQL tutorials if you need help in locating syntax).

Now you have all you need to extract. You can keep altering the payloads to handle this for you if you are working with a vulnerability or exploit that is rinse wash and repeat, however if the targets do not have the same content then this may be the time to switch back to the REPEATER to manually apply the found content to extract what you want. Just alter the syntax to fit just like it was normal SQLi and then hit GO and parse the rendered results for your pirate treasure.

OK so now you have successfully used Burp Suite to find vulnerability and exploit it. If you need to map out the site to perhaps find login pages there is one last tool in the set that can help, and that is the SPIDER tool. It is application-aware meaning it will pick up on any links passed through the proxy during tests. You can also activate it by customizing the option settings for it and letting it loose on target site. It is pretty good even with default settings. You just find your target in the SITE MAP list on left hand side under the SPIDER. Right click your target site and tell it to “spider host” and it will do its thing. If it comes across any forms it will set off the RED alert box as you need to tell the tool to either submit forms or ignore them (you can configure custom settings for this to be handled under options - just remember that what you put is what shows up in logs so if your trying to be professional you might want to change it ;).

Once it is done you can use tree view to see the site infrastructure according to the spider tool:

You could alternatively use a request to the web root and then enumerate a list file of known login pages/directories and judge repsonses to see if it is present. I will end the tutorial here or I could keep going for ever and ever with all the cool features that are built in, but you should have the basic idea now. I have included a link below to a download which contains all of the content and text files referenced (and some more for other projects I am working on). I have put this together for my own personal testing with Burp Suite, and you are free to download and use as well. If you have any additions please let me know as this is a constant work in process for me, with most of it built on top of the FuzzDB project which I used as a base for figuring this out combined with plain old experience gathered through trial and error over time. I will try to work on some additional follow up tutorials for some other common tasks that can be performed with Burp Suite like Authentication Bypassing via SQL, POST injections, XSS, Uploading Shells, and whatever else I can come up with. Part II to come in next few weeks. If you need more in the meantime you can check the Burp Suite site and community forums for help.

I hope you have enjoyed another tutorial by me H.R., please comment and let me know what you think, and don’t forget to check back often for updates and new material.

Until next time, Enjoy!

EXTRA-BONUS: HR's Burp Suite Extension Pack

Here is link for anyone interested in getting a head start on usable files for Burp Suite. This is my picking and choosing through the FuzzDB set as well as a lot of my own additions and interpretations. You might not find all of it usefull, but I assure you it is packed full of great content to get you started. I will do my best to keep it updated as I make changes and additions to my own personal set. If you have anything notable to add please send my way and I will gladly update the set so others can benifit as well.