[vc_row][vc_column][vc_column_text]Tools that can intercept HTTP Requests/Response
Thick Clients often use an HTTP protocol for communication. The following is a list of some of the key HTTP proxy tools that are useful in testing proxy-unaware Thick Clients:
- Burp Suite by enabling invisible proxy mode
- Burp Suite with Microsoft Loopback Adapter
Burp Suite by enabling invisible proxy mode
Burp Suite utilizes a widely used HTTP proxy tool that is considered a tester’s best friend during a security assessment. When a proxy-unaware Thick Client is tested, Burp Suite has a special mode that allows the capture of requests from Thick Clients that create their own HTTP requests. An example of this is a Thick Client that uses the Apache HTTP Client package.
The following steps should be performed to set up the invisible mode in Burp Suite:
Note: We can identify the domain and port used by any proxy-unaware Thick Clients with the help of a network-monitoring tool such as Wireshark.
The first step involves resolving this domain to loop back the IP address (127.0.0.1). This is to ensure that whenever the request is fired from the application it does not reach the actual server and remains in the local machine. We can achieve this by making the following entry in the host file of the testing machine:
In Windows machines the host file can be found in the following path: c:\windows\system32\drivers\etc\.
In Linux machines the host file can be found in: /etc/hosts path.
After the entry is made in the host file we need to configure Burp Suite to listen to the loopback interface and forward the request to the actual IP address of the server. To achieve this we need to add a proxy listener in Burp Suite, as depicted in the following screenshots.
Configuration for the loopback listener:
Note: any of the following two methods can be used for forwarding the request to the actual server.
- Configure the listener to redirect the captured request to the actual server:
- The Hostname Resolution feature of the Burp suite tool can also be used for resolving the domain name to the actual IP address.
Once the Burp Suite is configured as described above, we can capture the request sent by a proxy-unaware Thick Client.
The key configuration in this technique is resolving the actual domain to the loopback IP address. This can be done by making an entry in the host file. If the Thick Client application does not send the request to a domain or a host name, then it is impossible to make a host file entry. An example of such a request would be: http://184.108.40.206:9079/app/login.
Burp Suite with Microsoft Loopback Adapter
As mentioned earlier, the key limitation of the Burp invisible proxy mode is that it cannot intercept the requests directly fired to an IP address instead of a domain or a host name. There is a workaround for this scenario and it is achieved by using Microsoft Loopback adapter with Burp Suite.
To create this setup we need to have two machines residing in the same network. Both machines need to have Burp Suite tool running and one machine should have Microsoft Loopback Adapter installed.
In this setup, the machine where Microsoft Loopback Adapter is installed (in our case Machine 1) should be used as the testing machine and the second (i.e. Machine 2) acts as a gateway that forwards the requests to the internet.
What is Microsoft Loopback Adapter?
Microsoft Loopback Adapter is a dummy network card, i.e. no hardware is involved. It is used as a testing tool for a virtual network environment where network access is not available.
To install Microsoft Loopback adapter the following steps should be followed.
- Click the Start menu.
- Search for “cmd".
- Right-click on “cmd” and select “Run as Administrator”.
- Enter “hdwwiz.exe”.
- In the "Welcome to the Add Hardware Wizard", click Next.
- Select "Install the hardware that I manually select from a list (Advanced)" and click Next.
- Scroll down and select "Network adapters" and click Next.
- Select "Microsoft" as the Manufacturer and then select the Network Adapter "Microsoft Loopback Adapter" and click Next.
For our setup, we use this adapter to deceive the local machine so that all the requests fired to the actual server are redirected to the Loopback adapter. This can be achieved by setting the same IP address of the Microsoft Loopback adapter as the actual server’s IP address.
Machine 1 (10.0.1.1):
This is the testing machine where the proxy-unaware Thick Client application is running. This machine should be set to the following configuration:
- Microsoft Loopback adapter is installed and has the same IP address as the server.
- Burp Suite is configured to listen on the Loopback adapters IP address.
- Burp Suite is configured to forward the requests to Machine 2 (0.1.2).
Let us assume that the Thick Client application sends the following request:
Note: We can identify the domain and the port used by any proxy-unaware Thick Client with the help of a network-monitoring tool such as Wireshark.
As we have set the IP address of the Loopback adapter to be identical to that of the actual server (in our case 220.127.116.11), when the proxy-unaware Thick Client application fires a request, it will be sent to the loopback adapter. As the listener on Burp Suite listens on the same IP address, Burp will be able to capture this request. We need to make sure that this request is forwarded to Machine 2 (10.0.1.2), so that the request can reach the actual destination server. The following screenshots show the Burp Suite configuration in Machine 1.
Machine 2 (10.0.1.2):
This machine acts as a gateway that sends the requests forwarded by Machine 1(10.0.1.1) to the destination server. Internet connectivity is an important prerequisite for this machine.
The key configuration in this machine is to set up a Burp Suite Listener on the network adapter with the IP address 10.0.1.2 and redirects traffic to the actual server. The Burp listener on loopback IP address will ensure that the requests are captured and the redirect to host configuration will forward those requests to the destination server.
The following screenshots show the configuration:
Mallory transparent Proxy:
Mallory is a proxy tool that has the ability to capture TCP and UDP network traffic. It is a Linux-based tool and so can only be installed on a Linux machine. There are multiple ways to set up Mallory; however, the easiest and the most reasonable way while testing would be with the help of two virtual machines by enabling the NAT mode. These virtual machines will use the host machine’s internet connection.
- VM Machine 1: where the Thick Client application is installed.
- VM Machine 2: where Mallory is installed with two NICs, viz. eth0 and eth1.
These virtual machines should be configured as follows:
VM Machine 1:
Let us assume that this machine is a Windows 7 machine. This machine should be configured in such a way that the gateway of this machine is the eth0 interface of Machine 2 and DNS server is the eth1 interface of Machine 2.
VM Machine 2:
This machine should be a Linux machine with two network interfaces (e.g., eth0 and eth1). Out of these two, one should be listening as a gateway interface. There is no special configuration required for this; we have to just assign a static IP address to this interface. The second interface should be running a DNS server to resolve the requested domains, which can be done by starting the DNSMASQ service on eth1.
Mallory can be installed on this machine by running the Mallory_Install.sh file available at https://bitbucket.org/IntrepidusGroup/mallory/downloads/mallory_install.sh. Once Mallory is installed we need to configure this tool to act as an interface that connects the NICs eth0 and eth1.
Once it has been configured properly, Mallory receives the traffic from the gateway interface, i.e., eth0, and forwards it to the internet-facing interface, i.e., eth1.
How does this setup work?
As mentioned earlier, Thick Client applications run in VM machine 1. As we have set up the gateway of this machine as eth0 interface of VM Machine2, when the application fires a request it is sent to eth0, which captures the request and, in turn, sends it to Mallory. Once Mallory has captured this request, its user-friendly GUI allows the tester to modify requests. Furthermore, Mallory forwards this request to the internet-facing NIC eth1, which resolves the actual domain of the request and sends it to the actual server.
The following diagram depicts the working of Mallory.
Out of the above-mentioned tools, Mallory has an added advantage that it can intercept even non-HTTP traffic. In addition, this tool allows users to integrate custom python scripts that help in testing non-HTTP clients. The only limitation is setting up this tool as Mallory tool installation and the establishment of the virtual machines is time-consuming.
The Mallory Interface is shown below:
About the Author
Muhammed Noushad K. is an EC Council-Certified Security Analyst (ECSA) involved in information security for the past five years. He has rich experience in Application Security and Secure Code Reviews. Currently, he is employed as a Security Researcher at Paladion Networks, an information security organization providing security services for corporate organizations in India, Malaysia, the Middle East, and the USA. Paladion’s mission is to harness global technologies to deliver trusted solutions for creating a secure business environment.Speak to our application security experts