Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Burp Collab TCP stream issue

Schulz, | Last updated: Oct 29, 2019 04:40PM UTC

Hi Burp Team, I discovered a bug in Burp's collaborator, which confused me for about two days. Don't know if this is intended but to me it's a bug. What I saw is that if Burp collab receives a single TCP stream with a single HTTP request looking like this: ####### POST / HTTP/1.1 Content-Type: application/json Content-Length: 276 Host: collab_subdomain.burpcollaborator.net Connection: keep-alive {"random json payload"} GET /whatever HTTP /1.1 Host: collab_subdomain.burpcollaborator.net User-Agent: test #### Burp collab interprets this as two different HTTP requests (meaning that it shows you 2 individual request in the collab client). Showing two individual HTTP requests made me think that I had encountered a SSRF vuln. However, while monitoring my network with Wireshark, I figured that only the first benign POST request had been sent. The second malign "GET" request actually never caused the target to send an individual request. Let me know what you think or if you need more information. Appreciate it, Pascal

Mike, PortSwigger Agent | Last updated: Oct 30, 2019 12:06PM UTC

Hi Pascal, I saw your post on twitter about this as well, so I just wanted to clarify a couple of things; - The content length that you have specified in your first request, that encompasses the JSON payload AND the second GET request that you have provided in your example. - From your Wireshark interaction, you didn't see two independent requests to collaborator? you only saw the first one from the POST request?

Burp User | Last updated: Nov 05, 2019 10:26AM UTC

Hi Mike, yes, both your statements are correct. This is exactly what I saw. Content-length ecompassed both benign JSON and malign additional GET request. Wireshark recorded only one outgoing HTTP request. I still got "two HTTP requests" coming in according to what I saw in Collaborator. Best, Pascal

Mike, PortSwigger Agent | Last updated: Nov 06, 2019 08:54AM UTC

Pascal, thank you for the clarification. Would you be able to provide an example request so I can try and replicate your issue?

Burp User | Last updated: Nov 11, 2019 08:09AM UTC

Hi Mike, unfortunately not. This happened to me while testing an internal application. The application itself would be publicly reachable, but I cannot set up an account for you. Is there anything else I could do to help resolving this issue? Best, Pascal

Liam, PortSwigger Agent | Last updated: Nov 11, 2019 03:13PM UTC

Hi Pascal Thanks for your feedback. We'll monitor this behavior and proceed accordingly. We don't think it is currently causing any issues for users. If I can be of any further assistance, please let me know.

Burp User | Last updated: Nov 14, 2019 02:01PM UTC

Okay thanks. No, no further assistance needed. I guess I will have to double-check Burp collab results with Wireshark if possible in the feature. Best, Pascal

Hannah, PortSwigger Agent | Last updated: Nov 14, 2019 03:36PM UTC

Hi Pascal Your understanding is correct. You would expect only one interaction to be listed if only one request is issued. However, due to the implementation of Collaborator, if you have inserted multiple collaborator addresses in your request that gets sent to Collaborator, then Collaborator will create an interaction for each collab-ID it has received. If your Wireshark monitoring only reported one interaction to the Collaborator, then in this instance you can assume that only one request has been sent.

Burp User | Last updated: Nov 20, 2019 09:36AM UTC

Just noticed a different example. Am I understanding Burp collab wrong? Managed to insert an additional header in a specific web app. The request turned out to look as followed. The app completely messed up my insert resulting in the line "GET: Host <collab-ID>.burpcollaborator.net", which obviously is not a correct way to issue a GET request. ##### GET / HTTP/1.1 Authorization: Basic <creds> User-Agent: <user agent> GET: Host <collab-ID>.burpcollaborator.net content-length: 22 connection: close host: <collab-ID>.burpcollaborator.net accept: */* testparam=test&test1=2 ##### However, Burp collab lists 2 HTTP interactions coming in. In the "Request to Collaborator" tab, the two requests are identical (both look like the request above between the hashmarks). In my understanding of Burp Collab, I would only expect one HTTP interaction (the one of the actual request sent as seen in Wireshark) but not two). Is this what you would expect as well or is it regular Burp Collab behavior what I see? Best, Pascal

Mike, PortSwigger Agent | Last updated: Nov 22, 2019 10:07AM UTC

Hi Pascal I have just spoken to our development team, this is known behavior of the Collaborator due to how it was implemented and how it communicates with Burp Suite. We would advise if you are working with multiple collaborator payloads per request in the future that you monitor the network traffic as you have previously done to affirm what interactions the collaborator has received.

Burp User | Last updated: Dec 03, 2019 08:37AM UTC

Hi Hannah, thank you for clarification. To be honest, this behavior states a bug to me. In my case, I was lucky enough to be able to use Wireshark in between to monitor the amount of actual HTTP requests being sent. A lot of times however, this is not the case. I would expect Burp Collab to only list one HTTP interaction in my example. Curious what you and the team thinks about this? Best, Pascal

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