Home
Blog
Burp suite
Burp scanner
Burp intruder
Burp proxy
Books
Misc
RSS
|
|

skip to main |
skip to sidebar
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.
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: Modify your operating system hosts file to resolve the relevant destination hostnames to your loopback address (127.0.0.1), for example:
127.0.0.1 www.example.org 127.0.0.1 secure.example.org
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.
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: 127.0.0.1 localhost to: ::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.
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.
If you want to play with this example yourself, you can download the source code. The steps to compile and run the plugin are as follows: If you don't already have it, download and install the Java Development Kit (JDK) from Sun.
Create a directory to work in, and cd into it from the command line. Copy the plugin source file (BurpExtender.java) into your working directory. Create a subdirectory called "burp", and copy the IBurpExtenderCallbacks.java file into this directory. You will need this file in the correct relative path, because the plugin code makes use of the IBurpExtenderCallbacks interface. In your working directory, compile the BurpExtender.java 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" BurpExtender.java Confirm that the file BurpExtender.class has appeared in your working directory. 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 Confirm that the file burpextender.jar has appeared in your working directory. Copy your normal Burp JAR file into your working directory. 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.
Burp Suite v1.2 is now available to download. This is a major upgrade with a host of new features, including: Site map showing information accumulated about target applications in tree and table form Suite-level target scope configuration, driving numerous individual tool actions Display filters on site map and Proxy request history Suite-wide search function Support for invisible proxying Fully fledged web vulnerability scanner [Pro version only] Ability to save and restore state [Pro version only]
The series of posts below this one describe the new features in more detail. Many thanks to everyone who helped with the beta testing and gave me their feedback - this was much appreciated. Have fun!
A beta version of the new release of Burp Suite Professional is now available to licensed users. The free edition will be made available in two or three weeks time. If you just can't wait that long to get your hands on the new Burp, there is an easy solution! If you bought or renewed your Burp license within the last year, you should today have received the new beta. If you think you have missed out, or have any other licensing questions, please email us directly. If you have feedback about the beta, including bugs, either email us or use the comments below. There are still one or two bugs that we are aware of, and presumably many that we are not, so today will see a freeze on functionality changes, and a focus on ironing out any glitches. The final edition will be released just as soon as we are happy with it, but the beta release is highly stable and suitable for day-to-day working right away. Have fun!
Here is a feature that has been frequently requested, and which, like Burp Scanner, will be restricted to the professional edition of Burp. The new version of Burp lets you save the state and configuration of the key tools, and restore this on another occasion. This facility is of huge benefit to penetration testers, enabling you to seamlessly resume yesterday's work, perform backups of key information throughout a job, and take a complete archive of the information accumulated at the end of an engagement. You can also create as many customised configurations of suite tools as you want, and save each configuration separately for reuse on future occasions. The items that can be saved include: The target site map, which includes all of the content discovered via the proxy and spider. The proxy history. The issues identified by the scanner. The contents and histories of the repeater tabs. The configuration of all suite tools.
The save and restore process is fully configurable, and really easy. First off, you select "save state" from the Burp menu: This launches a wizard which lets you choose which items you want to save the state and configuration of:  You then choose your output file, and Burp does the rest: To restore previously saved state and configuration, you select "restore state" from the Burp menu. Each save file can include the state and configuration for any combinations of tools, and Burp lets you choose which tools you want to restore, and how to do it (whether to add to or replace their existing state):  Again, Burp goes to work and restores everything you have selected: In our testing, this new feature is working beautifully. Obviously, the files can grow pretty large, because they include the full requests and responses accumulated within the tools you are saving. A few hours' testing will typically save or restore in a minute or two. You can make this process leaner and quicker by deleting unneeded items from the site map and proxy history before performing a save. I hope that everyone who has this feature will get into the habit of using it. Picking up exactly where you left off the night before is a time saver. Being able to re-open your work from a completed job, to answer a client question or re-test a fixed issue, is a real benefit. If your colleague has fully enumerated an application's content, they can save this out for you to add to the current state of your instance of Burp to save you duplicating the effort. If you have worked on a problem for a while and got stuck, you can pass your entire work to someone else to think about. And team leaders can optimise Burp's configuration for a particular engagement, including fine-grained target scope definition, and pass this configuration straight to other team members to begin testing. You can create configuration templates designed for different kinds of task, and switch between these easily. There are probably plenty of other applications of this new functionality - let me know if you think of any.
|
|