Hi everyone,

I have been spending some time this week reviewing some of the old Security Ninja blog posts now that we are getting close to our second birthday. I wanted to create a list of things I’ve promised to write about but never got around to doing.

The first item on my list is a tutorial for the Burp Suite. If you Google “Burp Suite Tutorial” my blog post from 2008 saying I was going to write a tutorial is the 7th result returned. The old Security Ninja blog has received over 2,000 visits to that blog post including an additional 30 visits so far in March.

What is the Burp Suite?

Burp Suite is an integrated platform for attacking web applications. It contains all of the Burp tools with numerous interfaces between them designed to facilitate and speed up the process of attacking an application. All tools share the same robust framework for handling HTTP requests, persistence, authentication, upstream proxies, logging, alerting and extensibility.

Burp Suite allows you to combine manual and automated techniques to enumerate, analyse, scan, attack and exploit web applications. The various Burp tools work together effectively to share information and allow findings identified within one tool to form the basis of an attack using another.

Source: http://www.portswigger.net/suite/

The Burp Suite is made up of tools (descriptions take from the Port Swigger website):

Proxy: Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications. It operates as a man-in-the-middle between the end browser and the target web server, and allows the user to intercept, inspect and modify the raw traffic passing in both directions.

Spider: Burp Spider is a tool for mapping web applications. It uses various intelligent techniques to generate a comprehensive inventory of an application’s content and functionality.

Scanner: Burp Scanner is a tool for performing automated discovery of security vulnerabilities in web applications. It is designed to be used by penetration testers, and to fit in closely with your existing techniques and methodologies for performing manual and semi-automated penetration tests of web applications.

Intruder: Burp Intruder is a tool for automating customised attacks against web applications.

Repeater: Burp Repeater is a tool for manually modifying and reissuing individual HTTP requests, and analysing their responses. It is best used in conjunction with the other Burp Suite tools. For example, you can send a request to Repeater from the target site map, from the Burp Proxy browsing history, or from the results of a Burp Intruder attack, and manually adjust the request to fine-tune an attack or probe for vulnerabilities.

Sequencer: Burp Sequencer is a tool for analysing the degree of randomness in an application’s session tokens or other items on whose unpredictability the application depends for its security.

Decoder: Burp Decoder is a simple tool for transforming encoded data into its canonical form, or for transforming raw data into various encoded and hashed forms. It is capable of intelligently recognising several encoding formats using heuristic techniques.

Comparer: Burp Comparer is a simple tool for performing a comparison (a visual “diff”) between any two items of data. In the context of attacking a web application, this requirement will typically arise when you want to quickly identify the differences between two application responses (for example, between two responses received in the course of a Burp Intruder attack, or between responses to a failed login using valid and invalid usernames), or between two application requests (for example, to identify the different request parameters that give rise to different behaviour).

I wanted to explain how to use the Intruder tool in this first Burp Suite tutorial because this is probably the tool I use most. I also used the Burp Suite Intruder tool to find the Facebook vulnerability I reported last year.

The reason I started using the Intruder tool was to automate input validation testing. I had created a large amount of test inputs which were used to test for input validation weaknesses (SQL Injection, XPATH Injection, Cross Site Scripting etc) in web applications. The amount of test inputs I’d created made manual testing infeasible so I needed a tool that would take these inputs and automatically make the 500+ requests I needed per input point. I found the Burp Suite and I now use the Intruder tool to help me execute these tests, hopefully you will be able to do the same after you have read this blog post.

Enabling the Burp Suite Proxy

To begin using the Burp Suite to test our example web application we need configure our web browser to use the Burp Suite as a proxy. The Burp Suite proxy will use port 8080 by default but you can change this if you want to.

You can see in the p_w_picpath below that I have configured Firefox to use the Burp Suite proxy for all traffic:

When you open the Burp Suite proxy tool you can check that the proxy is running by clicking on the options tab:

You can see that the proxy is using the default port:

The proxy is now running and ready to use. You can see that the proxy options tab has quite a few items that we can configure to meet our testing needs. A lot of these items are out side of the scope of this tutorial.

The Burp Suite will now begin logging the requests and responses that pass through the proxy. We have browsed to the logon page of our example application and the Burp Suite proxy has captured the request and response:

The logon page is very simple, we have two input points that we need to test for input validation weaknesses.

We need to capture a logon request and replace the username and password values with our test inputs.

To do this we must ensure that the Burp Suite proxy is configured to intercept our requests:

With the intercept enabled we will submit the logon form and send it to the intruder as you can see below:

The Burp Suite will send our request to the intruder tool so we can begin our testing. You can see the request in the intruder tool below:

The tool has automatically created payload positions for us. The payload positions are defined using the § character, the intruder will replace the value between two § characters with one of our test inputs.

The positions tab which is shown in the p_w_picpath above has four different attack types for you to choose from (definitions taken from http://www.portswigger.net/intruder/help.html) :

Sniper: This uses a single set of payloads. It targets each position in turn, and inserts each payload into that position in turn. Positions which are not targeted during a given request are not affected – the position markers are removed and any text which appears between them in the template remains unchanged. This attack type is useful for testing a number of data fields individually for a common vulnerability (e.g. cross-site scripting). The total number of requests generated in the attack is the product of the number of positions and the number of payloads in the payload set.

Battering Ram: This uses a single set of payloads. It iterates through the payloads, and inserts the same payload into all of the defined positions at once. This attack type is useful where an attack requires the same input to be inserted in multiple places within the HTTP request (e.g. a username within the Cookie header and within the message body). The total number of requests generated in the attack is the number of payloads in the payload set.

Pitchfork: This uses multiple payload sets. There is a different payload set for each defined position (up to a maximum of 8). The attack iterates through all payload sets simultaneously, and inserts one payload into each defined position. I.e., the first request will insert the first payload from payload set 1 into position 1 and the first payload from payload set 2 into position 2; the second request will insert the second payload from payload set 1 into position 1 and the second payload from payload set 2 into position 2, etc. This attack type is useful where an attack requires different but related input to be inserted in multiple places within the HTTP request (e.g. a username in one data field, and a known ID number corresponding to that username in another data field). The total number of requests generated by the attack is the number of payloads in the smallest payload set.

Cluster Bomb: This uses multiple payload sets. There is a different payload set for each defined position (up to a maximum of 8). The attack iterates through each payload set in turn, so that all permutations of payload combinations are tested. I.e., if there are two payload positions, the attack will place the first payload from payload set 1 into position 1, and iterate through all the payloads in payload set 2 in position 2; it will then place the second payload from payload set 1 into position 1, and iterate through all the payloads in payload set 2 in position 2. This attack type is useful where an attack requires different and unrelated input to be inserted in multiple places within the HTTP request (e.g. a username in one parameter, and an unknown password in another parameter). The total number of requests generated by the attack is the product of the number of payloads in all defined payload sets – this may be extremely large.

In this tutorial we are going to use the Sniper attack type to test both the username and password fields.

Selecting a payload

So far we have enabled the Burp Suite proxy, captured a request, sent it to the intruder tool and marked our payload positions. We now need to tell the intruder tool what values to insert into the positions.

To define our payloads we need to click on the payloads tab within the intruder tool:

We are going to use the sniper attack type in this example so we only have one payload set. The dropdown menu next to the payload set number allows you perform many different types of testing/data manipulation as you can see below (definitions taken fromhttp://www.portswigger.net/intruder/help.html):

Preset list: This is the simplest payload source, and configures a preset list of payload items

Runtime file: This payload source configures an external text file from which payloads will be read at runtime. This is useful when a very large list of predefined payloads is needed, to avoid holding the entire list in memory. One payload is read from each line of the file, hence payloads may not contain newline characters.

Custom iterator: This payload source provides a powerful way to generate custom permutations of characters or other items according to a given template. For example, a payroll application may identify individuals using a personnel number of the form AB/12; you may need to iterate through all possible personnel numbers to obtain the details of all individuals.

Character substitution: This payload source takes a preset list of payload items, and produces several payloads from each item by replacing individual characters in the item with different characters, according to customisable rules. This payload source is useful in password guessing attacks, e.g. for producing common variations on dictionary words.

Case substitution: This payload source takes a preset list of payload items, and produces one or more payloads from each item by adjusting the case of characters within each item. This payload source may be useful in password guessing attacks, e.g. for producing case variations on dictionary words.

Recursive grep: This payload set works together with the extract grep function. It allows payloads to be generated recursively on the basis of responses to earlier requests. The “extract grep” function captures a portion of a server response following a matched regular expression. With “recursive grep” payloads, the captured text from the previous server response is used as the payload for the subsequent request.

Illegal unicode: This payload source takes a preset list of payload items, and produces a number of payloads from each item by replacing a specified character within each item with illegal Unicode-encodings of a specified character. This payload source may be useful in attempting to circumvent input validation based on pattern-matching, for example defences against path traversal attacks which match on expected encodings of the ../ and ..\\ sequences.

Character blocks: This payload source generates character blocks of specific sizes using a given input string. It can be useful in detecting buffer overflow and other boundary condition vulnerabilities in software running in a native (unmanaged) context.

Numbers: This payload source generates numbers, either sequentially or at random, in a specified format.

Dates: This payload source generates dates between a specified range, at a specified interval, in a specified format. This payload source may be useful during data mining (e.g. trawling an order book for entries placed on different days) or brute forcing (e.g. guessing the date of birth component of a user’s credentials).

Brute forcer: This payload source generates a set of payloads of specified lengths which contain all possible permutations of a specified character set.

Null payloads: This payload source generates “null” payloads – i.e. zero-length strings. It can generate a specified number of null payloads, or continue indefinitely.

We are going to use a predefined list of inputs for our testing:

We also have several other options on the payload page which you might want to use during your testing. The “case” drop down menu allows you to perform case modification tasks on your payloads including changing all characters to uppercase or lowercase. You can also use regular expressions to match/replace values in your payloads.

The payloads can also be encoded or hashed if we need to during our testing. The options are (definitions taken from http://www.portswigger.net/intruder/help.html):

Do not encode: No processing is performed.

URL encode these characters: Any of the specified characters which appear within the payload string are URL-encoded (e.g. space characters are replaced by %20). This is useful where spaces or other problematic characters appear in payloads that are inserted into the URL or message body; these may cause some web servers to return errors unless properly encoded for safe transmission over HTTP.

Base 64 encode: This adds any specified prefix and suffix to the payload, and base-64 encodes the entire string. A possible use of this function is in brute forcing Basic HTTP authentication controls. Adding the prefix “username:” to the payload enables a simple word list to be used to perform password guessing against the specified username.

Hash: This adds any specified prefix and suffix to the payload, and takes a cryptographic checksum of the entire string, using the selected algorithm (MD5, SHA, etc). This function may be useful when attacking custom authentication schemes that use hashed values.

Configuring intruder options

The options tab in the intruder tool allows you to configure additional test parameters including a grep function, enabling a DOS mode and deciding how you want the Burp Suite to handle 3xx redirects.

For this example we are going to use the grep function to perform a simple pattern match. The Burp Suite will provide you with a default list of words to match against but we are going to remove these and add our own for this test.

The logon form that we are going to test uses an XML file containing usernames and passwords to authenticate our users. The username and password values we provide will be entered into an XPATH query. If the application fails to securely validate these values an XPATH Injection vulnerability could exist.

We want the intruder tool perform a pattern match for us using the word “XPATH”. This should allow us to easily identify any XPATH errors caused by our test inputs:

Executing our tests

The only thing left for us to do now is to execute our tests.

To start the intruder tool you need to click “intruder” on the top menu and then click on “start”:

A separate window will be opened which will show you each test, the payload used, the status code, length and in our case the tests which match our XPATH pattern match word:

You can see that some of the tests matched our pattern match word by looking at the tick boxes in the XPATH column.

To review the request and the response for each test you can double click any of the requests shown in the attack window.

We are going to review request 13 which entered a single quote (‘) into the username field:

This single quote caused an XPATH error to be thrown by the application:

So as you can see we have used the Burp Suite intruder tool to identify a potential XPATH injection vulnerability.

I hope you have found this blog post useful and I’m always interested in hearing any feedback you have.

SN