Business as usual

As a UK-based creator of "hacking tools", I have more than a passing interest in the new amendments to the Computer Misuse Act. These have been on the statute book for over a year, but have not yet come into force. The new law makes it illegal to supply software "believing that it is likely to be used to commit an offence".

Burp was downloaded 10,483 times last month. Were all of these used for lawful purposes? I would say it is absolutely certain that some people who download Burp use it unlawfully, and the same goes for any other popular security tool.

The arguments about "dual use" software are well worn, and scarcely need repeating. The same tools that are used by criminal attackers are also used in legitimate security testing. Demonstrating what attackers can do helps people to defend against them. Blanket restrictions will only penalise the good guys.

The same situation exists in many other domains which, being more familiar, do not invite such ill-considered legislation. Kitchen knives can be used for chopping food or for stabbing people. Manufacturers know that it is likely that some of their products will be used unlawfully. But we don't ban the production of kitchen knives - we just make it illegal to stab people.

The British Crown Prosecution Service has this week published its guidance on the new law, which responds to the preceding objections. The guidance notes the existence of a "legitimate industry" producing software "to test and/or audit hardware and software". This software may have a "dual use" and so prosecutors need to ascertain that a suspect has a criminal intent.

How can this be done? The following factors are relevant, says the CPS:

• Does the distributor have in place robust and up to date contracts, terms and conditions or acceptable use polices?

• Are users made aware of the Computer Misuse Act and what is lawful and unlawful?

• Do users have to sign a declaration that they do not intend to contravene the CMA?

• What thought did the suspect give as to who would use the software; for example, was it circulated to a closed and vetted list of IT security professionals or posted openly?

• Has the software been developed primarily, deliberately and for the sole purpose of gaining unauthorised access to computer material?

• Is the software available on a wide scale commercial basis and sold through legitimate channels?

• Is the software widely used for legitimate purposes?

• Does it have a substantial installation base?

• What was the context in which the article was used to commit the offence compared with its original intended purpose?

This is a weird set of considerations, several of which can be trivially complied with by any criminal wishing to cover themselves. Some of the other factors apparently assume that "good" software must be sold commercially and widely used, and hence presumably that small-scale, freely distributed tools are "bad".

The function of CPS guidance is not to determine what is legal, but rather to advise prosecutors who to pursue. Taken together, the law and guidance leave a huge amount of discretion within the legal process. The net of literal illegality is cast very widely, and prosecutors are told to ask a set of vague questions about an individual's intentions when deciding whether to take action. In other words, everyone producing hacking tools is criminalised, and it will be up to prosecutors which people they don't like the look of. Most legal processes involve some discretion, but too much can be a bad thing, particularly when the parties involved don't really understand the subject matter. Would you like to take your chances against the British judge in a computer crime trial who asked lawyers to explain what a website is?

I don't plan to stop distributing or updating Burp any time soon. This is clearly a crap law, but I'm guessing that prosecutions will be rare, and that I'll be some way down anyone's target list. Oh, and keep it legal, kids.

Burp Suite v1.1 released

I'm pleased to announce that the release version of Burp Suite v1.1 is now available. You can download the software and read about what is new here.

Thanks to everyone who downloaded the beta version and gave me their feedback - this was much appreciated. Burp should hopefully work properly in many kinds of usage scenarios and platforms that I'm unable to test myself.

The new burp beta

The beta version of the new release of Burp Suite is now available.

This is a major release, containing several new tools and features. Highlights include:

• Improved analysis and rendering of HTTP requests and responses wherever they appear.

• Burp Sequencer, a new tool for analysing session token randomness.

• Burp Decoder, a new tool for performing manual and intelligent decoding and encoding of application data.

• Burp Comparer, a new utility for performing a visual diff of any two data items.

• Support for custom client certificates (in all tools) and custom server certificates in Burp Proxy.

• Ability to follow 3xx redirects in Burp Intruder and Repeater attacks.

• Improved interception and match-and-replace rules in Burp Proxy.

• A fix for the Intruder payload positions bug affecting some Linux users.

• A "lean mode", for users who prefer less functionality and a smaller resource footprint.

I'm aiming to complete the final release fairly shortly, so if you have any problems or bugs, please let me know as soon as possible, either via email or in the comments. The new release requires Java version 1.5 or later, so make sure you have the latest JRE installed.

Update: some people using JRE version 1.5 have been having problems, with NoSuchMethodError getting thrown in java.nio.charset.Charset. I thought this class was supported from 1.4 onwards, but it seems it isn't implemented in all JRE's. Switching to JRE 1.6 ought to fix the problem (not an option for Mac users, I know, although this may help you). I'll see if I can get around having to use that class for the final release.

Update2: I fixed the problem preventing the beta running on Java 1.5. Try v2 below if this was causing you problems.

Download beta v2.

beta v1. [doesn't run on Java v1.5]

Introducing Burp Sequencer

This is a preview of a new addition to the Burp family of tools, which will be included in the next release of Burp Suite arriving later this year.

Burp Sequencer is a tool for evaluating the randomness of session tokens or other data. Think Stompy on steroids, with more tests, quantitative results, graphical reporting, and arbitrary sample sizes.

Burp Sequencer is easy to use. The first step is usually to locate a request within the target application which returns a session token somewhere in the response. You can do this using the "send to sequencer" option within any of the other Burp tools:



[click on any image to enlarge]

The request and response are displayed within Sequencer, allowing you to identify the location of the token you are interested in. Any cookies or form fields within the response are automatically parsed out for you to choose; alternatively, you can select an arbitrary position within the response where the token appears:



Once configured, Burp Sequencer begins acquiring tokens from the application by repeatedly issuing your request and extracting the relevant token from the application's responses:



As soon as 100 tokens have been captured, you can perform an analysis of the tokens, to get an initial rough indication of the quality of their randomness. Obviously, a larger sample size enables a more reliable analysis. The live capture continues until 20,000 tokens have been captured, which is sufficient to perform FIPS-compliant statistical tests.

If you have previously obtained a sample of tokens from the application (or from any other source) you can also load these manually into Burp Sequencer, to perform the same analysis on them:



Burp Sequencer can operate on any sample size between 100 and 20,000. The analysis mainly uses significance-based statistical tests in which the assumption that the tokens are random is tested by computing the probability of the observed results arising if this assumption is true. If the probability falls below a particular level (the "significance level") then the assumption is rejected and the anomalous data is judged to be non-random.

This approach allows Burp Sequencer to give an intuitive overall verdict regarding the quality of randomness of the sample. This summary shows the number of bits of effective entropy within the token for each level of significance:



To gain a deeper understanding of the properties of the sample, to identify the causes of any anomalies, and to assess the possibilities for token prediction, Burp Sequencer lets you drill down into the detail of each character- and bit-level test performed. The following screenshot shows the analysis of character distribution at each position within the token:

The following screenshot shows the results of the FIPS monobit test at each bit position within the token:

There are several other useful functions and configuration options affecting how tokens are captured and processed. Hopefully, Burp Sequencer will prove to be a valuable weapon in the web application hacker's arsenal, and will enable more effective and easier assessment of session token randomness than is possible with other current tools.

Intruder bugfix - nonstandard charsets

Just to placate the salivating hordes who accost me on a daily basis demanding to know when the next release of burp will be available, here is some more evidence that I'm not bluffing and work is actually well underway on the new release.

One annoying bug in Intruder is that the payload positioning marker doesn't work when the JRE is set to use some unusual character sets. Instead of the § character, the payload marker appears as a red box or some other character altogether, which doesn't get recognised when you try to launch an attack. This affected Japanese, some Linux users and other subversives whose character set wasn't set to en-US:

Well, the good news is that this has been fixed in the next release. You can download a beta of Intruder containing the fix here. I'd be most grateful if anyone who experienced this problem could try it out and let me know whether it works for you. If this bug didn't affect you, don't bother with the download as it contains nothing else that differs from the current release version.

Burp Suite feature requests - thank you

Thanks to everyone who responded to my request for suggestions. I've had over 100 messages in various forms, so there are plenty of ideas of what else to include. Here are just a few of the requests I will be aiming to incorporate (in addition to those I mentioned previously):

• token analyser;

• option for Intruder/Repeater to follow 3xx redirects;

• back/forward buttons in Proxy history;

• fixing the bug with the payload marker when some unusual character sets are used;

• doing automated find/replace in the message body as well as headers.

Probably the most optimistic request was: "Can you write hooks into all common networking and SSL libraries to make a process use a proxy even if it is not configured to natively?" I already did this for WinINet. But sorry, Ollie, I doubt I'll have the energy to do all the others!

As well as all the good ideas for new features, I received many requests for things that are already there, including:

• response interception;

• function to search each request/response;

• tree view of site being browsed;

• saving of preferences;

• NTLM authentication;

• support for upstream proxy.

Plenty of people emailed me "Great tool, I use it every day, can you make it do X?", when X has been there since day one. May I respectfully suggest that anyone who is missing the above features should take a quick look at the help (or even just the options panels) to find what they are looking for!

Burp Suite - feature requests please

Now that the manuscript for The Web Application Hacker's Handbook is out of the way, I'll have some proper time to think about the next release of Burp Suite. This will be a major upgrade with lots of new features in all of the tools, including:

• Improved rendering and analysis of HTTP messages wherever they appear [preview].

• Function to do a compare/diff between any set of requests and responses.

• Versatile decoder/encoder with intelligence to detect encoding types and do recursive decoding.

• Support for client SSL certificates.

• New payload generators in Intruder.

At this point, it would be good to hear any other feature requests that people have, however large or small. Please leave them in the comments and I'll address as many as I can.

ViewState snooping

I've been taking a look at the ASP.NET ViewState recently, and have done a (rather unscientific) survey of the way it is currently used on Internet-facing web applications. Here are a few statistics, based on a sample of more than 10,000 applications:

• version 1.1 - 54%

• version 2.0 - 46%

• MAC-enabled (v1.1) - 93%

• MAC-enabled (v2.0) - 89%

• encrypted - 4%

• average size - 16.8Kb

The largest ViewState I discovered was a whopping 3.8Mb in size, which appeared in a government web application displaying tables of statistics. Given that the ViewState is posted back to the server with each request, this application is seriously sluggish to use, even with a relatively fast connection.

I was surprised at the number of applications not using the EnableViewStateMac option, given that this is now set by default in ASP.NET. Without this option, the contents of the ViewState can be modified by the user, potentially affecting the application's processing in nefarious ways.

Even with EnableViewStateMac set, users can still decode and read the contents of the ViewState if it has not been encrypted. Application developers may use the ViewState to store arbitrary data, beyond the default serialisation of UI controls. I wonder how many attackers bother to decode and inspect the ViewState to check whether it contains anything of interest. The next version of Burp Suite will include a utility to deserialise and render the ViewState contents, to make this task trivial. A sneak preview is shown below:

Using recursive grep for harvesting data

Talking to someone the other day I realised that even many experienced users of burp don’t know what the "recursive grep" payload source is used for.

This payload source is different from all the others, because it generates each attack payload dynamically based upon the application’s response to the previous request. In some situations, this can be extremely useful when extracting data from a vulnerable application.

A typical situation is where you have an SQL injection bug that enables you to retrieve a single item of data at a time. To extract the entire contents of a table, you can use recursion to extract each value in turn on the basis of the previous value. For example, suppose you are attacking an MS-SQL database and have enumerated the structure of the table containing user credentials. Supplying the following input returns an informative error message containing the username which appears alphabetically first in this table:

' or 1 in (select min(username) from users where username > 'a')--

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'abigail' to a column of data type int.

This gives you the username 'abigail', which you can place into your next input to retrieve the username which appears alphabetically second:

' or 1 in (select min(username) from users where username > 'abigail')--

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'adam' to a column of data type int.

To extract all usernames, you can continue this process, inserting each discovered username into the next request until no more values are returned. However, performing this attack manually may be very laborious. You could write a script to do it in a few minutes. Or in a few seconds, you can configure the "recursive grep" function to perform the attack for you.

The first step is to capture the vulnerable request in burp proxy, and choose the "send to intruder" action. Then type your attack string into the vulnerable field, and position the payload markers around the part which you need to modify:



Next, in order to use "recursive grep" as a payload source, you need to configure "extract grep" to capture the username which is disclosed in each response. To do this, you tell intruder to capture the text following the error message

Syntax error converting the nvarchar value '

and to stop capturing when it reaches a single quotation mark:



Finally, you need to select the "recursive grep" payload source, select the single "extract grep" item you have configured, and specify the first payload as 'a':



That's it! Launching the attack will cause intruder to send 'a' in the first request, and in each subsequent request send the username which was extracted from the previous error message. Within seconds, you can dump out all of the usernames in the table:



You can select save/results table to export the username list. Equipped with this list, you can then use it as a conventional payload source to retrieve all of the passwords and other data, for example using requests of the form:

' or 1 in (select password from users where username = 'abigail')--

There are other cases where recursive grep can be useful, but this kind of attack was the one I mainly had in mind when I wrote it.