One of our recent assessments required us to pentest a thick client application, for which we needed to inspect the HTTP communication between the thick client and the server. One of the ways could’ve been to intercept and modify traffic on the go. But traditional proxies wouldn’t be of much use as the application was proxy unaware. This blog covers how we went about solving the issues that come with traditional proxies when pentesting thick client applications.
What are Thick Clients?
A “Thick Client” (also called “Fat Client”) is an application that has most of its resources installed locally. These applications are capable of working offline since most of the computation is handled locally, and maintaining a constant connection with the server is not required.
Why Traditional Proxies Don’t Work?
Traditional proxies, such as BurpSuite, or OWASP Zap are built around HTTP. They are well capable of dealing with HTTP/S traffic, however, when it comes to thick clients, we often observe the following:
- Use of raw TCP traffic, or custom protocols
- Use of other protocols on top of TCP, often TLS-encrypted
- Proxy unaware
While there are tools like BurpSuite NoPE extension and echo mirage, they didn’t quite fit our requirements or outright refused to work in some cases.
These problems can be overcome by using a tool called Mitm Intercept which was built by CyberArk.
Modern Problems Require Modern Solutions
The tool works by setting up the port to which the thick client application sends data, on your local machine. Any data received on this port is converted to HTTP and forwarded to Mitm_Intercept, which then converts it back to its original form and delivers it to the correct host.
Why convert to HTTP?
It’s so that the data can be easily captured with proxies like Burp.
If that was a bit overwhelming, here’s a handy diagram to help you understand better.
Getting Started
While the readme for the Mitm_Intercept repository is sufficient to help you get started, here’s an example of interception of a thick client traffic. We’ve used NetSPI’s BetaBank for this example:
Through the config file, it is clear that the application server is on 192.168.0.107, and the port is 1433.
This can also be confirmed using Wireshark. Let’s switch the Address to our machine (192.168.0.104) and then use Mitm_Intercept to set up a listener on that port.
We will also forward traffic to BurpSuite, which is listening on 192.168.0.106:8080.
An SSL certificate and private key can also be provided for encrypted communication using the -lc and -lk flags. A custom Python script to modify the traffic can also be provided using the -s flag. In this case, we’ve used the script below to print the first 10 bytes of captured messages and print them in hex. This is to identify TDS packets, that start with “1703”.
Upon running the application, we can see all the traffic being captured and forwarded through BurpSuite.
The lesson to learn here is, we don’t need to give up on a tool just because it has limitations. We can always extend their capabilities or weave them with other tools to achieve our goals.
