Burp, Collaborate, and Listen: A Pentester Reviews the Latest Burp Suite Addition

Portswigger is back with a brand new invention.

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.

Better yet, Collaborator server instances act as authoritative DNS servers with a resolver pointing to themselves. This means if an injection payload triggers an HTTP request that is somehow blocked — e.g., by egress filtering or other firewall rules — the injection will still be reported, since the DNS request will likely evade such filtering. For example, when a JavaScript XMLHttpRequest (XHR) is made to example.com, the browser must first resolve the domain to an IP with a DNS request, then make the HTTP request. This is especially useful when a payload is triggered on an internal domain that the pentester can’t access, because DNS egress is rarely filtered.

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.

Should I Use the Default Burp Collaborator Server?

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 Us^TM basis.

I Already Have a Virtual Private Server, Though

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.

• First, the integration with Burp is extremely convenient, as it makes your external interaction vulnerability data only a click away. This is significantly easier than having to check the HTTP logs of a VPS you might use for similar purposes.
• Second, Burp Collaborator acts as a dedicated service — meaning that your pentest data won’t comingle with other data on your VPS.
• Finally, Burp Collaborator’s use of UUIDs in the injected subdomain allow for collateral requests to be uniquely identified, whereas if you simply inject something like `curl my-vps.com,` the request you’re looking for may be buried in other HTTP traffic. We were recently on an engagement where a colleague injected a similar payload and checked his VPS for traffic. As it turned out, someone curl’d the VPS at the same time, leading to the emotional rollercoaster of false-positivity every penetration tester strives to avoid.

Okay, I’m Interested. Show Me The Magic!

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.)

XSS

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.

XXE

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.

As shown in the above image, Burp Scanner not only caught the XXE, it also reported the external interaction, a nifty advantage.

SSRF

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.

With the custom injection point captured in the above image, Burp successfully caught the SSRF external interaction.

Final Thoughts

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:

• Support for manually inserting Collaborator payloads would be a major win. This would allow for targeted injections rather than depending on Burp Intruder to catch everything in the automated scan.
• It would also be helpful to have Collaborator server instances track injected payloads (perhaps with customizable timeouts) even if they don’t immediately result in an HTTP or DNS request. This would allow pentesters to catch out-of-band payload triggers such as stored XSS that require further user interaction on the backend of the target to pop. An example of this would be an admin rendering HTTP logs in a custom logging web application solution that is internally facing the organization.

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. 

For More Information …

https://portswigger.net/burp/help/collaborator.html

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.