PortSwigger / http-request-smuggler

https://portswigger.net/blog/http-desync-attacks
Other
952 stars 101 forks source link

Burp not logging packets while performing HTTP request smuggle probe. #36

Closed infosecconsultant closed 4 years ago

infosecconsultant commented 4 years ago

I’ve been trying to exploit and track down an apparent HTTP smuggling issue in a site I’m testing which is causing me lots of grief.

I start by spinning up a collaborator client and copying a payload.

I then go to the target tab, select my target domain and enter the collaborator domain in the poc-collab domain field and select all ‘poc’ options.

I then click ok which launches the scan. Using the Logger++ extension I can watch the requests and responses being sent. I also launch Wireshark and capture my Ethernet interface at the same time. The traffic generated by Burp and displayed in both logger++ (and project options -> misc -> logging output) looks something like this: image

All requests are only slight differences between the Content Length and Transfer Encoding headers. No actual payload information (for example, containing collaborator payloads or the 'smuggled' requests) is presented. Only a handful of characters.

This is in stark contrast to what Wireshark sees as a raw packet on the wire: image (fun fact, Wireshark also struggles to handle malformed CL/TE information)

But once the output is cleaned up from Wireshark, the REAL request is shown as below: image

This packet isn’t logged anywhere that I can find. And, more concerning is that the finding isn’t noted anywhere, even though collaborator pingbacks are regularly occurring. image

Currently there is no way for me to easily reproduce the results generating the collaborator payloads as I can’t identify the original requests that generated them without manually digging through all the Wireshark packets and testing different smuggler payloads.

I’m not sure why this appears to be an issue as I have issues raised in the target tab for other hosts with similar requests as shown here: image

But none raised for the specific host I’m testing currently.

Any help you could provide would be greatly appreciated. Thanks!

infosecconsultant commented 4 years ago

Oh sorry, just to be clear. I've also raised this as a support ticket with Burp support as I'm unsure if the issue lies with BSP or with the extension itself. Cheers,

albinowax commented 4 years ago

Burp Suite doesn't log traffic sent by Turbo Intruder as it uses its own network stack. If you want to see the traffic, uncheck the 'use turbo for autopoc' option in HTTP Request Smuggler

Regarding it not reporting an issue, it'll be dependent on the response content.

infosecconsultant commented 4 years ago

Hey albinowax,

Thanks for the clarification. That makes total sense.

Is there a way then to invoke the turbo intruder console when launching the smuggle probes to see the full requests and responses (the same as if you were to launch it manually)?

Cheers,

albinowax commented 4 years ago

Sorry, I think if untoggling 'use turbo for autopoc' somehow stops the attack from working (which would be surprising), you'll need to launch them manually.

infosecconsultant commented 4 years ago

Apologies for stopping in again @albinowax There's one last thing here I don't understand. If Burp Suite doesn't log traffic generated by Turbo Intruder that's fine, but why am I seeing 'half' of the request come through in Turbo Intruder instead of no requests at all?

Thanks,

albinowax commented 4 years ago

It probably uses a mix of Turbo Intruder's network stack and Burp's.