Application security

Application security testing of thick client applications

In this article, we will learn about thick client applications, their vulnerabilities and ways to carry out security assessment of these applications.

What are thick client applications?

A thick client, also known as Fat Client is a client in client–server architecture or network and typically provides rich functionality, independent of the server. In these types of applications, the major processing is done at the client side and involves only aperiodic connection to the server.

Thick client vs thin client applications

The thick clients are heavy applications which normally involve the installation of application on the client side (user computer). These application take up memory and run completely on the computers resources. This means that the security of the application is dependent on the local computer.

Thick clients are often not well-suited for public environments. To maintain a thick client, IT needs to maintain all systems for software deployment and upgrades, rather than just maintaining the applications on the server. Additionally, thick clients often require specific applications, again posing more work and limitations for deployment.

Typical examples of thick clients are G-Talk, Yahoo Messenger, Microsoft Outlook,online trading portals,etc…

The thin client applications are web-based application which can be accessed on the internet using a browser. These types of applications do not require any installation of software on the client side. The complete processing is carried out on the server. Also, these are light weight and do not occupy any space on the client side (user computer). In addition,thin client apps can be accessed by any computer or mobile device that has internet access, making them very portable. With that said, thin client apps are only as fast and reliable as the user's internet connection and the server's bandwidth.

Examples of thin client application are web-sites like google.com or yahoo.com.

The thick client applications are made of two types:

Two tier thick client application

The two tier thick client application consists of the user computer and the server. In this type, the application is installed on the client side, which directly communicates with the database on the server. These usually involve legacy applications. (E.g. - The VB.NET application directly communicating with the database using Open Database Connectivity)

Three tier thick client application

These kinds of thick client applications involve three tiers, wherein the client talks to the application server, which in turn talks to the database. The communication in these applications is carried out using HTTP/HTTPS. Examples of these applications involve G-Talk or Yahoo Messenger.

Security assessment of thick client applications

Application security assessments of thin client applications are comparatively easier than thick client application, as these are web based applications which can be intercepted easily and major processing takes place at the server side.

Since the thick client applications include both local and server side processing, it requires a different approach for security assessment.

The table below distinguishes the vulnerabilities faced by a web based and a thick client application:

#

Vulnerabilities

Web based vulnerabilities

Thick Client based vulnerabilities

1.

Improper error handling

Applicable

Applicable

2.

SQL Injection

Applicable

Applicable

3.

Cross Site Scripting

Applicable

Not applicable – browser based vulnerability

4.

Clickjacking attacks

Applicable

Not applicable – browser based vulnerability

5.

Parameter Tampering

Applicable

Applicable

6.

Insecure Storage

Applicable

Applicable

7.

Denial of Service

Applicable

Applicable

8.

Reverse engineering

Not Applicable

Applicable

9.

Broken access control

Applicable

Applicable

10.

Session management

Applicable

Applicable

Refer towww.owasp.org for more details on the vulnerabilities listed above.

List of tools that can be used intercepting thick client applications

1. Echo mirage:

Echo mirage is a network proxy tool that uses DLL injection and function hooking techniques to intercept the traffic transmitted and received by the local applications. Traffic can be intercepted in real-time or manipulated with regular expressions and a number of action directives.

Echo Mirage can be run in two different modes:

By launching an executable from Echo Mirage

Injecting into a currently running process

By launching an executable from Echo Mirage

In this option, the path of the application is provided into the Echo Mirage tool and it launches the selected application. The data sent and received by the application is intercepted by Echo Mirage.

The screenshot below shows the Gtalk traffic intercepted by the Echo Mirage tool.

Injecting into a currently running process:

In this, the Echo Mirage tool injects into the process by hooking into the socket calls.

Select the thick client application from the list of running processes, and inject Echo Mirage using the "inject into a running process" option from the tool.

Echo Mirage can also be useful in capturing data from JAVAApplets. For capturing data from a JAVA applet, inject Echo Mirage into the process "java.exe".

2. BURP Proxy invisible proxy mode

BURPProxy is an intercepting proxy server for security testing of web applications.

The BURP proxy tool can be used in invisible proxy mode to intercept the request from non-proxy-aware thick client applications (HTTP/HTTPS traffic only).

More Details can be found here:

http://blog.portswigger.net/2009/04/intercepting-thick-client.html

Mallory is a proxy tool that can intercept TCP and UDP traffic and can be used to capture network traffic or thick client applications using both HTTP(S) and non-HTTP(S) traffic.

In manycases, the above mentioned tools like Echo Mirage get hanged due to heavy network traffic and become difficult to test. Mallory comes to the rescue in such cases.

The ideal setup for Mallory is to have a "LAN" or "Victim" network that Mallory acts as the gateway for. This can be configured within a virtual machine environment using only network interfaces. The victim virtual machine then configures the Mallory machine as the gateway by manually setting its gateway. The gateway machine will have at least one WAN interface that grants Internet access. The victim network then uses the Mallory gateway to route traffic.

More details can be found here:http://intrepidusgroup.com/insight/mallory/

Wireshark is a network protocol analyzer tool that can be used to analyze the network traffic. This tool can be used to study the non-encrypted traffic sent by the thick client application.

More details can be found here:http://www.wireshark.org/

It allows for intercepting the traffic for thick client applications. ITR serves as a TCP tunnel between the client and the server. By instructing the client to open its connection to the ITR instead of the server, the entire connection is shifted to work through the ITR, without the client or the server noticing a difference.

More details can be found here:

http://download.cnet.com/Interactive-TCP-Relay/3000-2383_4-10239124.html

This tool can be used to intercept the methods, alter data and also test the security of JAVA applications on your computer.

More details can be found here: https://www.aspectsecurity.com/research/appsec_tools/javasnoop/

In the following sections, we will discuss the critical vulnerabilities faced by thick client application.

3. Sensitive data storage on files and registries

During the installation and execution of thick client applications, these apps tend to write/modify sensitive details in the files and registries. The sensitive data stored by these apps usually include username, passwords, database credentials, license details, cryptographic keys, and configuration details like IP address, port, etc…

The attacker can get access to these sensitive details and might compromise the application. In order to assess the application for sensitive data storage, we need to analyze the files and registries used by the application. Using a sysinternal tool called "Process Monitor", we can identify the files and registries used by a particular thick client application.

Process monitor

Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, registry and process/thread activity. This tool by default starts monitoring all processes. By setting up proper filters, it can be set to only capture the data related to a particular process.

Registry Monitoring:

Set the Process Monitor tool to intercept the registry activity as shown below:

Analyze the registries accessed by the application to check for sensitive details like keys, encrypted passwords, etc…

File Monitoring:

Set the Process Monitor tool to intercept the file access activity, as shown below:

Analyze the files accessed by the application to check for sensitive details like configuration details, log writing, caching files in folders, etc…

Listed below are a few sample exploits that a thick client application may face:

Sample exploits 1

A thick client tool (licensed version of a tool)after license registration on 'A' machine stores the license validation key and expiry date in encrypted format as a value in the registry. Whenever the tool is opened, a function in the tool validates against this registry value and provides access to the GUI of the tool.

Exploit: An attacker may export the registry key from 'A' machine and import this registry key into the 'B' machine to use the professional tool thereby bypassing the license registration process.

Sample exploit 2

During installation, a two tier thick client application stores a configuration file locally on the machine containing the database IP, port, username and password locally.

Exploit: An attacker might get access to this configuration file containing the database connectivity details. He might then directly connect to and compromise the database.

Sample exploit 3

A thick client application writing/storing application logs containing sensitive details like user accounts, trading details, last login date and time, etc… on the user machine.

Exploit: An attacker can get access to this machine and steal the user-specific details written onto the log files.

4. Response modification

We are all aware of capturing requests and tampering with the parameters for the testing of vulnerabilities in web-based applications. In the case of thick clients, major processing/validations are carried at the client-side. As a result, both the request as well as response modifications play a key role in testing the thick client for vulnerabilities.

Sample Exploit 1

Consider a thick client application that displays the GUI(modules/sub-modules) based on the response parameters received from the server after authentication.

For example, when an Admin logs in, the response sent by the application is as follows:

Response ----- …….U.s.e.r=A.D.M.I.N…..A.c.c.o.u.n.t.N.o=1111

When a low privileged user logs in, the response sent by the application is as follows:

Response ----- …….U.s.e.r=C.U.S.T.…..A.c.c.o.u.n.t._.N.o=2111

Exploit: In this case, the attacker or the lower privileged user will intercept the response and modify the User and Account_No parameter to that of the Admin and get access to the administrator module.

Sample Exploit 2

As we discussed above, the major validations are carried out at the client-side, a faulty implementation of the authentication process has been observed in various two-tier apps and is described below.

When a user enters the user name and password in the application, the application sends a SQL query to the database containing the username to retrieve the user credentials.

The SQL query is as follows:

Select MD5Hash_Password

From User_Table

Where User_Name='Admin1';

The response received from the database is as follows:

Response ---- … MD5Hash_Password= 3f7caa3d471688b704b73e9a77b1107f

It can be observed that only the username is sent to the database, and the database sends the valid password back in the response. This password is compared locally at the client side with the password entered by the user on the login page.

Exploit: The attacker can enter a correct username (say Cust1) and a wrong password on the login page. The application will send a SQL query to the database with the username entered, and retrieve the correct password. The attacker will then intercept the response, and steal the hashed password(Cust1 in this case).

All applications, be it web based or thick client applications, temporarily store data into the memory (Random Access Memory) for further processing. An application might store sensitive data like user credentials or encryption keys into the memory and store them until they get written by other data. An attacker may run a memory reading tool like WinHex in the machine to analyze the entire memory content used by the application.

The screenshot below shows the memory dump of Google Talk application.

Other vulnerabilities that can be tested for in thick client apps are as follows:

• SQL Injection
• Session Management
• Authentication
• Authorization
• Input validations
• Password management

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

 Sources

• OWASP – http://www.owasp.org