Introduction Burp Suite Part IV (Intruder Tab)
Burp Intruder is a tool for automating customized attacks against web applications. It is extremely powerful and configurable, and can be used to perform a huge range of tasks, from simple brute-force guessing of web directories through to active exploitation of complex blind SQL injection vulnerabilities.
How Intruder Works
Burp Intruder works by taking an HTTP request (called the "base request"), modifying the request in various systematic ways, issuing each modified version of the request, and analyzing the application's responses to identify interesting features.
For each attack, you must specify one or more sets of payloads, and the positions in the base request where the payloads are to be placed. Numerous methods of generating payloads are available (including simple lists of strings, numbers, dates, brute force, bit flipping, and many others). Payloads can be placed into payload positions using different algorithms.
Attack Target
Attack Target
This tab is used to configure the details of the target server for the attack. The required options are:
- Host - This is the IP address or hostname of the target server.
- Port - This is the port number of the HTTP/S service.
- Use HTTPS - This specifies whether SSL should be used.
The easiest way to configure these details is to select the request you want to attack anywhere within Burp, and choose the "Send to Intruder" option on the context menu. This will send the selected request to a new tab in Intruder, and will automatically populate the Target and Positions tabs.
(Click image for large view)
Payload Positions
This tab is used to configure the request template for the attack, together with payload markers, and the attack type (which determines the way in which payloads are assigned to payload positions).
Attack Type
Burp Intruder supports various attack types - These determine the way in which payloads are assigned to payload positions. The attack type can be selected using the drop-down above the request template editor. The following attack types are available:
- Sniper - This uses a single set of payloads. It targets each payload position in turn, and places each payload into that position in turn. Positions that are not targeted for a given request are not affected - the position markers are removed and any enclosed text that appears between them in the template remains unchanged. This attack type is useful for fuzzing a number of request parameters individually for common vulnerabilities. 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 places the same payload into all of the defined payload positions at once. This attack type is useful where an attack requires the same input to be inserted in multiple places within the request (e.g. a username within a Cookie and a body parameter). 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 20). The attack iterates through all payload sets simultaneously, and places one payload into each defined position. In other words, the first request will place 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 place 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 request (e.g. a username in one parameter, and a known ID number corresponding to that username in another parameter). The total number of requests generated in 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 20). 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 2 into position 2, and iterate through all the payloads in payload set 1 in position 1; it will then place the second payload from payload set 2 into position 2, and iterate through all the payloads in payload set 1 in position 1. This attack type is useful where an attack requires different and unrelated or unknown input to be inserted in multiple places within the request (e.g. when guessing credentials, a username in one parameter, and a password in another parameter). The total number of requests generated in the attack is the product of the number of payloads in all defined payload sets - this may be extremely large.
- Add § - If no text is selected, this inserts a single payload marker at the cursor position. If you have selected some text, a pair of markers are inserted enclosing the selected text.
- Clear § - This removes all position markers, either from the entire template or from the selected portion of the template.
- Auto § - This makes a guess as to where it might be useful to position payloads and places payload markers accordingly. This is useful to quickly mark positions suitable for fuzzing, but manual positioning is required for more customized attacks. If you have selected some text, markers are placed within the selected text only; otherwise, they are placed throughout the whole request template. The automatic placement of markers places payloads into the value of various types of request parameter, including:
b. Body parameters
c. Cookies
d. Multipart parameter attributes (e.g. the filename in file uploads)
e. XML data and element attributes
f. JSON parameters
You can configure whether the automatic payload positions will replace or append to the existing parameter values, via an option on the Intruder menu. Note that if a sub-portion of the request, but not the whole message body, contains data formatted using XML or JSON, you can automatically position payloads within this structure by manually selecting the exact block of formatted data, and using the "Auto" button to position payloads within it. This is useful, for example, when a multipart parameter value contains data in XML or JSON format.
- Refresh - This refreshes the syntax colorizing of the request template editor, if necessary.
- Clear - This deletes the entire request template.
Payloads
This tab is used to configure one or more payload sets. The number of payload sets depends on the attack type defined in the Positions tab. For many common tasks, such as fuzzing parameters, brute force guessing a user's password, or cycling through page identifiers, only a single payload set is needed.
The configuration steps needed to configure a payload set are as follows:
Payload set - Select if you wish to configure from the drop-down list.
Payload type - Select If you want to use from the drop-down list. A large number of payload types are available, and these are highly configurable, allowing you to quickly automate the generation of payloads for virtually any situation:
- Simple list
- Runtime file
- Custom iterator
- Character substitution
- Case modification
- Recursive grep
- Illegal Unicode
- Character blocks
- Numbers
- Dates
- Brute forcer
- Null payloads
- Character frobber
- Bit flipper
- Username generator
- ECB block shuffler
- Extension-generated
- Copy other payload
The payloads generated by the configured payload type can be further manipulated using various payload processing rules and payload encoding.
Payload Processing Rules
You can define rules to perform various processing tasks on each payload before it is used. The defined rules are executed in sequence, and can be toggled on and off to help debug any problems with the configuration. Payload processing rules are useful in many kinds of situation where you need to generate unusual payloads, or need to wrap payloads up within a wider structure or encoding scheme prior to use.
The following types of rule are available:
- Add prefix - This adds a literal prefix before the payload.
- Add suffix - This adds a literal suffix after the payload.
- Match / replace - This replaces any parts of the payload that match a specific regular expression, with a literal string.
- Substring - This extracts a sub-portion of the payloads, starting from a specified offset (0-indexed) and up to a specified length.
- Reverse substring - This functions as for the substring rule, but the end offset is specified counting backwards from the end of the payload, and the length is counted backwards from the end offset.
- Modify case - This modifies the case of the payload, if applicable. The same options are available as for the case modification payload type.
- Encode - This encodes the payload using various schemes: URL, HTML, Base64, ASCII hex or constructed strings for various platforms.
- Decode - This decodes the payload using various schemes: URL, HTML, Base64 or ASCII hex.
- Hash - This carries out a hashing operation on the payload.
- Add raw payload - This adds the raw payload value before or after the current processed value. It can be useful, for example, if you need to submit the same payload in both raw and hashed form.
- Skip if matches regex - This checks whether the current processed value matches a specified regular expression, and if so, skips the payload and moves onto the next one. This can be useful, for example, if you know that a parameter value must have a minimum length and want to skip any values in a list that are shorter than this length.
- Invoke Burp extension - This invokes a Burp extension to process the payloads. The extension must have registered an Intruder payload processor. You can select the required processor from the list of available processors that have been registered by currently loaded extensions.
You can configure which characters within the payload should be URL-encoded for safe transmission within HTTP requests. Any configured URL-encoding is applied last, after any payload processing rules have executed.
It is recommended to use this setting for final URL-encoding, rather than a payload processing rule, because the payload grep option can be used to check responses for echoed payloads before the final URL-encoding is applied.
Options
This tab contains Intruder attack options for request headers, the request engine, attack results, grep match, grep extract, grep payloads, and redirections. You can edit these options in the main Intruder UI before launching an attack, and most settings can also be modified in the attack window when the attack is already running.
Request Headers
These settings control whether Intruder updates the configured request headers during attacks. Note that you have full control over the request headers via the request template in the payload positions tab. These options can be used to update those headers per-request in ways that are normally helpful.
The following options are available:
- Update Content-Length header - This option causes Intruder to add or update the Content-Length header in each request, with the correct value for the length of the HTTP body of that particular request. This feature is usually essential for attacks that insert variable-length payloads into the body of the template HTTP request. If the correct value is not specified, then the target server may return an error, may respond to an incomplete request, or may wait indefinitely for further data to be received in the request.
- Set Connection: close - This option causes Intruder to add or update the Connection header with the value "close". In some cases (when the server does not itself return a valid Content-Length or Transfer-Encoding header), this option may allow attacks to be performed more quickly.
These settings control the engine used for making HTTP requests in the Intruder attack. The following options are available:
- Number of threads - [Pro version] This option controls the number of concurrent requests the attack is able to make.
- Number of retries on network failure - If a connection error or other network problem occurs, Burp will retry the request the specified number of times before giving up and moving on. Intermittent network failures are common when testing, so it is best to retry the request several times when a failure occurs.
- Pause before retry - When retrying a failed request, Burp will wait the specified time (in milliseconds) following the failure before retrying. If the server is being overwhelmed with traffic, or an intermittent problem is occurring, it is best to wait a short time before retrying.
- Throttle between requests - Optionally, Burp can wait a specified delay (in milliseconds) before every request. This option is useful to avoid overloading the application, or to be more stealthy. Alternatively, you can configure a variable delay (with a given start value and increment). This option can be useful to test the session timeout interval enforced by the application.
- Start time - This option lets you configure the attack to start immediately, or after a specified delay, or to start in a paused state. These alternatives can be useful if an attack is being configured which will be executed at some future point, or saved for future use.
Attack Results
These settings control what information is captured in the attack results. The following options are available:
- Store requests / responses - These options determine whether the attack will save the contents of individual requests and responses. Saving requests and responses consumes disk space in your temporary directory, but enables you to view these in full during an attack, repeat individual requests if necessary, and send them to other Burp tools.
- Make unmodified baseline request - If this option is selected, then in addition to the configured attack requests, Burp will issue the template request with all payload positions set to their base values. This request will show as item #0 in the results table. Using this option is useful to provide a base response against which to compare the attack responses.
- Use denial-of-service mode - If this option is selected, then the attack will issue requests as normal but will not wait to process any responses received from the server. As soon as each request is issued, the TCP connection will be closed. This function can be used to perform application-layer denial-of-service attacks against vulnerable applications, by repeatedly sending requests that initiate high-workload tasks on the server, while avoiding locking up local resources by holding sockets open waiting for the server to respond.
- Store full payloads - If this option is selected, Burp will store the full payload values for each result. This option consumes additional memory but may be required if you want to perform certain actions at runtime, such as modifying payload grep settings, or reissuing requests with a modified request template.
These settings can be used to flag result items containing specified expressions in the response. For each item configured in the list, Burp will add a new results column containing a checkbox indicating whether the item was found in each response. You can then sort on this column (by clicking the column header) to group the matched results together.
Using this option can be very powerful in helping to analyze large sets of results, and quickly identifying interesting items. For example, in password guessing attacks, scanning for phrases such as "password incorrect" or "login successful" can locate successful logins; in testing for SQL injection vulnerabilities, scanning for messages containing "ODBC", "error", etc. can identify vulnerable parameters.
In addition to the list of expressions to match, the following options are available:
- Match type - This specifies whether the expressions are simple strings or regular expressions.
- Case sensitive match - This specifies whether the check for the expression should be case sensitive.
- Exclude HTTP headers - This specifies whether the HTTP response headers should be excluded from the check.
Grep - Extract
These settings can be used to extract useful information from responses into the attack results table. For each item configured in the list, Burp will add a new results column containing the text that was extracted for that item. You can then sort on this column (by clicking the column header) to order the extracted data.
This option is useful for mining data from the application and can support a wide range of attacks. For example, if you are cycling through a range of document IDs, you can extract the page title of each document looking for interesting items. If you have found a function that returns details of other application users, you can iterate through user IDs and retrieve relevant fields about users looking for administrative accounts or even passwords. If a "forgotten password" function takes a username as a parameter and returns a user-configured password hint, you can run through a list of common usernames and harvest all the associated password hints, and then visually scan through the list looking for easily guessed passwords.
If the same matching item is added multiple times in succession, then each server response will be searched for multiple occurrences of that expression, and the text immediately following each occurrence will be captured. This can be useful, for example when an HTML table contains useful information but there are no unique prefixes with which to automatically pick out each item.
Grep - Payloads
These settings can be used to flag result items containing reflections of the submitted payload. If the option is enabled, Burp will add a new results column containing a checkbox indicating whether the value of the current payload was found in each response. (If more than one payload set is used, a separate column will be added for each payload set.)
This feature can be useful in detecting cross-site scripting and other response injection vulnerabilities, which can arise when user input is dynamically inserted into the application's response.
The following options are available:
- Case sensitive match - This specifies whether the check for the payload should be case sensitive.
- Exclude HTTP headers - This specifies whether the HTTP response headers should be excluded from the check.
- Match against pre-URL-encoded payloads - It is normal to configure Intruder to URL-encode payloads within requests. However, these are normally decoded by the application and echoed in their original form. You can use this option to make Burp check responses for payloads in their pre-encoded form.
These settings control how Burp handles redirections when performing attacks. It is often necessary to follow redirections to achieve the objectives of your attack. For example, in a password guessing attack, the result of each attempt might only be displayed by following a redirection. When fuzzing, relevant feedback might only appear in an error message that is returned after an initial redirection response.
The following options are available:
Follow redirections - This setting controls the targets of redirections that are followed. The following options are available:
- Never - Intruder will not follow any redirections.
- On-site only - Intruder will only follow redirections to the same web "site", i.e. to URLs employing the same host, port and protocol as was used in the original request.
- In-scope only - Intruder will only follow redirections to URLs that are within the suite-wide target scope.
- Always - Intruder will follow redirections to any URL whatsoever. You should use this option with caution - occasionally, web applications relay your request parameters in redirections to third-parties, and by following redirections you may inadvertently attack an application that you do not intend to.
(Click image for large view)
Source : Burp Suite Official Site
Like it ? Share it.
