Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Out of Band vulnerabilities and Collaborator

steven | Last updated: Apr 13, 2018 09:57PM UTC

Good Afternoon, I am curious about how vulnerabilities for out-of-band issues are being presented in Burp. When looking at a finding for this, my confusion comes from the difference between the 'base request' and the Issue 'request'. Sometimes there are extreme differences. For example, the base request might be for a mutipart/form-data request like this: POST /user/988/edit HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Firefox/52.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://example.com/user/988/edit Cookie: token=tokenvalue Connection: close Upgrade-Insecure-Requests: 1 Content-Type: multipart/form-data; boundary=---------------------------13847271448288266691510891441 Content-Length: 1509 -----------------------------13847271448288266691510891441 Content-Disposition: form-data; name="form_build_id" form-sP5IGckg1YHN6SIC_Kb1cyimp1oNT49n6Lu4V1btR7s -----------------------------13847271448288266691510891441-- But when I look at the Issue request all it says is: GET / HTTP/1.1 Host: qxrv4nj52n8poashzn1prat7nytwykrjf92zqo.burp.example.com Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close I understand what an out-of-band vulnerability is, and I can follow the flow of traffic with the unique subdomains in the requests, and character strings in the responses. But I'm unsure of how Burp gets from that 'base request' to the Issue 'request'. Every time I have seen this vulnerability pop up, it's always this situation. I would have expected to see something more like: POST /user/988/edit HTTP/1.1 Host: qxrv4nj52n8poashzn1prat7nytwykrjf92zqo.burp.example.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Firefox/52.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://example.com/user/988/edit Cookie: token=tokenvalue Connection: close Upgrade-Insecure-Requests: 1 Content-Type: multipart/form-data; boundary=---------------------------13847271448288266691510891441 Content-Length: 1509 -----------------------------13847271448288266691510891441 Content-Disposition: form-data; name="form_build_id" form-sP5IGckg1YHN6SIC_Kb1cyimp1oNT49n6Lu4V1btR7s -----------------------------13847271448288266691510891441-- Thanks for any clarification you can give me. Steven

PortSwigger Agent | Last updated: Apr 16, 2018 09:34AM UTC

Hi Steven, Thanks for your message. When the Scanner generates a request that includes a Collaborator payload, it generates a unique interaction ID for that request. It stores a copy of the request and interaction ID, sends the request to the target server, and periodically polls the collaborator for interactions. If an interaction is detected, the Collaborator server returns both the interaction ID, and the request the Collaborator received. It then consults it's list of saved requests and interaction IDs to find the original request that included this payload. It reports the original request and response, along with the Collaborator interaction. I hope this helps you to understand the process better. If you have any more questions, just get in touch.

PortSwigger Agent | Last updated: Apr 16, 2018 09:41AM UTC

Hi Steven, Can you provide an example of a reported issue like this? The example base request you've sent does not include a Collaborator payload. In general, what Collaborator detects is the target application making an independent HTTP request. For example, if we include an external DTD in an XML document, some servers will attempt to load the DTD. By providing a DTD URL on the Collaborator server, we can track when the server makes this request. And use interaction IDs to correlate this with the original HTTP request.

Burp User | Last updated: Apr 16, 2018 02:09PM UTC

Thank you for the explanation, but it doesn't really clear up my confusion. In the example I provided, how is Burp going from an initial POST request, one with a content type of multipart/form-data (lots of headers, and data in the body of the request), to the most basic and generic of GET requests? I do not understand how those requests are related. -Steven

Burp User | Last updated: Apr 16, 2018 03:13PM UTC

Yes, I can provide an example of this issue. I don't see a way to post screen shots or anything. Is there an email I can send them to? -Steven

PortSwigger Agent | Last updated: Apr 17, 2018 08:36AM UTC

Hi Steven, Sure, you can send to support@portswigger.net

Liam, PortSwigger Agent | Last updated: Jul 16, 2018 08:11AM UTC

Oscar, could you send screenshots demonstrating this behaviour to support@portswigger.net. Thanks.

Burp User | Last updated: Jul 15, 2019 03:59AM UTC

Hi Steven, I have the same question - why the Issue Request is completely different from the targeted one? For example, the original request is a POST request with several parameters. However, the Issue Request is just like the below one which is a GET request. GET / HTTP/1.1 Host: nkbaerf99k2pnj191ead92fer5x0ltkha40sp.burpcollaborator.net Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close Moreover, when I send this Issue Request to repeater and resend it out, I find that the URL and the value of header 'Host' are also changed to nkbaerf99k2pnj191ead92fer5x0ltkha40sp.burpcollaborator.net. If the plugin targets to test if server validation is in place for the Host value in header, it should not change the target URL. So, we suspect that it is a bug/false positive. Please advise. Thanks!

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.