Skip to navigation Skip to main content Skip to footer

Tool Release – Collaborator++

28 January 2020

By Corey Arthur

When testing for out-of-band vulnerabilities, Collaborator has been an invaluable tool since its initial release in 2015. By acting as a HTTP, DNS and SMTP server, Collaborator allows researchers to identify complex out-of-band interactions between target applications and external services aiding in the discovery of vulnerabilities such as server-side request forgery (SSRF), XML external entity injection (XXE) and blind cross-site scripting (XSS).

This project aims to extend upon the existing Collaborator functionality provided by Burp Suite, providing a number of quality of life features, and the implementation of an authentication mechanism to secure private collaborator deployments, while still being compatible with all existing extensions which generate and poll Collaborator contexts.

Screenshot of Collaborator++ in action

Context Persistence

While Collaborator contexts created during automated scans are saved within the Burp project, contexts created via other means such as user extensions or the Collaborator client do not persist outside the current session, resulting in interactions being lost with no method of retrieval once the session is closed. One of the things that makes Burp Suite great is the vast range of user-created extensions. While working with Collaborator, extensions such as Taborator, Collaborator Everywhere and Handy Collaborator are extremely useful. However, the lack of a central solution to manage contexts leaves interactions scattered throughout various places within Burp Suite like the issues tab, Collaborator client windows and user extension tabs.

Collaborator++ was built to operate in a way which is transparent to the Collaborator client and extensions using the ICollaboratorContext interface within Burp, allowing their full functionality to continue working as designed in addition to all functionality provided by Collaborator++.

Collaborator Authentication

To prevent potentially sensitive data from being sent to the public Burp Collaborator instance, users are able to deploy private Collaborator servers locally. However, there currently exists no mechanism for preventing unauthorised use besides restricting polling to a specific interface. This requires users of the private server to be on the same network to retrieve results, either physically or by use of VPN. However, this is not always suitable for a number of reasons, resulting in server owners leaving their deployments unsecured.

By searching Shodan.io for response headers sent by Burp Collaborator, NCC Group discovered the existence of 187 private Collaborator servers. 122 of which were externally pollable, many of which were configured with SSL certificates with common name attributes suggesting ownership by leading security companies and private researchers, highlighting the importance of an alternative security mechanism. This tool aims to secure Collaborator servers by providing an authenticated proxy for polling for Collaborator interactions, additionally and optionally enabling server owners to limit unauthenticated polling to the local network.

Authentication Mechanism

Collaborator Authenticator consists of two components: The authentication server, responsible for authenticating incoming polling requests before passing them to the Collaborator server, and the extension used to manage and forward requests.

When Burp requests the list of interactions received by the Collaborator server, the extension encrypts the polling requests with the AES256-CBC encryption scheme, using PBKDF2 to generate the encryption key from a shared secret. Provided the secret is correct, the authentication server is able to decrypt the request and forward it to the Collaborator server to retrieve the latest interactions. The response is then encrypted with the shared-secret before being sent back to the Burp client.

By using the shared-secret to encrypt the transmission between the Burp client and the authentication server, the shared-secret does not need to be transmitted along with the request, allowing confidentiality to be maintained even in cases where HTTP communication must be used between the client and Collaborator server.

Future Plans

The ability to monitor and intercept Collaborator events opens up a large number of possibilities for additional tools and utilities. This could include emailing interactions to be stored for later, integration with slack for group collaboration, or simple processing of the results using custom scripts.

Download

The latest version of Collaborator++ can be downloaded from: GitHub
Pull requests are encouraged!