SSH Socks Proxying and Burp

There's no question about it, PortSwigger's Burp Suite is the de-facto tool for testing web applications for security vulnerabilities. It's far from a "fire-and-f0rget" tool, which means that it take a lot of getting used to in order to make effective use of everything that the tool has to offer. Due to it's rich feature set, and all of the additional capabilities that are available via the Extender, tool and the BApp store, Burp can quickly become overwhelming for an inexperienced tester. Today, I'm only going to cover one feature that you should consider when using Burp for web application testing, SOCKS proxying.

If you're unfamiliar, SOCKS is a protocol that sends traffic between two endpoints via a proxy. This means that a connection is established between two nodes or hosts and traffic flows into the tunnel established between those hosts. SOCKS connections allow for the redirection of specific traffic through the established proxy in order to have more control over how the traffic is being handled. Secure Shell (SSH) has the ability to set up a SOCKS proxy when connecting to a remote server with the added benefit that all of the traffic being sent over the connection is encrypted via the SSH protocol. With a SOCKS proxy established over SSH, traffic can then be tunneled through the connection so that it exits from the remote end of the proxy connection. This can be useful in several testing scenarios.

Let's say that a client has a web application that they want tested, but the web app is being developed internally and has no external connection interface. One available option is for the client to forward a port to the application that the consulant can connect to. If not configured correctly, this could result in unauthorized users having access to the potentially vulnerable application if proper restrictions were not established when creating that forward. Another option is for the consultant to travel to the client's site and perform testing locally, using an internal connection to the target application. This too increases testing time and costs due to the travel costs associated with on-site testing. The other option is that the client can allow the consultant to SSH into a server that has internal rules configured to reach the target web application, and the consultant can tunnel all traffic over a SSH SOCKS connection and perform testing remotely. This reduces testing costs since the consultant does not have to travel and be on site, and ensures that the connection to the target application is secure while testing occurs.

Burp Suite has options available where a consultant can tunnel all testing traffic through an established SOCKS proxy. Assuming that the consultant has a proxy connection configured locally to listen on port 9090, this can be configured as follows.

0) Establish SOCKS proxy using SSH

$ ssh <user>@<enpoint_IP> -D 9090

1) From Burp Suite, click on the User options tab.

2) Scroll to the SOCKS Proxy settings

3) Enter the proxy information. In this scenario, the connection is listening on host 127.0.0.1 and port 9090.

4) Click the "Use SOCKS proxy" checkbox

5) If testing a remote internal application, and testing is being done via hostname, check the "Do DNS lookups over SOCKS proxy". This will override the default host lookup process and direct DNS requests for the hostname through the proxy. As a result, hostname requests will be performed on the internal network instead of over the internet or on using whatever name resolver the consultant has configured.

That's it! Now all traffic that is configured to flow through Burp will now also flow through the SSH SOCKS proxy. This doesn't affect any other traffic, only what's configured to go through Burp.

Happy hacking!