Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
2  
I'm actually quite curious about this –  Lucas Kauffman Jan 28 '13 at 11:37
    
A new dimension of 'security theater'... –  Deer Hunter Jan 28 '13 at 11:45

3 Answers 3

up vote 3 down vote accepted

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.

share|improve this answer
    
It seems that this should be enough to keep me busy as well as what has been posted by Thomas Pornin. Thanks @Rory. –  Lex Jan 28 '13 at 13:24

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.

share|improve this answer
    
That's sensible. Both answers, yours and @Rory are very satisfactory. Thanks a million. –  Lex Jan 28 '13 at 13:26
    
it may be legal in Europe, but your EULA that was expressly agreed does not allow it in 2.2.6. Just pointing it out to the community because it could cause some in-house lawyers to have minor heart feailure. –  Callum Wilson Jan 28 '13 at 15:48

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.

share|improve this answer
    
could not agree more; which is why I have not asked this to the vendor yet: I might not believe whatever they tell me as to what this connection is doing. –  Lex Jan 28 '13 at 12:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.