Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Burp Collab TCP stream issue

Pascal Schulz 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 Eaton Oct 30, 2019 12:14PM UTC Support Center agent

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?


Pascal Schulz 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 Eaton Nov 06, 2019 08:55AM UTC Support Center agent

Pascal, thank you for the clarification.

Would you be able to provide an example request so I can try and replicate your issue?


Pascal Schulz 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 Tai-Hogan Nov 12, 2019 01:55PM UTC Support Center agent

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.


Pascal Schulz 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

Pascal Schulz 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


Hannah Law Nov 22, 2019 10:07AM UTC Support Center agent

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.


Pascal Schulz 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

Mike Eaton Dec 05, 2019 12:24PM UTC Support Center agent

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.


Post Your public answer

Your name
Your email address
Answer