Thick Client Security Assessment — I
By: Saksham Chawla
Tags: Windows, Owasp, Operating Systems, Thick Client, Cybersecurity

“What are Thick Clients really?”

“And I need to make sure they are secure?”

“What could possibly be an exploit for such applications?”

Before we begin note that I’ve used the DVTA project for this blog. I’ll be referencing the same throughout this post. You can download the project and set it up for yourself and dive straight into exploiting it(I recommend setting it up on a VM). Alright, let’s start.

Thick clients can be referenced by many names: Fat Clients, Rich Clients or even Heavy Clients. Such applications follow a client-server architecture and can be developed using various programming languages such as .NET or JAVA. These can either be executables or web-based applets(Eg: XBAP).

In this blog post, the main focus areas have been derived from the OWASP Windows Binary Executable Files Security Checks Project. Apart from vulnerabilities that are specific to Thick Client applications, I will provide an overview on different phases that are involved during the assessment, such as Information gathering, Traffic analysis, Client side and Server Side analysis.

First a brief introduction …

Auditing Thick Client applications for vulnerabilities generally include Authentication bypasses, Unauthorized executions, Privilege Escalations and Sensitive Information disclosures through application misconfigurations and crashes. Most of these vulnerabilities share a background with the OWASP standard for Web Applications. The following table shows the applicability of

OWASP Top 10 vulnerabilities in Web Application to Thick Client applications.

Thick Client Application Security

Thick clients usually require installation on the client machine(could be temporarily), this implies that deploying and updating the application is not limited to the application server but would also involve the client-side installed application instances. In comparison to thin clients, thick clients can provide functionality that is not dependent on the application server. Processing takes place mostly on the client instance, which in turn also means that application security is heavily dependent upon the client itself.

There are two architectures that thick clients can be deployed under:

● 2-Tier system

● 3-Tier system

2 Tier System

3 Tier System

In 2-Tier systems, processing is mostly done on the client instance, whereas in 3-Tier systems processing relies on the application server. In comparison, 2-Tier systems are more vulnerable to exploits as they are prone to reveal sensitive details such as database credentials, usernames, and passwords.

Setting up Proxies

At this point, we can start capturing application traffic like when assessing web applications. But first, we need to figure out how thick clients will communicate with such a proxy.

Thick Clients can be classified into two categories:

● Proxy aware

● Proxy unaware

Proxy aware applications require an address, in addition to application credentials. This makes proxying application traffic easier. Proxy unaware applications, on the other hand, pose a challenge. Traffic needs to be redirected to the client system, where the intercepting proxy’s listener would then again redirect the traffic to the actual application server.

Proxy Unaware

For proxy unaware applications, application server’s IP address and ports need to be figured out. Using commands like ‘ping’ will provide the actual IP address of the host domain. Using tools such as WireShark or TcpDump(SysInternals Suite), corresponding ports can also be determined.

Using WireShark to analyze traffic

To redirect the traffic back to the system where the intercepting proxy resides, the hostname or domain needs to be resolved to the loopback address. This can be ensured by making an entry within the ‘hosts’ file.

Mapping Hostname to loopback address

Using tools such as BurpSuite, an intercepting proxy should be configured to act as a loopback listener. The details about the IP address and ports obtained earlier, can be used to redirect the traffic being intercepted, to the application server.

Using Burp as loopback listener

For traffic that use HTTP/S, tools such as Burpsuite(invisible proxy mode) and Mallory can be used. For non-HTTP/S traffic tools such as Fiddler, Procmon(SysInternals Suite), Wireshark and EchoMirage are useful. We can also use JavaSnoop in case of Java based platform and SoapUI for soap requests.

Sometimes thick clients will not send traffic to a given hostname or domain. In cases where the application directly uses the IP address of the application server, we can use Microsoft’s loopback adapter which acts as a dummy network. Once the adapter has been installed we can configure it with the address of the actual server. The intercepting proxy residing on the same

machine can then hook to the same address as that of the loopback adapter. Once the proxy tool starts intercepting we have to forward this traffic to another instance of the proxy tool, which will reside on another machine, acting as our gateway to the actual application server.

Using the loopback adapter as a dummy network

This approach, however, is limited due to the constraint that two machines with separate intercepting proxy instances are required.

That’s it for Part-I, in the coming blogs I will discuss the exact phases of exploitation. These will comprise of the following:

● Information gathering

● Client side analysis

● Traffic analysis

● Server side analysis

Note: This post is only indicative of what application security for thick clients entails. There are in-depth articles on the web that might contain more information. I recommend going through the reference section and exploring the articles/posts for more detailed information. These are very well written and were the basis of my own research.

UPDATE: PART II, PART III and PART IV .

References

[1]https://andersontech.com/network-security-audit/

[2]https://www.owasp.org/index.php/OWASP_Windows_Binary_Executable_Files_Security_Checks_Project

[3]https://www.paladion.net/blogs/thick-client-testing-toolkit-part-1-introduction

[4]http://blog.securelayer7.net/thick-client-penetration-testing-1/

[5]http://securitywarrior9.blogspot.com/2017/08/intro-to-thick-client-penetration.html

[6]http://nileshkapoor.blogspot.com/2011/10/pentesting-thick-client-apps.html

[7]https://resources.infosecinstitute.com/application-security-testing-of-thick-client-applications/#gref

[8]https://resources.infosecinstitute.com/practical-thick-client-application-penetration-testing-using-damn-vulnerable-thick-client-app-part-1/#article