Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Burp Collaborator OOB - HTTP

Philip | Last updated: Jul 27, 2017 11:04AM UTC

Correct me if I'm wrong, but using the following payload "@<SNIPPED>.burpcollaborator.net/" to detect Out-of-band resource load (HTTP) will generate huge false positives, as I was able to trigger an issue for every website GET http://portswigger.net@<SNIPPED>.burpcollaborator.net/. Using the @ symbol seems to redirect all application. Not much information on why @ symbol redirects. I'm just trying to limit false positives in my results.

PortSwigger Agent | Last updated: Aug 01, 2017 02:28PM UTC

Hi, Have you seen Burp Scanner reporting false positives due to the use of this payload? Burp's scanner will send a request like "GET @xxx.burpcollaborator.net HTTP/1.1" to whatever website you target, but this won't cause an interaction unless the target website decides to forward it to burpcollaborator.net. You can verify this by using the following shell command: echo -e 'GET @xxx.burpcollaborator.net HTTP/1.1\r\nHost: example.com\r\n' | ncat example.com 80 Please note that if you try to load a URL like http://portswigger.net@xxx.burpcollaborator.net/ in your web browser this will cause an interaction, but that's expected behaviour and does not indicate a vulnerability. If you're seeing Burp Scanner report this vulnerability on every target, it's possible that you have an upstream proxy which is being incidentally exploited by Burp. This might not necessarily be within your own companies infrastructure; some ISPs including BT route traffic through a pool of proxies. For further information on this technique, you may wish to read the whitepaper at http://blog.portswigger.net/2017/07/cracking-lens-targeting-https-hidden.html Cheers, James

PortSwigger Agent | Last updated: Aug 02, 2017 10:23AM UTC

We only added this payload in the last release, so that'll explain why you've never seen it before. Since this behaviour is visible regardless of which host you target, it's highly likely that it's being caused by your upstream proxy. In this instance, the scanner issue isn't really a false positive (it has successfully identified that an upstream service will proxy traffic to arbitrary destinations), but it isn't a vulnerability either, as proxies proxying is expected behaviour. For now, I would recommend avoiding using an upstream proxy if possible, and otherwise simply disregarding this issue. In a future release we may simply skip sending the @payload if the user has an upstream proxy enabled. Cheers, James

Burp User | Last updated: Aug 03, 2017 11:20AM UTC

I've never seen this interaction using the @ symbol before. So OOB resource load (HTTP) flagged in the Scanner results and I sent it to the repeater and the response was from Burp Collaborator https://burpcollaborator.net/ with random value in the body. My curiosity with the @ symbol, I then substituted a bunch of different domains(Changed Target,HOST etc..) and all responses was from burpcollaborator.net < This is where I'm getting confused, if it gets a response from burpcollaborator.net it's a indication of a vulnerability, so because I changed HOST/URL/Target to any domain and it got always got a response from burpcollaborator I marked it a false positive. I must read that paper to get a better understanding as I see it makes reference to what I'm asking. Thanks Note: I do use a upstream proxy Burp Repeater: Request GET http://any.com@xxx.burpcollaborator.net/ HTTP/1.1 Host: any.com Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close Response HTTP/1.1 200 OK Server: Burp Collaborator https://burpcollaborator.net/ <html><body>xxx</body></html>

Burp User | Last updated: Aug 03, 2017 01:13PM UTC

Thanks James - having the upstream proxy disabled, fixes it, however I need the upstream proxy to contact your public collaborator server, I will have to disregard the issue for now. I was thinking of deploying a private collaborator server in the future anyway, not sure if that would work better as I still need a upstream proxy to pull down CDN resources.

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