Burp Suite工具使用之二-Intruder模块介绍

Hi everyone,

 

 

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).

This tutorial will cover the Intruder tool; you can find tutorials for some of the other tools in older Security Ninja blog posts.

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 www.2cto.com in the image below that I have configured Firefox to use the Burp Suite proxy for all traffic.

When you open the Burp Suite proxy tool and 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 DVWA login page and the Burp Suite proxy has captured the request and response:

We are going to use the SQL Injection example in the DVWA for the rest of this tutorial. You can see in the image below that the SQL Injection example is quite simple for us to test:

We need to capture the User ID request after we click the submit button and replace the User ID value 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 User ID request 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. You can modify this behaviour by instructing the Burp Suite to automatically append your input to the original instead of replacing it as we have done in the example above. To instruct the Burp Suite to automatically position its payload markers to append data to your input rather than replace it you need to click on “append to base parameter value”:

The positions tab which is shown in the image 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 the User ID field.

You can perform a quick search in the positions tab to identify values of interest. We have performed a search below for the word “security”:

The positions tab provides several data encoding/decoding options. This allows us to encode/decode values in the positions tab. If you want to encode or decode any of the values in your request (or “anything” in the request) you can highlight and right click it, from the menu click on “convert selection”. I have selected our User ID value below to show how to encode a value:

I have encoded the User ID value using URL encoding:

We can convert our values into 4 different main types, each one is explained below:

URL Encoding: URL Encoding (otherwise known as Percent Encoding) is used to encode data that will be contained within a URL. The characters that are allowed in URLs are defined as either Reserved or Unreserved in RFC 3986. The reserved characters are defined as characters which can sometimes have a special meaning in URLs, the RFC states that amongst other things the Reserved character are used as delimiters in URLs.

HTML Encoding: In my opinion HTML Encoding is much simpler than URL Encoding. We will use HTML Encoding to represent characters which may have special meanings as a literal character. We use character entity references to replace these potentially dangerous characters with a symbolic name, the common character entity references are shown below (there are around 250 character entity references):

“&lt;” represents the < sign.

“&gt;” represents the > sign.

“&amp;” represents the & sign.

“&quot;” represents the “ mark.

Base64: Base64 is a generic term for any number of similar encoding schemes that encodes binary data by treating it numerically and translating it into a base 64 representation.

Constructed String: The constructed string option allows you to transform your values into a string that could be useful in code injection attacks. You can create Javascript, Microsoft SQL, Oracle and MySQL constructed strings.

I’ve included a screen shot below which shows a right angle bracket (<) encoded with all of the different encoding types:

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 from: http://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.

Char frobber: This operates on the existing base value of each payload position, or on a specified string. It cycles through the base string one character at a time, incrementing the ASCII code of that character by one. This payload source is useful when you are testing which parts of parameter’s values have an effect on the application’s response (such as portions of complex session tokens).

Bit flipper: This operates on the existing base value of each payload position, or on a specified string. It cycles through the base string one character at a time, flipping each bit in turn. You can configure which bits are to be flipped. You can configure the bit flipper either to operate on the literal base value, or to treat the base value as an ASCII hex string. This payload source can be useful in similar situations to the character frobber but where you need finer-grained control. For example, if session tokens or other parameter values contain meaningful data encrypted with a block cipher in CBC mode, it may be possible to change parts of the decrypted data systematically by modifying bits within the preceding cipher block. In this situation, you can use the bit flipper payload source to determine the effects of modifying individual bits within the encrypted value, and understand whether the application may be vulnerable.

Username generator: This payload source takes human names as input, and generates potential usernames using various common schemes.

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

The payloads can be modified using the processing rules in the payload processing rules section of the payloads tab. The payload processing rules almost need a blog post to themselves so I’d encourage you to test them out yourself. The rules that you can apply to your payloads are: (definitions taken from: http://www.portswigger.net):

Add prefix: Adds a prefix value to the payload

 

Add suffix: Adds a suffix value to the payload

Match/replace: Define a regular expression and a value to replace regular expression matches with.

Substring: From a specified offset up to a specified length

Reverse substring: As substring, but indexed from the end of the payload

Modify case: Same options as for the case substitution payload source

Encode: As URL, HTML, Base64, ASCII hex and constructed strings for various platforms

Decode: As URL, HTML, Base64 and ASCII hex

Hash: Create a hash, multiple hashing algorithms available (SHA-512, MD5 etc)

Add raw payload: this can be useful if you need to include the same payload in both raw and hashed form

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.

We can also instruct the Burp Suite to make a request without any values being modified which will be used a baseline request. This baseline request will be used to compare the attack requests against.

For this example we are going to 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 User ID field that we provide will be entered into an SQL query. If the application fails to securely validate this value a SQL Injection vulnerability could exist.

We want the intruder tool to perform a pattern match based on this string: “SQL syntax”. This should allow us to easily identify any SQL errors caused by our test inputs:

Saving our attack configuration

The test we have configured in this tutorial might only be used once but we can save our attack configuration so we can repeat this test in future. You can save your attack configuration by clicking on the Intruder menu item and choosing “save attack config”. You can save your tests with or without the payload positions:

As you can see in the image above you also load the attack configs by clicking on the Intruder menu item.

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 menu item and then click on “start attack”:

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 SQL syntax pattern match:

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

To review the request and the response for each test you can click any of the requests shown in the attack window. The request and response for the test will be shown in the bottom half of the intruder attack window.

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

This single quote caused a MySQL error to be thrown by the application:

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

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