The newest addition to the much beloved Burp Suite, Collaborator, allows penetration testers to observe external resource interactions in their targets, especially those triggered through blind injection. It works by hosting an instance that listens for and reports HTTP and DNS requests to the Burp application.
The most notable benefit of hosting a Collaborator instance is that when injecting content into a target web application that may cause a callback to that instance, out-of-band and so-called “super-blind” injection points (meaning those with no evidence of injection in the response, not even timing-based) can be enumerated.
Furthermore, if such a DNS request was logged without a matching HTTP request, this could serve as conclusive evidence of egress filtering or other network segregation.
For organizations, hosting a private Collaborator server instance is ideal for a multitude of reasons, the foremost being the privacy of vulnerability data. This type of private instance is easily configured in Burp’s settings by entering the instance’s fully qualified domain name.
Portswigger also offers universally unique identifier (UUID) subdomains of their Collaborator server instance to Burp users. This allows users the opportunity to leverage Collaborator functionality with no configuration involved. Logical separation and trust boundaries, meanwhile, are maintained between other users’ vulnerability data by way of Portswigger’s instance. It’s important to note that this capability is provided on a Trust UsTM basis.
You may be asking yourself, “What are the advantages of using this instead of any old virtual private server (VPS) with a dedicated IP?” Well, there are several compelling reasons to do exactly that, as explained below.
To demonstrate Burp Collaborator’s possibilities, we wrote a web application full of vulnerabilities such as unsanitized content rendering, user input written to an open TCP socket, and unsafe XML parsing. The XML parser also supports entity resolution, in allowing for the exploitation of XSS, XXE (XML External Entity) processing, and request-splitting server-side request forgery (SSRF) via CRLF injection. It’s vulnerable to a host of other exploits as well, but the three mentioned are best suited for the Burp Collaborator testing model. (Plus, three is a good number.)
Consider the example of an unsanitized username rendered in an admin interface. A user might register an account with the site, his username stored in a backend database, but he may never encounter a page where his username is rendered into the Document Object Model (DOM). An XSS payload as a username would thus likely never be triggered during the user’s regular browsing unless he was escalated to admin status and visited an admin interface which, for example, displayed a list of users by username.
At this point, the tester who injected an XSS payload will be unsure as to whether or not the payload has been — or will be — executed. However, if the Burp Intruder scan triggered the XSS, sourced a script, or made an XMLHttpRequest to the Collaborator server, the Burp Collaborator server would log the request. Unfortunately, Burp doesn’t yet automatically report this on the application side like it does with the XXE and SSRF below. See the end of this blog post for reasoning on how finding super-blind XSS could become easier in the future.
XML External Entity (XXE) Processing occurs when a vulnerable or misconfigured XML parser handles attacker-provided XML.
By injecting XML with malicious entities like those specifying SYSTEM file:// URIs or external SYSTEM http:// resources, the server can be made to include local files to be read by an attacker or to make HTTP GET requests to arbitrary internal and external hosts (a form of SSRF).
In this scenario, by injecting XML with entities which resolve externally to a Collaborator server, a tester can catch these vulnerabilities even if the XML is not rendered as the resource resolution will occur during parsing.
Following a Burp Intruder scan, external HTTP and DNS alongside the XXE can be seen in the Burp Scanner output without using custom insertion points.
Although we’ve illustrated that SSRF can be done through XXE, those HTTP requests are limited to GETs.
Wouldn’t it be nice if we could POST, too? In this next example, we will exploit an image downloader embedded in the demo web application using a request splitting attack.
By injecting encoded CRLFs and additional valid HTTP into vulnerable inputs in a web application, unexpected HTTP requests will be made by the web server itself. This is because something like this example transaction can be triggered over the TCP connection:
GET / HTTP/1.1\r\nHost: example.com:80\r\n\r\nGET / HTTP/1.1\r\nHost: some.internaldomain.net\r\n\r\n
By adding extra CRLFs and an additional GET (although any HTTP verb could work), an additional, unexpected HTTP request is made by the server, resulting in arbitrary SSRF.
If a request was made to the Collaborator server, Burp would report the external resource interaction.
While Collaborator is a great addition to the Burp Suite, there are a few other additions we would love to see in the future. Here is our wish list of features:
Burp Collaborator is certainly a step in the right direction for pentesters everywhere. We’re eagerly anticipating the further developments Portswigger has up its sleeve.
UPDATE: As of January 2016, Burp Collaborator does detect delayed interactions and blind XSS. Details can be found here.
All examples in this blog post were taken from an internally developed web application made intentionally vulnerable for demonstrative purposes. As such, no organizations served as targets for the examples.