Proxying Unaware Thick Clients

Here we force obtuse thick clients to send traffic our way

Eventually, you may end up in a situation where you can’t use SSH alone to proxy your traffic to Burp Suite from some thick client. Perhaps this is due to unaware clients or due to traffic restrictions.

In a recent engagement, I had to proxy traffic from a thick client that ignored all system and environment variable proxy settings to a server within the same VPN. Here is a rundown of some of your options when forcing restrictive clients to proxy their traffic.

TLDR: Here’s a TAR with a proxy setup for thick clients

Hooking Network Functions

If the client is not doing anything complicated, (complicated things include: some jvm-based applications, statically linked binaries) then you may be able to use tsocks or proxychains to force the client to proxy traffic. Try this solution first, and if it does not work for your application, read below for a client agnostic solution.

Proxychains:

Create a socks proxy connection over ssh with the following command: ssh -D 8080 -q -C -N user@yourproxy.com
- The extra flags tell this command to run in the background without an extra terminal.
Run the following command: sudo apt install proxychains
Open the configuration file located at: /etc/proxychains.conf

Scroll to the very bottom and delete any proxies listed under [ProxyList]. Then enter the following line:

[ProxyList]
socks4 127.0.0.1 8080

After you’ve completed configuration, run the client by prepending proxychains:

proxychains thick-client arg1 arg2

Firewall Based Traffic Redirection

In my scenario, the client was using network operations in the JVM which proxychains and tsocks did not support. To solve this problem, I directed traffic to my intercepting proxy using redsocks and iptables rules at the firewall level. To prevent duplication of effort, here is a ready-to-use solution for proxying traffic between headless boxes in a VPN in Ubuntu / Debian systems. If you had any previous iptables configuration settings, back them up in case something goes horribly wrong!

Here is a TAR archive with scripts to enable and disable the direction of traffic at the firewall level. To install and configure the scripts, follow these steps:

Run the following command: sudo apt install redsocks
Open client/redsocks.conf
Replace the lines port=3128 with the port you would like your intercepting proxy to listen for incoming traffic on. Outgoing traffic from the intercepting proxy will be passed on to the port specified by the client.
Replace ip=x with the address of your machine which is running the intercepting proxy.
Place client/redsocks.conf in /etc/redsocks.conf
Open client/redsocks_iptable.sh and ensure that there are 2 lines with --dport for the port your client communicates over.
There should be one line for the REDSOCKS table, and one line for the PREROUTING table.
Run the following command: sudo ./redsocks_iptable.sh

Troubleshooting

At this point, you should be sending traffic to the box running the intercepting proxy. If this happens to be running Burp Suite and you are sending traffic to 8080 or have changed your Burp Suite configuration, congratulations, you are done! If you’d like to verify your setup or need help troubleshooting, take a look at these steps:

If you are proxying traffic within a VPC/VPN, you may need to comment out some of the ignored / reserved addresses so that traffic moving internal to the VPC is also redirected.

You can confirm that the rules are set up as desired using the following command: sudo iptables -t nat --line-numbers -L

Rules can be removed with the following command, where 1 is the number of the command and PREROUTING is the name of the table containing the rule: sudo iptables -D PREROUTING 1

Run the following command: sudo systemctl restart redsocks

Headless Proxies

If you’re working in a command-line-only environment, then you may not be able to use Burp Suite or whichever intercepting proxy you are most comfortable with. Read on for instructions about setting up MITMProxy for command-line only environments.

Transfer the proxy/mitmproxy-4.0.4-linux.tar.gz file to the box you wish to run the intercepting proxy from.
Run the following command: tar xvzf mitmproxy-4.0.4-linux.tar.gz
The resulting folder should contain three binaries: mitmproxy, mitmdump and mitmweb.
Move these binaries to some location in your path or run them from the current directory.
To listen on the port you specified in your /etc/redsocks.conf file, use mitmproxy --listen-port port

Ideally, at this point, you are capturing traffic from the ports of your choosing through mitmdump or mitmproxy. When you are ready to remove the custom iptables rules, run the reset_iptables.sh file as sudo. Note that this will clear all existing rules and set the firewall to allow all connections. You can then restore any rules you backed up at the start of this process.

Afterword

In my case, the application ended up having critical TLS misconfiguration issues which allowed attackers to impersonate both the client and the server in a sensitive environment. Take this knowledge and get that extra bit of coverage on your next engagement!

For more content like this, please visit my personal blog at https://maxfieldchen.com

If you didn’t get your fill or just want further treatment of this subject, take a look at these curated resources which I used to put together this guide.