login

Burp Suite, the leading toolkit for web application security testing

Burp Suite release notes

Wednesday, December 9, 2015

1.6.32

This release introduces a brand new tool: Burp Clickbandit.

Burp Clickbandit is a tool for generating clickjacking attacks. When you have found a web page that may be vulnerable to clickjacking, you can use Burp Clickbandit to create an attack, to confirm that the vulnerability can be successfully exploited.

Burp Clickbandit is built in pure JavaScript, and is easy to use. In Burp, go to the Burp menu and choose "Burp Clickbandit". Copy the script to your clipboard, and paste it into the web developer console in your browser. It works on all modern browsers except for Microsoft IE and Edge.

For more details about how Burp Clickbandit works and how to use it, see the blog post.

This release also adds the following enhancements:
  • There is a new option in the Proxy to set the "Connection: close" header on incoming requests. Setting this header in requests can speed up the processing of the resulting responses from some target servers. The new option is on by default.
  • When generating the CA certificate used by the Proxy, Burp now uses a 2048-bit key if that is supported by the platform, and fails over to a 1024-bit key if not. Some modern clients are rejecting certificates that use a key length shorter than 2048 bits. If you encounter this problem, you can tell Burp to generate a new CA certificate at Proxy / Options / Proxy Listeners / Regenerate CA certificate, and you will need to install the regenerated certificate in your browser in the normal way.
Burp Suite Professional:
MD5: 60d496721e75bc7f73106991f68514ff
SHA256: 45563deb20309c9b4b79b771c76bc55631cdd030ae9c6c72b359cfb1d156e42d

Burp Suite Free Edition:
MD5: ea4e6bac280f854a2125e631a6c82a1c
SHA256: 7a27e95d86dc38cf261485c2050851715181cdce6b8cb0052239c5970fa94543

Wednesday, December 2, 2015

1.6.31

This release enhances Burp Scanner to report issues based on deferred interactions with the Burp Collaborator server.

Asynchronous server-side injection vulnerabilities are normally invisible in an application's responses, and completely elude conventional scanning techniques. To detect invisible vulnerabilities, Burp Scanner uses payloads that cause the application to make some kind of network connection to the Collaborator server. When an interaction with the Collaborator server is observed, this demonstrates that the payload was successful and a vulnerability is present.

In this release, invisible vulnerabilities are reported even when the interaction occurs after Burp has finished scanning the relevant item. After scanning has completed, Burp continues polling the Collaborator server in the background, and retrospectively reports issues when deferred interactions occur. This cutting-edge capability allows Burp to report all kinds of serious issues that are otherwise impossible to detect, for example:
  • Blind second-order SQL injection, where a payload gets stored and later used in an unsafe SQL query, with no behavioral evidence in the application's responses.
  • OS command injection in an overnight batch job that passes stored user input into shell commands in an unsafe way.
  • Asynchronous back-end SOAP/XML injection where user input is stored and later embedded in an XML-based message in an unsafe way.
Each Burp session uses a unique identifier to track Collaborator interactions, and this can optionally be included in the Burp state file when saving your work. This means that you can later reload a state file containing completed scans, and observe any asynchronous Collaborator interactions that have occurred since you finished the original scanning. On reloading the state file, Burp will poll the Collaborator server and report issues based on any new interactions that have occurred for that Burp session. 

Burp polls the Collaborator for asynchronous interactions every few minutes. When an asynchronous interaction is detected, Burp reports the issue without making any in-band requests to the target application. This means that you can safely revisit completed scans to pick up any asynchronous vulnerabilities even if the time window for testing is over. So imagine this: you finish testing on Friday without any decent issues; you load the Burp state file on Monday to start writing your report, and discover that one of your payloads has detected a command injection vulnerability in a shell script that runs over the weekend. Pretty cool?

[In fact, Burp began optionally saving Collaborator identifiers in state files starting with version 1.6.29. So if you have a state file from a test that was carried out with Burp 1.6.29 or later, you can reload it into the latest release to see if any deferred Collaborator interactions have occurred since you completed your testing.]

People are accustomed to seeing Burp report vulnerabilities during scanning, and not afterwards. To help users identify when deferred Collaborator interactions have occurred, a number of related useful features have been added:
  • The Scanner has a new "Issue activity" tab that contains a sequential record of when issues are created or updated. You can monitor this tab to view everything that is reported by the Scanner in time order, including detection of deferred Collaborator interactions.
  • When an issue is reported based on a deferred Collaborator interaction, the issue detail indicates the approximate elapsed time between the relevant scan completing and the interaction occurring.
  • The active scan queue has two new columns indicating the times that scanning started and ended for each item. This can help correlate the timings of Scanner activity and observed Collaborator interactions.
Note: The reporting of elapsed time between scan and interaction depends on some new capabilities in the Collaborator server. It is recommended that users who have deployed a private Collaborator server should upgrade to the latest Burp release, to gain the benefit of this feature.

In addition, some other updates have been made:
  • The BlazeDS library used for analyzing AMF messages has been updated to the latest version. This fixes some additional security vulnerabilities in BlazeDS's handling of malicious messages, which were found by the Burp research team. Since Burp version 1.6.29, Burp has disabled support for AMF messages by default, due to security concerns about the BlazeDS library. Any users who have enabled the option to support AMF messages should upgrade to the new release of Burp.
  • A problem comparing site maps from certain Burp state files has been fixed.
  • A problem installing some PKCS#11 certificates has been fixed.
  • All available command line arguments can now be listed by specifying the --help argument on the command line.
Burp Suite Professional
MD5: efdc0f3c468cbab6be3ae59c79e5bcdb
SHA256: 495f7ef5847836272678315a9d218b58534b11472cd041b5b954fb5926cdf79c

Burp Suite Free Edition
MD5: 425f0b339453c57e6628850381e36620
SHA256: 3e120b275e381840b549fcd9242950b1c74d4cc259b56b9422c11f00dfa26dc7

Support Center

Get help and join the community discussions at the Burp Suite Support Center.

Visit the Support Center ›

Copyright 2016 PortSwigger Ltd. All rights reserved.