This post details the steps required to achieve persistent access to Burp Collaborator sessions which are usually volatile, and lost when current instance of Burpsuite collaborator client is closed.
In case you are currently unaware of the collaborator client in Burpsuite, it allows you to generate collaborator links and monitor DNS, HTTP, and SMTP interactions made by external services. This is an excellent feature which greatly simplifies testing for vulnerabilities such as Server-Side Request Forgery (SSRF), Blind-XSS, and various other issues which may cause external service interactions.
Whilst attempting to re-create the research pipeline described by James Kettle, in the whitepaper cracking the lens, and integrate it into my enumeration/scanning tool Ardent (which I will release here another time). I was faced with a choice of rolling my own interaction server, or living with the limitations imposed by collaborator, in that, manually generated links are only usable as long as the collaborator client is open, and do not survive exiting Burp. As the latter was unfeasible due to my goals of scanning a large range of targets over an extended period of time, I decided to see if I could piggyback off Burp collaborator in a less obvious way before taking the plunge and implementing my own solution.
Initially, I found that you can run your own collaborator server, which I recommend if you follow this guide as to not piss off PortSwigger. However, even when using your own Collaborator server, there is not an obvious way to interact with it outside BurpSuite. Which leads me to the following…
Through some research I discovered that in order to maintain a simple stateful collaborator implementation, they generate the collaborator subdomains using a key derivation function based on a secret key. This secret key is generated by the Burp collaborator client when you open it, and subsequently destroyed when you close it.
When polling for interactions, Burp’s collaborator server regenerates the list of collaborator domains from the secret key, and returns the interactions it has recorded against that subdomain. Thus, it is possible to capture a Collaborator secret, and use it to poll for interactions made against links generated from that secret key.
To begin with, we must find a way to intercept a polling request from BurpSuite, to the Burp Collaborator server. As this is a HTTP based protocol, you can use two instances of BurpSuite to achieve this. However, it’s probably easier to use wireshark.
However, before we are able to capture the polling request sent by BurpSuite to collaborator, we must first go to
Project Options->misc, and set Collaborator to poll over HTTP.
Once this has been achieved, and wireshark is listening on the appropriate interface, go to
Burp->Collaborator Client and press
Poll now. In wireshark, you should now 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
Now, it’s time to get some links to use with this secret in future. To do so, generate however many links you think you may need, and save them somewhere, along with the secret key.
It is now possible to retrieve interactions with any one of the generated collaborator links by sending a HTTP GET request to
http://polling.burpcollaborator.net/burpresults?biid=SECRET_KEY_HERE. As the collaborator server generates the links using the secret key, they will never expire. However, the Burp collaborator server is ephemeral and thus may lose data if it is left there for prolonged periods. As such, it is recommended you poll regularly to collect your data.
I hope this helps the researchers out there in some way, and if you haven’t already, I highly recommend watching James Kettle’s talk “cracking the lens” and messing about with it yourself, it’s bizarre some of the interactions you can get from services by placing links in weird places. Figuring out why you have so many pingbacks for China when you never sprayed there will keep you busy for a while ;).