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.


emotional-stuntman said...

very helpful. thank you.

S. Hamid Kashfi said...

Hi ,

Not actually related to this post ,but since I had no other contact point I`m using here :

"match & replace" option in proxy section of Burp suite 1.2 seems broken !
I've no problem using this feature in 1.1 but it seems not working in 1.2 . Maybe something has changed in 1.2 that make it not working the way I use it on 1.2 ?

thanks for keeping this great project alive :)

PortSwigger said...

@S. Hamid Kashfi

Re contact point, there is an email link at the bottom of every page on my site.

Why don't you email me an example of a match/replace rule that isn't working for, and I'll look into it? Thanks.

Anonymous said...

I've used a commercial product called ProxyCap to create rules to redirect proxy-unaware apps. You can have a rule for each individual application and/or a default catch-all rule, and each rule can forward to a different local or remote proxy. You can even redirect Burp itself (javaw.exe) through a proxy such as TOR. I've heard FreeCap is a similar product, but I haven't used it myself.

Now that I think about it, built-in forward-proxy functionality would be a great feature addition for Burp, if it doesn't already exist.

Thank you.

Jabes said...

Really Triggering..

We ill enter in lan settings. Imagine already a Browser is connected via proxy server( Replacing loopback ip address( in already assigned ip address( causing no internet connectivity.. Plss Help.. Thanks in Advance...

Vince said...


I have a question which isn't actually related to this post but that I thought it could be.

My thick client authentifies to the server with a USB stored certificate (as in a smart card reader) which isn't, afak, usable (forwarded as is) by BURP. And then, the servers starts a HTTPS session authenticated with real CA certificate, which is replaced by BURP and then isn't shown to the client.

I thought a solution called "invisible proxying" could be the solution I'm looking for. But finally my problem is still entire.

Any idea how I could use Burp to use both the clientside token authentication, and forward the real CA certificate from the server ?