Burpsuite 1.5 initiating TLS Connection on their IP to Port 443. What is it?

Question

I recently started using a security tool (Burpsuite 1.5) which has a free licence and a professional one. Upon downloading the free one from its vendor web-site (I am using BackTrack), I noticed within my Wireshark that every time I launch the tool, a TLS connection is made to the vendor’s IP on their port 443. This connection stays open and exchanging information for as long as the tool is kept open. Because I do not know what is being transmitted I blocked the outgoing traffic on my firewall to this IP: this did not impact on its usability. It might be paranoia, ignorance or both, but I don’t think I want this to be happening.

I have spent a couple of hours’ worth of research to see if the vendors would say anything about, which led me nowhere: perhaps I have not searched correctly, but I am intrigued by this from a learning point of view (and from a security perspective too, but to a lesser degree in this case). I have not directly contacted the vendor yet, mainly because I want to learn about it first, so my apologies if this is out of scope in here. However, a question if I may:

Is there a way of finding out what this is being sent?

Is there a more elegant way of stopping this from happening other than blocking the connection on my Firewall?

Answer 1

One thing you could look at is setting an upstream proxy in burp (either another instance of burp or a similar tool) and see if the traffic is then sent via that proxy. It may hit a problem with SSL certificate validity on the other hand might work. Assuming that it works, it would let you see within the SSL stream (although there could be further encryption of course).

To block the communication you could add an entry to your hosts file for the DNS name that it's contacting and redirect it to 127.0.0.1 as one option. You could also block it on your hosts firewall or if you're running it via a chained proxy as I mentioned above, you could likely block the traffic there too (depending on which tool you use.)

Another thing I'd recommend is asking in the the PortSwigger Forums, they're usually reasonably responsive, so you could well get an answer there.

Answer 2

Burp Suite is written in Java; Java bytecode is easy to reverse-engineer, to the point that decompilers can be written. Looking at the entrails of Burp Suite would be the most direct way to determine what is going on.

Legal framework on reverse engineering varies, depending on the country. In Europe, it tends to be allowed as long as it is for interoperability purposes -- which does not really apply to your situation. Therefore, the safest way to determine what is going on is to ask the vendor.

Another method, which might be considered as not pertaining to reverse-engineering, would be to intercept the SSL/TLS layer. This assumes that Burp Suite does not include its own SSL/TLS code, but instead uses the support provided by Java. In the Java architecture, this uses providers; the default SSL/TLS provider being SunJSSE. Perhaps adding your own provider and registering as default would be enough; or perhaps modifying SunJSSE in your VM would do the trick. Either way, a provider you control could record the exchanged data in files. Possibly, Burp Suite not only uses SunJSSE but also the default store of "root CA" included in the JVM to validate the server's certificate; in that case, you would just have to make a CA of your own, install it, make a fake certificate for the target server, and then use Fiddler to obtain the data. This would be the fastest way to determine what is going on.

Answer 3

the first place I always go to when this sort of thing happens is the licence. It looks like 2.2.6 prevents us from reverse engineering and poking around in the javacode to see what this code does...

There is nothing else that I can see in this licence that allows call-home functionality and it's a pretty poor quality licence for not mentioning it.