This release fixes a bug affecting HTML scan reports for some users.
MD5: 74ac6b837dc3152bab26a5cc063f2428
SHA256: d68baa37933516f2c8a9851b5a3a3aa280e63d740b2bf4f570f9c08209162ae0
Thursday, April 11, 2013
Wednesday, April 10, 2013
v1.5.10
This release includes the following additions:
SHA256: 465152985a1f3b3c174d2d6057a374a98e1241486bdc537c83f2dad3eefd903b
- In-tool updates for future releases. From the next release, you will be able to download updates from within Burp itself, without needing to log in to our website.
- A new improved Scanner reporting format. View a sample report.
- A new API for generating Scanner reports programmatically: IBurpExtenderCallbacks.generateScanReport().
- Fixes for some issues that prevented Burp from working with some PKCS#11 smart cards.
SHA256: 465152985a1f3b3c174d2d6057a374a98e1241486bdc537c83f2dad3eefd903b
Tuesday, March 26, 2013
v1.5.09
This release adds support for PKCS#11 client SSL certificates contained in smart cards and other physical tokens. These can be configured at Options / SSL / Client SSL Certificates.
Key features include:
This release also adds an option to encrypt passwords contained in Burp's configuration options when these are saved in persisted preferences or Burp state files. This option is available via the Burp menu / Remember settings / Passwords, and also within the save state wizard. If the option is selected, Burp will prompt you for a master password with which to encrypt individual passwords. The master password is not saved anywhere. When the settings are later restored, Burp will prompt you for the master password to decrypt the individual passwords. For those who are interested, this feature uses AES encryption with a 128-bit key generated from your password using PKCS#5v2.0.
MD5: b5a6b8c240ae4ee1c3c26273a95c4a8f
SHA256: 69d339db54e50d8732096305199d4e3f758b1e881269427deea1f65315471d34
Key features include:
- Ability to configure multiple PKCS#11 and PKCS#12 certificates for use with different hosts (or host wildcard masks) .
- Auto-detection of installed PKCS#11 libraries (currently Windows only).
- Auto-detection of card slot settings.
- Support for OS X, Linux and 32-bit Windows (note that Oracle Java does not currently support PKCS#11 on 64-bit Windows).
- Persistence of configuration across reloads of Burp.
This release also adds an option to encrypt passwords contained in Burp's configuration options when these are saved in persisted preferences or Burp state files. This option is available via the Burp menu / Remember settings / Passwords, and also within the save state wizard. If the option is selected, Burp will prompt you for a master password with which to encrypt individual passwords. The master password is not saved anywhere. When the settings are later restored, Burp will prompt you for the master password to decrypt the individual passwords. For those who are interested, this feature uses AES encryption with a 128-bit key generated from your password using PKCS#5v2.0.
MD5: b5a6b8c240ae4ee1c3c26273a95c4a8f
SHA256: 69d339db54e50d8732096305199d4e3f758b1e881269427deea1f65315471d34
Tuesday, March 12, 2013
v1.5.08
This release includes various minor enhancements and bugfixes, including:
SHA256: 5090c9a2d2feb4cb73f7c0377beb57dc909ee07363a415aba59d320c167c1904
- The Proxy has a new option to unpack compressed request bodies (previously only compressed responses were supported). This option is off by default as it may break some applications that require compressed requests.
- Decompression of compressed content now works with .NET DeflateStream compression, and a bug affecting some other deflate implementations has been fixed.
- The default Proxy match and replace rules include an available item to remove the Accept-Encoding header in requests, to deter servers from compressing response content.
- The active scan queue is now much more responsive, in terms of providing real-time information about progress, and responding to cancel/pause actions.
- A bug affecting NTLM negotiation with some servers has been fixed.
- A bug which occasionally caused the Proxy history filter panel to become uneditable has been fixed.
- A bug affecting the generation of per-host SSL certificates using a custom CA certificate that has been imported from another tool, has been fixed.
- The function to save and restore state now provides verbose debug output on error, to facilitate debugging of problems.
- A bug affecting the parsing of some ASP.NET ViewState structures has been resolved.
SHA256: 5090c9a2d2feb4cb73f7c0377beb57dc909ee07363a415aba59d320c167c1904
Wednesday, February 27, 2013
v1.5.07
This release fixes a bug introduced in yesterday's release that prevented the button to add a new extension from working in some situations.
MD5: 215792296cd2628e2de8121b416cb476
SHA256: 1160ade5291dd2ebf8b7279b9aec5eafd5f1145fc5243af1888428a9d616b84c
MD5: 215792296cd2628e2de8121b416cb476
SHA256: 1160ade5291dd2ebf8b7279b9aec5eafd5f1145fc5243af1888428a9d616b84c
Tuesday, February 26, 2013
v1.5.06
This release adds a number of useful new features and bugfixes.
The cross-domain XHR technique requires a modern browser that is capable of cross-origin resource sharing (CORS). CORS allows XHR to make arbitrary cross-domain requests. However, if a request contains any "non-standard" features (method, headers or content type) then the request is "preflighted". Here, the browser first verifies whether the destination server is configured to accept cross-domain requests of the relevant type, and this will normally cause the attack to fail. On the other hand, if a request contains only "simple" features (roughly, those that can be generated using a standard HTML form) then the request is not preflighted: the browser simply makes the full cross-domain request, and adds an Origin header identifying the domain from which the request originated. Servers will typically ignore the Origin header and process the request in the normal way.
The loophole provided by the XHR technique is that it allows us to create requests with a "normal" Content-Type header together with completely arbitrary content in the message body. So in the case of cross-domain file upload, we can include the required filename attribute in a way that cannot be done in a pure HTML form (unless, of course, the victim user is induced into selecting a file to upload).
The following points should be noted about the cross-domain XHR technique:
Two new options are also available to help work around common problems in SSL negotiation:
SHA256: d2afec9496756320e3d9df60879340049f155ffd63e63e74b60225e264130a6d
New CSRF technique
The CSRF PoC generator adds a new technique to generate requests using cross-domain XmlHttpRequest (XHR). This allows the submission of arbitrary binary request bodies together with any "standard" Content-Type header, including "application/x-www-form-urlencoded" and "multipart/form-data". One obvious use for the new technique is that it allows for cross-domain file upload, where a filename attribute needs to be included in a multi-part message body.The cross-domain XHR technique requires a modern browser that is capable of cross-origin resource sharing (CORS). CORS allows XHR to make arbitrary cross-domain requests. However, if a request contains any "non-standard" features (method, headers or content type) then the request is "preflighted". Here, the browser first verifies whether the destination server is configured to accept cross-domain requests of the relevant type, and this will normally cause the attack to fail. On the other hand, if a request contains only "simple" features (roughly, those that can be generated using a standard HTML form) then the request is not preflighted: the browser simply makes the full cross-domain request, and adds an Origin header identifying the domain from which the request originated. Servers will typically ignore the Origin header and process the request in the normal way.
The loophole provided by the XHR technique is that it allows us to create requests with a "normal" Content-Type header together with completely arbitrary content in the message body. So in the case of cross-domain file upload, we can include the required filename attribute in a way that cannot be done in a pure HTML form (unless, of course, the victim user is induced into selecting a file to upload).
The following points should be noted about the cross-domain XHR technique:
- It includes the browser's cookies in the normal way, and so works with authenticated (in-session) requests.
- It requires a relatively recent browser, and works on current versions of Firefox, Internet Explorer and Chrome.
- The application's response is not processed by the browser in the normal way, so the technique is not suitable for making cross-domain requests to deliver reflected cross-site scripting (XSS) attacks.
- If you try to generate a PoC for a request containing any unusual features that may trigger a preflighted request, Burp will do its best to construct a valid PoC, and will warn you about the problematic features.
New SSL options
Several new options are available for SSL negotiation. You can now individually select which SSL protocols and ciphers to use:
Two new options are also available to help work around common problems in SSL negotiation:
- "Automatically select compatible SSL parameters on negotiation failure" - If this option is enabled, then when Burp fails to negotiate SSL using the configured protocols and ciphers, it will probe the server to try and establish a set of compatible SSL parameters that are supported by both the server and Java. If compatible parameters are found, Burp caches this information and uses the parameters in the first instance for subsequent connections to the same server. This option is generally desirable and can avoid the need to troubleshoot SSL issues and experiment with protocols and ciphers.
- "Enable algorithms blocked by Java security policy" - As of Java 7, the Java security policy can be used to block certain obsolete algorithms from being used in SSL negotiation, and some of these are blocked by default (such as MD2). Many live web servers have SSL certificates that use these obsolete algorithms, and it is not possible to connect to these servers using the default Java security policy. Enabling this option allows Burp to use the obsolete algorithms when connecting to the affected servers. Changes to this option take effect when you restart Burp.
Other updates
The release includes the following new features and bugfixes:- When doing invisible proxying of SSL connections, Burp now inspects the Client Hello message for the server_name extension. If this is present, Burp uses it to generate per-host CA-signed certificates in the normal way.
- To facilitate development and debugging of extensions, you can now fast-reload an extension by Ctrl+clicking the "Loaded" checkbox in the table of extensions. The extension will be unloaded and reloaded without displaying a confirmation dialog. Further, extensions will now reuse the existing output window if one was already created for that extension.
- The IInterceptedProxyMessage interface has two new methods, getListenerInterface and getClientIpAddress, which you can query to obtain details about the Burp Proxy listener and the client for the intercepted message.
- The scope configuration UI now lets you load a list of items from a text file. Each item in the list should be either a URL or a domain name, and Burp will create appropriate scope rules accordingly.
- A bug where sending requests from the Target Analyzer to other Burp tools always results in non-parameterized GET requests being sent, has been fixed.
- A bug in the display of messages where character set encoding is wrongly applied to HTTP headers, making them unreadable in some cases (e.g. UTF-16LE) has been fixed.
- There is a new workaround to try to prevent OS X from periodically deleting Burp's temporary files when using the default location.
SHA256: d2afec9496756320e3d9df60879340049f155ffd63e63e74b60225e264130a6d
Friday, February 15, 2013
v1.5.05
This release contains a number of feature enhancements and bugfixes, including:
SHA256: 30ed3751a34ba98a684aec42a2843b63d38e5fad157689dd67fa82b92f996cf5
- The SOCKS proxy support now has an option to perform DNS lookups remotely via the proxy. This enables Burp to access TOR hidden services, and to work in some unusual infrastructures. When this option is enabled, no local DNS lookups will be performed by Burp.
- The per-installation CA certificate and key used by Proxy listeners to create per-host certificates can now be exported for use with other tools or another instance of Burp. You can also import a certificate and key into the current instance. The export/import function can be accessed via the Proxy listener configuration panel. Note that you should not disclose the private key for your certificate to any untrusted party. A malicious attacker in possession of your certificate and key may be able to intercept your browser's HTTPS traffic even when you are not using Burp.
- Your CA certificate (not the key) can now be downloaded by visiting http://burp/cert in your browser (configured to use Burp as its proxy). This makes it easier to install the certificate on some mobile devices.
- The IBurpExtenderCallbacks interface has two new methods, unloadExtension and get CommandLineArguments.
- The implementation of per-extension persistent preferences has been modified to use sub-nodes of Burp's preferences store, allowing extensions to use much longer preference names. Preferences saved by extensions using earlier versions of Burp will unfortunately be lost.
- There is a new option in Burp Proxy's miscellenaeous options to disable logging to the Proxy history and target site map. This option may be useful if you are using Burp Proxy for some specific purpose, such as authenticating to upstream servers or performing match-and-replace operations, and you want to avoid incurring the memory and storage overhead that logging entails.
- The Target Analyzer function now includes a column in the parameters view to show the value observed for the selected parameter in each request that uses it.
- There is now a command-line license activation process for use in headless installations of Burp.
- Burp now allows interactive debugging of extensions.
SHA256: 30ed3751a34ba98a684aec42a2843b63d38e5fad157689dd67fa82b92f996cf5
Wednesday, January 9, 2013
v1.5.04
This release adds an in-tool repository for the new extensibility APIs. The Extender / APIs tab lists all of the interfaces available in the current build of Burp, and lets you browse these and save the interface and Javadoc files locally.
Various updates have been made to the draft extensibility API, based on user feedback:
The new API is now "final", in the sense that we only anticipate making small incremental changes to the API for the foreseeable future, and those changes should be backwards compatible.
The final API and links to all the sample extensions are available here.
MD5: b8504df0907180c7ac887273f309fc14
SHA256: 099a26e903c0021ebf9a208ad62e86b41f77a6f27e541b1e640656e04b6bb58c
Various updates have been made to the draft extensibility API, based on user feedback:
- IBurpExtenderCallbacks has two new methods, saveExtensionSetting() and loadExtensionSetting(), which extensions can use to persist configuration settings across reloads of the extension and of Burp.
- You can now register an IScopeChangeListener to be notified when changes occur to the suite-wide target scope.
- There is a new ICookie interface, for holding details of HTTP cookies.
- IResponseInfo has a new method, getCookies(), which you can use to obtain details of any cookies that were issued in a response.
- IRequestInfo has a new method, getBodyEncoding(), which you can use to determine the encoding used for the message body (URL, multipart, XML etc). Extensions that provide custom scanner checks can use this method to determine the appropriate encoding to apply to attack payloads that are being placed into insertion points in the request body.
- IBurpExtenderCallbacks has two new methods, getCookieJarContents() and updateCookieJar(), which extensions can use to query and update Burp's session handling cookie jar, for use when dealing with unusual session handling mechanisms.
- The IBurpExtenderCallbacks method customizeUiComponent() now cascades the action automatically to child components, to reduce the number of calls that you need to make to this method.
- The IIntruderPayloadGeneratorFactory method createNewInstance() now receives an instance of a new interface, IIntruderAttack, which the extension can use to obtain details about the Intruder attack in which the payload generator will be used.
The new API is now "final", in the sense that we only anticipate making small incremental changes to the API for the foreseeable future, and those changes should be backwards compatible.
The final API and links to all the sample extensions are available here.
MD5: b8504df0907180c7ac887273f309fc14
SHA256: 099a26e903c0021ebf9a208ad62e86b41f77a6f27e541b1e640656e04b6bb58c
Thursday, December 20, 2012
v1.5.03
This release fixes a number of bugs affecting the new extensibility:
SHA256: b2db3585ae986ac8eed21aa0cd1b0f96efe70a181c6181286986f2d4dbda619f
- Extensions are now automatically reloaded on startup when Burp is running in headless mode.
- A bug introduced in v1.5.02 where Burp won't load a new Python extension unless the JRuby JAR file has been configured, has been fixed.
- An exception that occurred when adding custom scan issues asynchronously (using IBurpExtenderCallbacks.addScanIssue()) has been fixed.
- A bug where all custom scan issues were reported in the UI with High severity has been fixed.
- When an IProxyListener sets one of the XXX_AND_REHOOK intercept actions, when the subsequent call to the listener occurs, the intercept action returned from IInterceptedProxyMessage.getInterceptAction() will now be the same value that was previously set (rather than defaulting back to ACTION_FOLLOW_RULES). This enables extensions to more easily re-identify messages that are being rehooked.
SHA256: b2db3585ae986ac8eed21aa0cd1b0f96efe70a181c6181286986f2d4dbda619f
Wednesday, December 19, 2012
v1.5.02
This release adds native support for Burp extensions written in Ruby. To use this feature, you'll need to download JRuby, and either configure the location of the JRuby JAR file within the Extender options, or load the JRuby JAR file on startup via the Java classpath.
The code for the following sample extensions has been updated to include versions written in Ruby, which you can use as a template for your own extensions if you wish:
[As with the Python examples, I'm new to Ruby, so apologies if the code isn't to your taste.]
This is still a beta release, pending feedback about the new extensibility framework.
MD5: f5c87fba7aa0c7c738bf2f91e7a4d0a5
SHA256: e36b591d1c2847f6c489b9aa91c8c28bc3ee3925371a868122ed328c95bdb6bf
The code for the following sample extensions has been updated to include versions written in Ruby, which you can use as a template for your own extensions if you wish:
[As with the Python examples, I'm new to Ruby, so apologies if the code isn't to your taste.]
This is still a beta release, pending feedback about the new extensibility framework.
MD5: f5c87fba7aa0c7c738bf2f91e7a4d0a5
SHA256: e36b591d1c2847f6c489b9aa91c8c28bc3ee3925371a868122ed328c95bdb6bf
Subscribe to:
Posts (Atom)


