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.

How to Upload a Shell

Today I will show you how you can upload a webshell to a website after you have successfully found your way into the admin panel. I will start with the end of my SQLi session and dive into working to upload a shell through the admin panel. Please hold your questions till the end ;)

Ok so you found a vulnerable site and or somehow have managed to come across the admin credentials.

Uh oh, it is encrypted MD5! It's OK, we do quick check with the big online databases to save time and if we don’t find it there then we follow my other tutorial on how to use Hashcat tools to crack it ourselves. Lucky for us our Admin choose poor strength password which was easily found online with a quick check:

OK, so now we have admin credentials. We use our favorite admin finder, cross our fingers, and hope we find one that will work with the credentials we found. Here is a good online admin finder if you need one: http://sc0rpion.ir/af/

Once you make your way into the actual admin panel it is wise to take a look around to see what all you have access to. If you just want to leave your mark you may be able to quickly edit HTML on pages or inject a hidden iframe or an effective stored XSS of some kind (pop-up or redirect), but for this tutorial we will be focusing on how we can get a web-shell on the site, something like c99, GNY, etc. We will have much more flexibility with a full featured web-shell. OK, so you will want to look around and see what you can do as admin, maybe quickly add a new user with some rights in case the real admin changes their password. Then start looking for ways to upload things, doesn't really matter what it is for now - typically you can find areas to add news, products, images, movies, etc. We will leverage one of these upload fields to inject our shell instead and gain better access to our target site. In some cases you will find you can simply upload your shell with no problems, so always check if it will take “shell.php” first. In most cases it won't, if it does then there is no reason to continue reading as you’re in J. If it doesn't then things get interesting as we need to now find a way to manipulate our upload so it bypasses any file restrictions. How can we do this you say? By controlling our request we send in more detail. We will use Live HTTP Headers add-on for Firefox in this example, you could also use Burp Suite, or Tamper Data add-on (others exist too but these are main options I know). We will use these tools which allow us to manipulate more aspects of the actual HTTP request we send when we hit the actual upload button. We first will upload our file as “shell.php”.  

We typically will get an error indicating we can’t upload PHP files, and if we are lucky it will tell us what kind of files are acceptable. OK, let us try to fool it into thinking it is something else that is on the acceptable list. We can play wile file naming conventions or through the addition of NULL bytes (). They both are effective and you really have to play with both options until you find something which works, here are a few common methods I use which you can easily expand upon:

                shell.php

                shell.php.jpg

                shell.php.gif

                shell.php.jpg

                shell.php;fake.pdf

                shell.php.gif

                shell.php;fake.mp3

                ....

You get the idea. The point is that the “.xxx” file ending is what gets read during check and when server scans hopefully the null byte () causes it to stop reading the rest making it stop at “.php”. If this doesn't work or you shell is getting messed up when it is uploaded then we will use Live HTTP Headers to modify the request on the fly and in addition to faking out the file type we will straight change the file type in the request we send. Start Live HTTP Headers and make sure it is setup to capture requests (small check box at bottom):

Then you first submit the one that works to simply work and get the request formatting saved. Then replay the request so that a new window pops up and then modify the text in the request to remove the fake.fake-file-ending part so all that is left is “shell.php”.

NOTE: you probably need to scroll to the top and choose the first one since we started it only to capture the submission this should be the first request

When you hit replay it pulls up the original request to modify before sending. Find the part for the filename (use FIND to make it quick). Change the file name so all that is left is “shell.php” and then hit replay again. It will submit through browser and you should now be done.

Now find the file by right clicking or whatever means necessary and open in new browser tab.

Voila shell properly uploaded and working – Game Over, you win!

If you have problems finding your shell, here are a few helpful hints to finding it:

1 – Right click uploaded image on site and check its location. See if directory indexing is turned off, if it is not then you can easily see what all is in the folder until you find your shell. You might have to try a few images or locations on the site, just try to use other items from the same category your uploading to and think logically about it.

2 – If you can’t find it then I suggest scanning the site with a web-scanner like Accunetix, W3af, or something else you like better to see if it can find it (infrastructure scanning, or if you require password for shell check for auth files, or backdoors, etc)

3 – If you absolutely still can’t find it, you can try Google search to help find your shell. Use dorks and text from your shell or file name to try and find it on site.

Remember you won’t always get admin access and you can’t shell every site, but here is one more trick to add to your bag to increase your chances. If you’re a coder, then this is one more reason to check your uploads as you won’t always get what you expect coming through, don’t expect every user to be nice and use the system as intended as this method can be used against any upload form, not just admin panels. I hope you have enjoyed this brief tutorial. If any questions, comments, or suggestions please post here or let me know.

EXTRA BONUS:

For those that need a video to grasp the concept, here you go: 

Until next time, Enjoy!

Laters,

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.