Thick Client Penetration Testing Tutorials - Part 5

For carrying out penetration testing assessments, our main aim has been to resolve the actual domain to the loopback IP address, by adding an entry to the hosts file.

Let us know consider a situation where the thick Client application does not send the request to a domain or a host name, then what happens?

We are stuck since it becomes impossible to make a host file entry.

Consider a thick client url like http://172.32.23.23:891/login. It cannot be mapped in hosts file without a valid pointing domain.

So lets do a workaround via configuring burp with the concept of Microsoft Loopback Adapter.

Prerequisites:

Two machines residing in the same network ,both having Burp Suite tool running
One machine (the testing machine) should have Microsoft Loopback Adapter configured.
The second machine acts as a gateway that forwards the requests to the internet.
The loopback adapter helps deceiving the local machine. In absence of a real domain, all the application requests fired to the actual server are redirected to the Loopback adapter by setting the same IP address of the Microsoft Loopback adapter as the actual server’s IP address.

Those not aware with the concept of the loopback adapter, Microsoft Loopback Adapter is a dummy network setup.

It is a kind of hidden easter egg feature of windows, which you can enable by the following steps:



Run cmd as Admin.
Enter “hdwwiz.exe”.
Welcome to the Add Hardware Wizard”, click Next.
Install the hardware manually
Network adapters
Select “Microsoft” as the Manufacturer and then select the Network Adapter “Microsoft Loopback Adapter” and click Next.


Setting up loopback adapter_1

In network connections tab, you can see it:





Machine 1 (xx.xx.xx.x1):

This is the testing machine where the Thick Client application is running.

We configure the below settings to make it ready:

Microsoft Loopback adapter is installed with the TCP/IP address of the actual server ( in our example: 172.32.23.23:891)
Burp Suite is configured to listen on the Loopback adapters IP address.
Burp Suite is configured to forward the requests to Machine 2
Once we fire an actual request, the below execution happens:


Scenario:

IP address of the Loopback adapter is of the actual server, the Thick Client application sends an HTTP  request, which first goes to the loopback adapter.

The listener setup on Burp Suite hooke to the same IP address, capturing it.

What do to next?

Since the request meant for the actual server is stuck in machine one with the loopback adapter and burp, we need to forward it to  Machine 2 (xx.xx.xx.x2), so that the request can reach the actual destination server.

Setting up IP details on loopback adapter.

Let’s see how the logic works by a simple diagram:




High level working

The following screenshots show the Burp Suite configuration in Machine 1.

Assumption: The actual server IP is 172.32.23.23:891


We now need to forward the request to the second machine ( xx.xx.xx.x2)



Machine 1

Burp setting with loopbackMachine 2 (xx.xx.xx.x2):

This machine will be configured to route the requests from machine 1 to the actual server.gateway that sends the requests forwarded by Machine 1(xx.xx.xx.x1) to the destination server.

Configuration checklist to be setup for machine 2:

Set up a Burp Suite Listener on the adapter with the IP address xx.xx.xx.x2
Configure redirection of  traffic to the actual server ( in our case, the actual ip of the server (172.32.23.23:891)
Burp listener on loopback IP moderates the requests for  capture
Finally the redirect to host configuration forwards those requests to the destination server.
The following screenshots show the configuration:



Requests via burp to actual server ( machine 2 burp)That’s it. Once done, the application will start intercepting as well as redirect the requests to the IP which does not have domain name mapped!

Happy hacking!

Comments

Popular posts from this blog

Arbitrary file upload and RCE in Wonder CMS - CVE-2017-14521

Cross Site Request Forgery- Intex Router N-150 | CVE-2018-12529

Stored XSS in Wonder CMS- CVE-2017-14522