BURPSUITE IN-DEPTH

NOTE: This post will be a much deeper and in-depth dive in to some of the functionality of Burp Suite. If you need a quicker overview, please visit my Burp Suite Basics post. 

Repeater

The repeater function of Burp Suite allows us to take a request captured by Proxy, edit it and send the same request repetitively. This makes repeater ideal for any manual poking around at an endpoint.

Basic Usage:

The repeater interface can be split in the 6 main sections. Refer to the image above:

1. List of requests that are going through Repeater.
2. Controls for the current request, these allow us to send/cancel a hanging request and go forwards/backwards in a request history.
3. Request/Response view. Requests are edited in the Request view and Responses will show up in the Response view.
4. Allows us to change the layout for the Request and Response view.
5. The inspector allows us to break requests apart and analyse and edit them in a more intuitive way than the raw editor.
6. The IP address or domain that is our target. 

Whilst we can craft requests by hand, it is often easier to capture a request in Proxy, then send that through to Repeater for editing/resending by right-clicking the request and choosing "Send to Repeater".

The below is an example of a request that has been sent to Repeater.

When we click "Send" the response section quickly populates.

We can change anything about the Request and press "Send" again. In the below example, changing the "Connection" header to open rather than close , which results in in a response "Connection" header with a value of keep-alive .

Repeater - Views:

We have several different ways of viewing the Reponses to our requests:

• Pretty: Default view. Takes raw response and make it easily human readable.
• Raw: Pure, un beautified response from the server.
• Hex: Byte view of the raw response. Useful is the response is a binary file.
• Render: Renders the page as it would appear in browser.

Just to the right of the view buttons is the "Show non-printable characters" button that allows us to view non display characters such as \n .

Repeater - Inspector:

Inspector is supplementary to the request/response fields of the Repeater window as all it does is breakdown the requests and responses in a more readable way. Using Intruder, we are able to edit, delete and add items such as headers, methods and protocols.

• Query Parameters: Refer to the data being sent to the server in the URL. In https://example.com/?item=1 there is a query parameter called "item" with a value of "1".
• Body Parameters: Have the same function as Query Parametes, but for POST requests. 
• Request Cookies: Modifiable list of the Cookies being sent with each request.
• Request Headers: Allow us to view, access and modify any headers being sent. Editing these can be useful when attempting to see how a webserver will respond to expected headers.
• Response Headers: Shows us the Response Headers from the web server after a request is made. Note that these will not be able to be edited as they are from the web server.

Intruder

Intruder allows us to automate requests, which is very useful when fuzzing or brute forcing. For example, we could capture a request containing a log in attempt with Proxy and then configure Intruder to swap out the usernames and passwords to brute force a log in. It is worth noting that whilst we can use Intruder in Burp Community, the speed is throttled unless using Burp Pro.

There are four Intruder sub-tabs:

• Positions: Allows us to choose the attack type and where we wish to insert our payloads in the request.
• Payloads: Allows us to select the values that will be inserted in to each of the positions we have defined in the Positions tab. These values can be from a wordlist to regexes based on server responses. We can also alter intruder behaviour; for example we can define pre-processing rules (such as adding a prefix/suffix, match and replace or skip if the payload matches a defined regex).
• Resource Pool: Mostly used in Burp Pro. Allows us to divide our resources between tasks, such as how much memory to dedicate to each task.
• Options: Primarily how Burp handles results and how Burp handles the attack itself. For example, we can choose to flag requests that contain specified pieces of text.

Intruder - Positions

When we perform an attack with Intruder, we first need to look at Positions as they tell Intruder where to insert payloads. Burp Suite will automatically try and identify the most likely payload position, marked with §. These positions can be changed/added/removed with the buttons on the right of the screenshot below.

Intruder - Attack Types

There are four attack types available:

• Sniper
• Battering Ram
• Pitchfork
• Cluster Bomb

Sniper:

Sniper is the most common attack type. When conducting a payload, we provide one set of payloads. For example, this could be a single file containing a wordlist. Intruder will take each payload in a "payload set" and put it in to each defined position in turn. 

For example, if there are two positions (username and password) and a wordlist of three (foo, bar, buzz), Sniper will try foo in the username, then bar, then buzz. It will then try foo in the password, then bar, the buzz. A way of calculating how many requests Sniper will make is:

requests = numberOfWords * numberOfPositions .

This makes Sniper very good at single-position attacks, for example brute forcing a password with an already known username or fuzzing for API endpoints.

Battering Ram:

Like Sniper, Battering Ram takes one set of payloads. Unlike Sniper, Battering Ram puts the same payload in every position rather than in each position in turn.

Pitchfork:

Pitchfork can be thought of as having multiple Snipers running Simultaneously. Where Sniper uses one payload set(which is uses on every position simultaneously), Pitchfork uses one payload set per position (up to a maximum of 20) and iterates through them all at once. 

For example, this would be useful in a data leak where a list of passwords and a list of usernames are leaked together. Pitchfork would iterate through the lists in the same position (usernames[i] and passwords[i]), so you could always log in to the user at the ith position. 

Pitchfork will always stop as soon as one of the wordlists are completed.

Cluster Bomb

Like Pitchfork, Cluster Bomb allows us to use multiple payloads (one per position, maximum of 20. However, whilst Pitchfork iterates through each payload set simultaneously, Cluster bomb iterates through each payload set individually, making sure that every possibly combination of payloads is tested.

It is worth noting that this attack type can create a huge amount of traffic. Coupled with the Intruder rate-limiting Burp Community, an attack with Cluster Bomb can take an incredibly long time.

Intruder - Payloads

The payloads Sub-Tab is split in to four sections:

• Payload Sets: Allows use to choose which position we want to configure a set for as well as what type of payload we would like to use. NOTE: When using an attack type that uses multiple payload sets, positions should be read from top to bottom, then left to right when being assigned numbers in the "Payload set" dropdown.
• Payload Options: These options will differ depending on payload type selected for the current payload set.
• Payload Processing: Allows us to define rules to be applied to each payload in the set before being sent to the target. For example we could capitalise every word or skip the payload if it matches a regex.
• Payload Encoding: Allows us to override the default URL encoding options. It can be sometimes useful to not URL encode standard "unsafe" characters, which is where this section comes in.

Intruder - Example

We have a log in screen that we wish to defeat with a list of usernames and passwords leaked from their website. We attempt a log in wish any credentials and catch the request in Burp Suite Proxy.

We send this request over to intruder,

We choose the Positions of the payloads (in this case a username field and a password field), and we choose the appropriate wordlist for each Position. We then press "Start Attack".

We are then presented with a screen that shows us the different attack attempts. In order to find the successful log in we can first check the status codes for a 200 code, however all codes are 302 (a redirect code). Instead we check the length of response (in bytes) and look for any that stand out. 

Macros

Decoder, Comparer and Sequencer

Decoder, Comparer and Sequencer allow us to: work with encoded text; compare sets of text; and analyse the randomness of captured tokens, respectively. 

Decoder

Decoder allows us to decode data we capture during an attack and encode data of our own to send to a target. Decoder also allows to to create hashsums of data, as well as providing a Smart Decode feature which attempts to decode provided data recursively.

The Decoder Options tab includes:

1. Text to be encoded or decoded. Text can be sent here from other sections of Burp Suite but right-clicking and selecting Send to Decoder.
2. Treat the input as text or hexadecimal byte values.
3. Encode, Decode or Hash the input.
4. Smart Decode attempts to decode input automatically.

We can use this to manually encode text to formats such as:

• URL: Makes data safe to transfer in the URL of a web request (exchanging characters for their ASCII code in hex format, preceded by a % ). Useful in web application testing
• HTML: Replaces special characters with their HTML readable counterparts.
• Base64: A widely used encoding method.

We can also layer encoding on top of each other, such as HTML encoding some plain text, then Base64 encoding the outcome of that.

Smart Decoder attempts to automatically recognise and decode encoded text. Whilst it isn't a perfect feature, it is quick.

Decoder - Hashing

Hashing is a one-way process used to transform data into a unique signature. To be a good hashing algorithm, the resulting hash must be impossible to reverse. Decoder allows us to generate hashsums directly within Burp Suite.

The output of a hashing algorithm does not return pure ASCII/Unicode text, therefore it is common to take the output in the hexadecimal form.

Below is an example of a base64 hashsum created with the the plaintext input "Let's get Hashing!". The hashsum has then been base64 encoded.

Comparer

Comparer allows us to compare two pieces of data, either by ASCII words or by bytes. This can be useful if we wish to compare two responses from a web app after some log in attempts to see where the differences lie between a successful and failed log in.

Comparer can be split up in to three parts:

1. Items being compared. 
2. Options for inputting data to be compared, removing rows and clearing all data.
3. Option to compare datasets by either words or bytes. 

When data is loaded in to comparer we get the below pop up window:

1. Compared data, either in hex or text format.
2. The key for comparisons.
3. "Sync views" to ensure both sets of data will be in the same format.

See below for an example. The left is a failed log in attempt and the right a successful one:

Sequencer

Whilst sequencer is rarely used in CTF's or labs, it is used a lot in the real world. It is used to measure the entropy (or randomness) of "tokens". For example, we may wish to analyse the randomness of a CSRF (Cross Site Request Forgery) token protecting a form submission. If these tokens can be predicted, due to improper token generation then we may able to leverage this as part of an attack.

There are two main methods to perform token analysis with Sequencer:

• Live Capture: Allows us to pass thousands of requests automatically, storing any generated tokens for analysis.
• Manual load: Allows us to load a list of pre-generated token samples.

Live Capture

When we wish to analysis tokens using live capture, we capture the request in Proxy, and send it to Sequencer. We go to the Sequencer tab, then select the request we wish to execute Sequencer on.

Once this is selected, there is the option to choose between Cookie, Form field and Custom Location. In this case we have chosen to analyse the loginToken in the Form field.

We then press Start Live capture and we will begin automatically capturing loginTokens. We let this run until we have adequate tokens for analysis (around 10000) and then press Pause, then Analyse now. We hit pause instead of Stop, so we can continue capturing tokens if there are not enough for proper analysis.

Extender

The extender section of Burp Suite is designed to add functionality to Burp Suite through coding and the Burp App (BApp) Store. Extensions can be written in a variety of languages although most commonly Java.

If wishing to use languages that are not Java, we will need an interpreter:

• Jython: https://www.jython.org/download
• JRuby: Home — JRuby.org

If wishing to write your own Burp Suite Extension, please visit here for a guide by Portswigger.