Using the proxy option with Burp proxy causes the exploit to fail
joelland opened this issue · 4 comments
See the title. When the exploit is passed through Burp proxy using the --proxy argument, the proxy messes up the headers (drops Transfer-Encoding and adds back Content-Length) which causes the request smuggling to fail with no user being created. I have only tested this using Burp proxy, so I don't know if other proxies might behave. Running the exploit without --proxy is confirmed to work on the same target.
Can you post screenshots of detailed steps? I don’t know if it matches my guess.
With Burp proxy running, issue the following command:
python3 CVE-2023-46747-RCE.py -u https://192.168.92.157:8443 --proxy http://192.168.92.1:8080
The captured request looks like:
As you can see, the Transfer-Type: chunked, chunked header is gone, Content-Length: 516 is added, and the 204 and 0 are removed from the body of the request. Basically, it seems like Burp interprets the chunked request coming fully in a single packet and "fixes" it before sending it to the vulnerable BIG-IP host. The result is that no user is created and the exploit fails when the credentials don't succeed at obtaining a token.
Since this is actually a Burp proxy issue and not caused by your exploit, I've also filed a report with PortSwigger here: https://forum.portswigger.net/thread/burp-proxy-breaks-public-exploits-for-cve-2023-46747-dfa4dd9c?CategoryId=bug-reports
I don't really think there's much more you can do about it other than maybe warn users that Burp doesn't play nice. Since Burp is a popular choice of proxy among security folks, it may be warranted.
Code has been updated:
