How I gained persistent access to Burp’s Collaborator Sessions

In this write up, I set out an easy way to gain persistent access to Burp Suite’s Collaborator sessions. Previously these were thought to be volatile, and to disappear once the current instance of the Collaborator client is closed.

What is Burp Suite Collaborator?

The Collaborator client in Burp allows you to generate Collaborator links and monitor DNS, HTTP, and SMTP interactions made by external services. It’s an excellent feature that greatly simplifies testing for vulnerabilities like Server-Side Request Forgery (SSRF), Blind-XSS, and other issues which may cause external service interactions.

Collaborator in Action

How did I come across this?

I was trying to re-create the research pipeline in the whitepaper ‘Cracking the lens’ by James Kettle, so that I could integrate it into my enumeration/scanning tool ‘Ardent’ which I’ll release on Github soon.

Immediately I was faced with a choice of either rolling my own interaction server, or living with the limitations imposed by Collaborator namely:

  • Manually generated links are only usable if the Collaborator client is open, and…
  • They don’t survive exiting Burp

But my goal was to scan a large range of targets over an extended period, so I decided to see if I could piggyback off Collaborator in a less obvious way, before taking the plunge and spending time implementing my own solution.

Initially, I found that you can run your own Collaborator server, (which I highly recommend BTW if you want to avoid pissing off PortSwigger). However, even with your own Collaborator server, there is no obvious way to interact with it outside Burp. Which leads me to the following…

What is the work around?

I discovered that in order to maintain a simple, stateful Collaborator implementation, Collaborator subdomains are generated using a key derivation function based on a secret key. This secret key is generated by the Collaborator client as soon as you open it and it’s destroyed as soon as you close it.

When polling for interactions, Collaborator’s server then regenerates the list of Collaborator domains from the secret key, and returns the interactions it has recorded against those subdomains. This opens the possibility of capturing a Collaborator secret key and using it to poll for interactions made against links generated from that secret key.

Methodology

Step 1: Set Collaborator up to poll over HTTP

Before we can capture any polling requests, we have to set Collaborator up to poll over HTTP, and we do that over in: Project Options->misc

Collaborator polling over HTTP

Step 2: Intercept a polling request

Now, as this is a HTTP based protocol, you could just use two instances of Burp to intercept a polling request between Burp and the Collaborator server. However, it’s just easier to use Wireshark.

Once Collaborator is set up and Wireshark is listening on the appropriate interface, go to Burp->Collaborator Client and press ‘Poll now’. Now when you check Wireshark, you should see a HTTP request to http://polling.burpcollaborator.net/burpresults?biid=SECRET_KEY_HERE. Take note of the secret key value sent as the value of the biid parameter.

With your secret key in hand, it’s time to create some links to use with it in the future. Generate as many links you think you may need and save them somewhere, along with the secret key.

Retrieving interactions from Collaborator

However, it is worthwhile note that the Collaborator server ignores any data you prepend to the generated link, thus allowing you to store data by inserting it as a subdomain of the Collaborator link. This is similar to how DNS tunnelling functions, in fact, you can even perform DNS tunnelling using collaborate if you like. https://github.com/NetSPI/BurpCollaboratorDNSTunnel

That’s it - you can now retrieve interactions with any of these links simply by sending a HTTP GET request to http://polling.burpcollaborator.net/burpresults?biid=SECRET_KEY_HERE. And, because the Collaborator server generates the links using the secret key, they will never expire. Be careful though, the Collaborator server is ephemeral, so may lose data if it’s left there for prolonged periods. Therefore, I recommend you poll more regularly if you pull your data in real time.

Conclusion

Hopefully Burp will add support for persistent access to the collaborator client in the future, especially for paying users. In the meantime, I hope this workaround helps Security Researchers who struggle with the current limitations of the Collaborator Client. There are of course other ways to achieve similar results, but not with the same level of convenience. For example;

If you’re not familiar with James Kettle’s archive I recommend you start with his fascinating talk ‘Cracking the lens’ before just diving right into messing about with it yourself. It’s truly bizarre the kinds of interactions you’ll get from services by placing links in weird places. You may find yourself scratching your head trying to figure out why you’ve so many pingbacks for China, even though you never sprayed there ;).

Let me know what interesting stuff you come across, and if you have any questions about any of this guide, drop me an email at calum.boal@onsecurity.co.uk or get in touch with me on LinkedIn

Finally, I’ll be releasing ‘Ardent’ on Github soon, so keep an eye out.