Mar 14, 2024 9:53:37 AM | application penetration testing Slam The Door Shut On Burp Suite’s Perfunctory Proxy

Burp Suite has some really cool features that make it useful as an HTTP Swiss Army Knife. It’s great for debugging and acting as a middle translation layer to duct tape software together. Features like TLS Pass Through and Request Handling (Host Redirection) provide precision to bypass and redirect traffic while working with Burp. 

But there’s just one problem: Not all Settings take immediate effect.

Perfunctory Proxy

That is, if you already opened the browser and initiated some connection to the host you’re working with before you configure settings in Burp, like the majority of users will do during the Discovery phase of testing. The browser process (chrome.exe) keeps idle connections open to the target webserver to improve speed. When some networking settings are changed, Burp does not force these pre-existing connections to re-negotiate. For new settings to take effect, the browser has to timeout these connections so that new ones will be initiated, which will then follow the current Burp configuration. They might not time out for a long long time. You can use a process monitoring tool like TCPView or Process Hacker to see these open connections:

To force the browser to obey the current Burp configuration options, you can either restart the browser 👎or work around the issue by forcibly shutting the connections.

The Workaround

If you’re using a version of Chrome / Chromium, like Burp’s built-in browser, you can access the built-in Sockets settings page at chrome://net-internals/#sockets. You’ll need to copy and paste it into your browser. There, you can click the “Close idle sockets” button to force your browser to establish a new connection and follow the modified Burp settings. This is not ideal, but may be preferable to having to close and open a browser completely, re-establish an application session, perform Multi-Factor Authentication, etc.

But You Don’t Have to Take My Word For It

Want to experience this odd edge case yourself? Here are two procedures you can follow to reproduce it.

(Method 1) Perform the following steps to experience the configuration delay using the TLS Pass Through setting:

1. Open Burp, validate version is v2023.12.1.3 (newest). Start a new temporary project. In Proxy Http History Filter, click Show All and set Proxy HTTP History filter to “favicon.ico”. (Images enabled)

2. Open Built-in Chromium. Open Dev Tools > Network and check Disable Cache. Keep Dev Tools open. Navigate to https://www.google.com/favicon.ico.
3. Right click the request to /favicon.ico in Burp Proxy History, and Copy URL.
4. Open Settings > Proxy > TLS Pass Through. Use the “Paste URL” button to add it to the list (it is automatically enabled). Close Settings.

5. Reload / refresh the Chromium browser. Observe that the new GET favicon.ico traffic still shows up in Proxy HTTP History when it should be passed through, and not visible in Burp.
6. Open chrome://net-internals/#sockets in a second tab and click “Close idle sockets”
7. Refresh the favicon.ico tab and observe that the traffic is now passed through successfully (i.e., requests are successful but do not reach the Proxy History). 

(Method 2)  Perform the following steps to experience the configuration delay using the Proxy Listeners setting:

1. Open Burp, validate version is v2023.12.1.3 (newest). Start a new temporary project. In Proxy Http History Filter, click Show All and set Proxy HTTP History filter to “favicon.ico” (Images enabled)

2. Open Built-in Chromium. Open Dev Tools > Network and check Disable Cache. Keep Dev Tools open. Navigate to https://www.google.com/favicon.ico.
3. In Burp Proxy > Proxy Settings > Proxy Listeners, disable the localhost proxy listener.

4. Refresh the browser. Even though the Proxy Listener is not “running”, the socket is still held open by the browser, and Burp does not terminate established connections when the Listener is disabled. The following requests were successfully submitted from the built-in browser, through Burp (logged in the Proxy History), while there were “no Proxy Listeners running” and Proxy Interception was turned on. None of the requests were actually Intercepted by Burp:

5. Open chrome://net-internals/#sockets in a second tab and click “Close idle sockets”. Refresh the /favicon.ico tab, and observe that it no longer can communicate, giving a “No Internet” error.

Beware Configuration Delay

Hopefully, future versions of Burp Suite can tamp down on these idle connections, terminating them when the user modifies Networking settings so that Burp’s active configuration is enforced immediately. Proxy Listener features, like host redirection, may not behave as immediately as you expect when using a browser or other client software that optimizes web performance by maintaining open idle connections. 
In the meantime, you can use the chrome://net-internals/#sockets page to update your browser during interactive testing. Consider alternative options if you need an absolute network connectivity shutoff option, like testing over an upstream SSH SOCKS Proxy which you may readily terminate. Want easier access to Burp’s SOCKS Settings? Try our SOCKS Settings Burp Extension.