Saturday, April 11, 2009

New release notes feed

I've been releasing updates to the Pro version of Burp pretty frequently recently. Some of these are fairly minor so you won't always see alerts that a new version is available. To help people who do want to follow the latest updates, you can now subscribe to a listing of release notes.

The latest update gives Burp a new editor for raw HTTP messages, which can handle much larger messages efficiently, supports undo/redo of edits, decodes encoded content in mouse-over popups, and auto-colourises request parameters and response syntax. Here's a preview for people who don't yet have it:

As well as being prettier, it's much nicer to work with, and helps you spot interesting data more easily. It even works on Macs too, if you're into that kind of thing. Hope you enjoy.

Friday, April 10, 2009

Intercepting thick client communications

I've written before about how Burp's invisible proxying mode can help you intercept requests from non-proxy-aware thick clients. Burp Suite Pro now contains a new feature which makes this task even easier.

If you are using a thick client component which cannot be configured to use a proxy, you can force it to talk to Burp Proxy instead of the actual destination host by performing the following steps:
  1. Modify your operating system hosts file to resolve the relevant destination hostnames to your loopback address (, for example:
  2. For each destination port used by the application (typically 80 and 443), start a proxy listener on this port of your loopback interface, and configure the listener to support invisible proxying.
With this set-up, the thick client will talk directly to Burp Proxy, thinking it is talking to the destination application, and Burp will accept and process the non-proxy-style requests it receives. When Burp processes these requests, it determines which actual destination host to forward them to based on the Host header in the requests. And this can lead to a problem if you have modified your hosts file as described above: Burp will resolve the hostnames to your loopback address, and will forward them back to itself, creating an infinite loop.

Previously, you could work around this problem by getting Burp to rewrite the Host header, or by using multiple machines with different DNS configurations for your testing. Now, things are much easier, because you can configure hostname resolution within Burp, to override the resolution provided by your operating system:

With this configuration, Burp will redirect outbound requests to the correct destination IP addresses, based on the Host header within each request. All being well, you should be able to intercept and forward traffic to multiple external domains, despite the thick client not itself supporting proxy connections.

One further complication may arise if your client does not include a Host header in its requests. If you are only dealing with one destination host, this is easily resolved: you can configure your proxy listener to redirect all traffic to a specific IP address. If you are dealing with multiple destination hosts, things get trickier again. You may be able to use Burp Extender to figure out the host based on the URL or other features of the request, and insert the correct Host header. Or you may be left with running Burp on multiple machines, and using your hosts file to redirect traffic for each destination host to a different intercepting machine.

Thursday, April 9, 2009

Burp problems after Windows update

If you use Windows, you may have encountered a problem following March's security update, in that Burp Proxy listeners running on the loopback interface stopped working. This was caused by Microsoft changing the "localhost" entry in the Windows hosts file from: localhost


::1 localhost

Manually reverting to the old entry fixes the problem for a while, but Windows will silently update to the new entry periodically. (Note that if you are running Windows Defender, you may need to dismiss some alerts in order to modify your hosts file.)

The latest versions of Burp (both free and Pro editions) have been updated to work with the new hosts entry. If you were having problems, please download the latest release and things should start working again.

Wednesday, April 8, 2009

Using Burp Extender

From time to time, people ask me for help getting their code working with Burp Extender, so here is a quick worked example of how to do this. The example is based on a plugin written by Daniele Costa, which extracts HTML comments from HTTP responses, and writes these to file and to the command line.

The core of the plugin code is simple. It implements the processProxyMessage method in IBurpExtender, to get a handle to all requests and responses passing through Burp Proxy. For response messages, it checks whether the requested URL is in scope, and if so uses a regular expression to match any HTML comments within the response. Anyone with some basic Java skills can create code like this. What may be less familiar is actually getting your code to load and run within Burp.

The steps to compile and run the plugin are as follows:
  1. If you don't already have it, download and install the Java Development Kit (JDK) from Sun.
  2. Create a directory to work in, and cd into it from the command line.
  3. Copy the plugin source file ( into your working directory.
  4. Create a subdirectory called "burp", and copy the file into this directory. You will need this file in the correct relative path, because the plugin code makes use of the IBurpExtenderCallbacks interface.
  5. In your working directory, compile the source file into a .class file using javac, the Java compiler. The exact command will depend on the location of your JDK - for example, on Windows, you might type: "\Program Files\Java\jdk1.6.0_04\bin\javac.exe"
  6. Confirm that the file BurpExtender.class has appeared in your working directory.
  7. Build a Java archive (JAR) file containing your .class file. Depending again on your JDK location, you might type: "\Program Files\Java\jdk1.6.0_04\bin\jar.exe" -cf burpextender.jar BurpExtender.class
  8. Confirm that the file burpextender.jar has appeared in your working directory.
  9. Copy your normal Burp JAR file into your working directory.
  10. Using the actual name of your Burp JAR file, start Burp using the command: java -Xmx512m -classpath burpextender.jar;burp.jar burp.StartBurp
If everything works, Burp should launch with a number of entries in the alerts tab, confirming which IBurpExtender methods were successfully loaded from your plugin (in this case, processProxyMessage and registerExtenderCallbacks):

To make use of the actual functionality of this plugin, you simply need to add the domains that interest you to Burp's Target Scope, and then browse to them via Burp Proxy. Any HTML comments contained within in-scope responses will be printed to the command line, and saved to a file in your working directory.