- 1 Introduction
- 2 Common Architectures of Thick Client applications
- 3 How to test thick client applications?
- 3.1 Information Gathering
- 3.2 Client-Side attacks
- 3.3 Server-side Attacks
- 3.4 Hacking Playgrounds
- 3.5 Closing Words
Introduction
Thick client applications have been around for many years and can still be found within a variety of organizations – across industries and sizes. Due to the adoption of hybrid infrastructure architecture, thick-client applications can become a better target for attackers.
Thick client pentesting involves both local and server-side processing and often uses proprietary protocols for communication.
Simple automated assessment scanning is not sufficient and testing thick client applications requires a lot of patience and a methodical approach. Moreover, the process often requires specialized tools and custom testing setup.
Thick client testing can be exciting for pentesters because the attack surface of these applications can be significant. Unlike web applications or infrastructure pentests, thick client pentests have a more notable success rate because the client is available locally and, hence, critical vulnerabilities may be found during the engagements. For example, here is a couple of vulnerabilities found by security researchers:
- https://www.cyberark.com/threat-research-blog/lazy-privilege-escalation-abusing-dells-dup-framework-cve-2019-3726/
- https://rhinosecuritylabs.com/application-security/nvidia-rce-cve-2019-5678/
- https://pwning.re/2018/12/04/github-desktop-rce/
- https://medium.com/@mantissts/more-thick-client-fun-73196809493d
- https://hackerone.com/reports/513154
- https://hackerone.com/reports/291539
This blog post aims to provide a security check-list and a number of tools to refer to when assessing the security of Windows executable files to achieve better pentest results.
We began researching pentesting thick client applications in order to eventually build an overarching methodology for pentesters which would serve as single source to reference for everything to with pentesting thick client applications, summarizing all the relevant and up-to-date knowledge on the subject. Moreover, the methodology refers to relevant tools in each section that can be used during pentests engagements.
Thick client applications can be developed using various programming languages such as:
- .Net
- Java
- C/C++
- Microsoft Silverlight
The main focus areas have been derived from the OWASP Windows Binary Executable Files Security Checks Project.
Common Architectures of Thick Client applications
In this section, we provide an overview of the common architectures that Thick Client application developers tend to use.
Two-Tier architecture
In two-tier architecture, the thick client application implements a client-to-server communication. The application is installed on the client computer and, in order to work, will need to communicate with a database server. For example, imagine an HR application that was installed on the client computer and, in order to retrieve the employees’ information, communicates directly with the HR database server.
Three-Tier architecture
In three-tier architecture, the client communicates with an application server, which in turn talks to the database in a manner similar to a regular web application. The most common communication method in these applications may be carried out using HTTP/HTTPS.
Three-tier architecture has a security advantage over two-tier architecture, because it prevents the end-user from communicating directly with the database server.
How to test thick client applications?
Thick client applications are generally more complicated and customized than web or mobile applications, so they need a specific approach when it comes to a penetration test.
The first steps to take when facing a thick client application is to gather information, such as:
- Discovering what technologies are being used on both the client and the server sides.
- Figuring out the application’s functionality and behavior.
- Identifying all of the different entry points for user input.
- Understanding the core security mechanisms used by the application.
- Identifying common vulnerabilities like languages and frameworks.
Information Gathering
Application Architecture and Identifying the Languages and Frameworks Used
It is essential to understand the full functionality of the tested thick client application tested during a pentest. Moreover, it is important to navigate through all of the UI elements with multiple users. Each user might have different permissions and unique functionalities that need to be discovered.
For example, the admin user might see additional administrative actions that a regular user might not see on his thick client UI.
Moreover, knowing which language the thick client was built in is very useful when reversing the thick client binary.
There are several tools that can aid in the process of identifying the development language used to build the thick client application.
The following table presents a set of static tools that can be used:
| # | Tool Name | Description |
| 1 | CFF Explorer | A tool that was designed to make PE editing as easy as possible without losing sight of the portable executable’s internal structure. |
| 2 | PEid | A tool that detects most common packers, cryptors and compilers for PE files. |
| 3 | Detect It Easy (DIE) | A program for determining file types for Windows, Linux and macOS. |
| 4 | Strings | A tool that scans any files you pass it for UNICODE or ASCII strings of a default length of three or more UNICODE or ASCII characters. |
In Figure 2, We loaded the DVTA.exe thick client binary into the CFF Explorer tool and received basic information about the thick client’s development language (marked in red).
As can be seen in Figure 3, using another tool named “Detect It Easy (DIE),” we retrieved some basic information about the tested thick client application.
Figures 2 and 3 show that the binary was built using Microsoft Visual Studio .NET. There are many .NET decompilers available on the internet that can be used to retrieve the source code for further analysis.
The following table presents a set of .NET decompilers and deobfuscators tools:
| # | Tool Name | Description |
| 1 | dnSpy | A .NET debugger and assembly editor. |
| 2 | ILSpy | ILSpy is the open-source .NET assembly browser and decompiler. |
| 3 | JetBrains DotPeek | A program for determining types of files for Windows, Linux, and macOS. |
| 4 | de4dot | .NET deobfuscator and unpacker. |
| 5 | NeonFuscatorDeobfuscator | .NET deobfuscator for Autori Obfuscator (NeonFuscator). |
Network Communication Between the Client and the Server
So, now that we’ve identified the development language used to build the tested thick client application we tested. The next step is to sniff the traffic between that thick client application and the local/remote server. As a penetration tester, learning how to use a network packet sniffer is essential for day-to-day operations. Whether you are trying to understand a protocol, debug a network client or analyze traffic, you’ll always end up needing a network sniffer.
The following table presents a set of network sniffers tools that can be used in this part:
| # | Tool Name | Description |
| 1 | Wireshark | Wireshark is the world’s foremost and most widely-used network protocol analyzer. |
| 2 | TCPView | TCPView is a Windows program that shows detailed listings of all TCP and UDP endpoints on your system, including the local and remote addresses and the state of TCP connections. |
| 3 | SmartSniff | SmartSniff is a network monitoring utility that allows you to capture TCP/IP packets that pass through your network adapter and view the captured data as sequence of conversations between clients and servers. |
| 4 | tcpdump | tcpdump is a common packet analyzer that runs under the command line. It allows the user to intercept and display TCP/IP and other packets being transmitted or received over a network to which the computer is attached. |
| 5 | Microsoft Network Monitor 3.4 | Microsoft Network Monitor 3.4 is a tool for network traffic capture and protocol analysis. |
Examining the traffic between the tested thick client application and the server might reveal sensitive and unencrypted data such as:
- Sensitive data transferred over an unencrypted tunnel (clear-text credentials/secrets/API Keys etc.)
- HTTP and HTTPS web endpoints (Web Services, REST API)
- File blobs/chunks sent over the wire
- Proprietary protocols used by the program
As can be seen in Figure 4, we can see what happens when a user performs a login on the DVTA thick client application.
A SQL query was sent in clear-text and was captured using the Wireshark sniffer tool:
In order to intercept the traffic between the tested thick client application and the server, we should use a proxy tool. The proxy tool will be in the middle between the thick client and the local/remote server, enabling us to view and modify the transmitted data.
When we talk about intercepting thick client traffic, we should know the difference between:
- Proxy aware – A thick client that has settings options in the application itself.
- Non-proxy-aware – A thick client that does not have any settings options in the application itself and requires a different testing approach.
If the thick client application is a proxy aware, it may be possible to intercept the traffic using any proxy tool.
When the thick client is non-proxy-aware, Burp Suite’s support for invisible proxying allows non-proxy-aware clients to connect directly to a Proxy listener.
More details for this specific tool can be found on this support page.
Figure 5 presents the steps for configuring the invisible proxy feature on Burp Suite tool.
In addition to Burp Suite, there is an alternative proxy tool named Echo Mirage. Echo Mirage enables intercepting non-HTTP traffic between the tested thick client and the local or remote server.
Echo Mirage can hook into the tested thick client application process so that communication between the tested thick client application and the local or remote server can be intercepted and edited. This can provide us insight into what kind of data was transmitted from the tested thick client application to the local or remote server.
NOTE: Remember that most of the thick client applications you will encounter were developed a long time ago and, therefore, the transmitted data is probably not be encrypted.
When you open the Echo Mirage tool, you will see two main tabs:
- Traffic Log – Watch a full record of all messages that have passed through the Proxy.
- Rules – Watch the currently configured rules and also add/change/delete interception rules.
Figure 6 presents the steps for injecting Echo Mirage into a currently running process.
Do you still remember the SQL query that we previously captured using the Wireshark tool? Now, using the Echo mirage tool, we can intercept the same TCP packet and modify the SQL query.
Figure 7 presents the SQL query that was captured after we injected Echo Mirage into the Damn Vulnerable Thick Client Application’s process.
The following table presents a set of proxy tools that can be used:
| # | Tool Name | Description |
| 1 | Burp Suite | Burp Suite Professional is an advanced set of tools for testing web security. |
| 2 | Fiddler | Fiddler is a free web debugging tool which logs all HTTP(S) traffic between your computer and the Internet. |
| 3 | Echo Mirage | Echo Mirage is a versatile local proxy tool that can be used to intercept and modify TCP payloads for local Windows applications. |
| 4 | Charles Web Debugging Proxy | Charles is an HTTP proxy that enables to view all of the HTTP and SSL / HTTPS traffic between the local machine and the Internet. This includes requests, responses and the HTTP headers. |
Client-Side attacks
Files Analysis
Applications usually store information in local files and the registry. Sensitive information that we might look for in a thick client pentest includes:
- Usernames
- Passwords
- Connection Strings
- API keys
For this step, it is crucial to know which files are being used by the tested thick client application. We can use the Process Monitor tool from the Sysinternals Suite to collect all the necessary information.
Figure 8 presents the Process Monitor tool with the applied filter:
The Process Monitor tool should be showing us only the relevant operations we wanted to see, those related to the tested thick client application.
Figure 9 presents the results of the operations after applying the filter.
The following table presents a set of file analysis tools that can be used in this part:
| # | Tool Name | Description |
| 1 | Process Monitor | An advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. |
| 2 | Regshot | An open-source (LGPL) registry compare utility that allows you to quickly take a snapshot of your registry and then compares it with a second one – used after doing system changes or installing a new software product. |
| 3 | Process Explorer | Provides the functionality of the Windows Task Manager along with a rich set of features for collecting information about processes running on the user’s system. It can be used as the first step in debugging software. |
| 4 | Process Hacker | A free, powerful multi-purpose tool that helps you monitor system resources, debug software and detect malware. |
Identifying DLL Hijacking Vulnerability
The next step is to examine if the tested thick client application is vulnerable to a DLL hijacking vulnerability.
DLL hijacking is an attack that exploits the Windows search and load algorithm, allowing an attacker to inject code into an application through disk manipulation. In other words, simply putting a DLL file in the right place causes a vulnerable application to load that malicious DLL.
This attack method has been in use since the beginning of Windows 2000 and is still alive and kicking. My colleague at CyberArk Labs, Eran Shimoni wrote about his research on this topic in his blog post, “DLLSpy – Tighten Your Defense by Discovering DLL Hijacking Easily.”
When the thick client application tries to load a DLL, it will go through the following in order:
- The directory from which the application is loaded
- C:\Windows\System32
- C:\Windows\System
- C:\Windows
- The current working directory
- Directories in the system PATH environment variable
- Directories in the user PATH environment variable
To be able to escalate privileges via DLL hijacking, the following conditions need to be in place:
- Write Permissions on a system folder.
- Software installation in a non-default directory.
- A service that is running as a system and is missing a DLL.
- Permissions for restarting the service.
The following table presents a set of tools designed for testing for DLL Hijacking vulnerability:
| # | Tool Name | Description |
| 1 | DLLSpy | A tool that detects DLL hijacking in running processes and services and in their binaries. |
| 2 | Robber | An open-source tool for finding executables prone to DLL hijacking. |
Run the process monitor tool and apply a filter as shown in Figure 10:
The Process Monitor tool will identify if the application is trying to load any DLLs and the actual path that the application uses when looking for the missing DLLs.
In Figure 11, we can see that the DVTA.exe process is missing several DLLs files that can be used for privilege escalation.
Thick client application configuration files typically contain valuable information for pentesters such as:
- Usernames
- Passwords
- License details
- Cryptographic keys
- IP addresses and ports
Identifying Interesting Files Bundled with the Thick Client Application
The configuration files are usually readable by all operating system users, which allows anyone who can read the file access to the compromised resources.
The following table presents a set of tools aimed for locating sensitive data storage on files and registry:
| # | Tool Name | Description |
| 1 | Process Monitor | An advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. |
| 2 | Regshot | An open-source (LGPL) registry compare utility that allows you to quickly take a snapshot of your registry and then compares it with a second one – used after doing system changes or installing a new software product. |
| 3 | Process Explorer | A tool that provides the functionality of the Windows Task Manager along with a rich set of features for collecting information about processes running on the user’s system. It can be used as the first step in debugging software. |
| 4 | Process Hacker | A free, powerful multi-purpose tool that helps you monitor system resources, debug software and detect malware. |
Usually, a thick client application contains several configuration files in the root folder of the application or in a specific configuration folder.
In Figure 12, we can see the root folder of the DVTA thick client application, including some configuration files, DLLs and other files.
When inspecting the DVTA.vshost.exe.config file’s content, we can see how the sensitive data has been stored, as shown in Figure 13:
Because the information is stored in cleartext, attackers could potentially read it. Even if the information is encoded in a way that is not human-readable, certain techniques could be used to determine which encoding is being used and then decode the information.
As pentesters, we might stumble against thick clients in black/gray-box testing scenarios. We may not have any prior knowledge or any documentation on the tested application.
For this challenge, we can use a decompiler tool to retrieve the tested thick client application’s source code of. A decompiler is a computer program that takes an executable file as input and attempts to create a high-level source file that can be recompiled successfully.
NOTE: The most popular development languages we faced was .NET or Java. Thick clients that were developed in those languages can be decompiled simply using open-source decompilers, provided the application has not undergone an obfuscation process.
Binary Analysis
After we have the source code for the tested thick client, we can start searching through the code for sensitive information, such as:
- Hard-coded credentials
- API Keys
- API Endpoints
- Comments
- Hidden functions
The following table presents a set of binary analysis tools that can be used in this phase:
| # | Tool Name | Description |
| 1 | Ghidra | A suite of free software reverse engineering tools developed by the NSA’s Research Directorate. It was originally exposed in WikiLeaks’s “Vault 7” publication and is now maintained as open-source software. |
| 2 | Immunity Debugger | Immunity Debugger is a powerful new way to write exploits, analyze malware and reverse engineer binary files. |
| 3 | Interactive Disassembler (IDA Pro) | Proprietary multi-processor disassembler and debugger for Windows, GNU/Linux or macOS. It also has a free version, IDA Free. |
| 4 | OllyDbg | x86 debugger for Windows binaries that emphasizes binary code analysis. |
| 5 | Radare2 | Open source, cross-platform reverse engineering framework. |
| 6 | dnSpy | A tool to reverse engineer .NET assemblies. |
| 7 | x64dbg | Open source x64/x32 debugger for windows. |
| 8 | JetBrains DotPeek | Free .NET decompiler and assembly browser. |
| 9 | ILSpy | Open-source .NET assembly browser and decompiler. |
| 10 | JD-GUI | A standalone Java decompiler GUI. |
| 11 | Jadx | Dex to Java decompiler. |
| 12 | Bytecode Viewer | A lightweight user-friendly Java bytecode viewer. |
| 13 | Luyten | An Open source Java Decompiler GUI for Procyon |
| 14 | PE Explorer | View, Edit and Reverse Engineer EXE and DLL Files. |
| 15 | UPX Decompression | A free, portable, extendable, high-performance executable packer for several executable formats. |
| 16 | Frida | A dynamic instrumentation toolkit for developers, reverse-engineers and security researchers. |
For .NET applications, it is possible to decompile multiple formats including libraries (.dll), executables (.exe) and Windows metadata files (.winmd).
For Java applications, it is possible to decompile multiple formats including JAR, CLASS, WAR, EAR, AAR, KAR, JMOD and JNLP.
Figure 14 presents the dnSpy decompiler loaded with our tested thick client executable DVTA.exe. When inspecting the source code, it is possible to quickly find a hard-coded connection string to an FTP service:
Weak Graphical User Interface
During our work as pentesters, we might encounter thick client applications that serve numerous users with different privileges. The user interface might include operations for administrators, that have been disabled for low privileged users.
For example, imagine an admin user who logs in to a thick client application with administrative functionalities in his user interface. For a regular user, those functionalities will be disabled, because regular users do not have the appropriate permission for the administrative functionalities.
Therefore, to test for user interface vulnerabilities as a low privileged user, we will need to use various tools to manipulate window objects in Windows, such as:
- Buttons
- Menu bars
- Text boxes
- OCX controls
Basically, anything that can be located as a child window and has an active window handle can be manipulated with some predefined attributes.
The following table presents a set of weak GUI control tools that can be used:
| # | Tool Name | Description |
| 1 | WinSpy++ | A tool whose purpose is to help you view and modify the properties of any window in your system with great ease. |
| 2 | WinManipulate | A simple tool to manipulate window objects in Windows. |
| 3 | Windows Enabler | A simple tool that lets you activate functions your thick client application has blocked. |
Memory Analysis
When testing for vulnerabilities in the tested thick client application, we should perform a memory analysis while the thick client application runs. Thick client applications developed in a two-tier architecture transfer sensitive information in the application’s memory.
This is a design flaw, because every thick client application developed in a two-tier architecture will, by default, disclose sensitive information in the application’s memory, such as:
- Usernames
- Passwords
- Connection strings
- Hardcoded database credentials
The following table presents a set of memory analysis tools that can be used in this phase:
| # | Tool Name | Description |
| 1 | Winhex | An advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. |
| 2 | Volatility | An open-source (LGPL) registry compare utility that allows you to quickly take a snapshot of your registry and then compares it with a second one – used after doing system changes or installing a new software product. |
| 3 | Process Explorer | Provides the functionality of the Windows Task Manager along with a rich set of features for collecting information about processes running on the user’s system. It can be used as the first step in debugging software. |
| 4 | Strings | Strings scans any file you pass it for UNICODE or ASCII strings with a default length of three or more UNICODE or ASCII characters. |
Figures 15-18 demonstrate how to export memory data on a tested thick client application’s memory with the use of Process Hacker tool.
In the properties window, we should choose the Memory tab, click on the Strings button and then click OK.
Hacker Process tool has a great filter mechanism that can help us search for a keyword somewhere in all of the dumped memory data.
Figure 18 presents the extracted memory from the tested thick client application, which contains a cleartext connection string to the application’s database.
Now, we can use any SQL client such as HeidiSQL to connect to the database using the credentials retrieved.
Server-Side Attacks
OWASP TOP10 Vulnerabilities
Once we have performed all the particulars of thick client testing, we can now focus on the OWASP Top10.
The following list presents the relevant vulnerabilities for thick client testing:
- A1:2017-Injection
- A2:2017-Broken Authentication
- A3:2017-Sensitive Data Exposure
- A4:2017-XML External Entities (XXE)
- A5:2017-Broken Access Control
- A6:2017-Security Misconfiguration
- A7:2017-Cross-Site Scripting (XSS) (Not applicable for a thick client testing)
- A8:2017-Insecure Deserialization
- A9:2017-Using Components with Known Vulnerabilities
- A10:2017-Insufficient Logging&Monitoring
The most common vulnerability in thick client applications is SQL Injection.
According to OWASP, injection flaws, such as SQL, NoSQL, OS and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Even today, developers are still making the same mistakes that cause SQL Injection vulnerabilities.
SQL injection can be detected manually by using a systematic set of tests against every entry point in the application. This typically involves:
- Submitting the single quote character (‘) and looking for errors or other anomalies.
- Submitting some SQL-specific syntax that evaluates to the base (original) value of the entry point and a different value and then looking for systematic differences in the resulting application responses.
- Submitting Boolean conditions, such as OR 1=1 and OR 1=2, and looking for differences in the application’s responses.
- Submitting payloads designed to trigger time delays when executed within an SQL query and looking for differences in the time taken to respond.
- Submitting OAST payloads designed to trigger an out-of-band network interaction when executed within an SQL query and monitoring for any resulting interactions.
Most SQL injection vulnerabilities arise within the WHERE clause of a SELECT query. This type of SQL injection is generally well-understood by experienced testers.
But, SQL injection vulnerabilities can, in principle, occur at any location within the query and within different query types.
The most other common locations where SQL injection arises are:
- In UPDATE statements within the updated values or the WHERE clause.
- In INSERT statements within the inserted values.
- In SELECT statements within the table or column name.
- In SELECT statements within the ORDER BY clause.
Let’s check if our tested thick client application is also vulnerable to SQL Injection vulnerability.
By inspecting the CheckLogin method, we can see that the username and the password values are being inserted into the SQL query without any validation.
Figure 20 presents the SQL query used by the thick client application in order to validate if the logged-in user is valid, which means that user exists in the application database and the username matches the password entered.
The above query can be exploited by commenting out the password part and appending a condition that will always be true. Let’s assume an attacker provides the following input in the username field: ‘ or 1=1–
Let’s check if the Damn Vulnerable Thick Client Application is vulnerable to SQL injection vulnerability by setting the username value to ‘ or 1=1– and the password field can be set to any value because it will be commented out.
As can be seen in Figure 22, we successfully bypassed the login mechanism and authenticated to the application on behalf of Raymond’s account.
Figure 23 presents the tested thick client application’s users table in the database.
In the following Wireshark TCP stream, we can see that we successfully logged into Raymond’s account without knowing his private password.
Hacking Playgrounds
If you want to exercise on vulnerable thick client applications, you can find vulnerable thick client applications on the following GitHub repositories:
| # | Tool Name | Description |
| 1 | Damn Vulnerable Thick Client App | DVTA is a vulnerable thick client application developed in C# .NET. |
| 2 | Vulnerable Java (EE) Application | DVJA is a vulnerable thick client application developed in JAVA. |
Closing Words
When developers follow secure SDLC practices and deploy them properly, thick-client applications can be highly secure from attacks. But, not every developer remembers to follow the best practices or deploy the server correctly. These are the weaknesses that attackers will try to exploit and that we – as pentesters – need to identify before the attackers do.
In this blog, we presented our thick client pentest methodology and common attack vectors, including tools that can be used during penetration test engagements. The main focus areas were derived from the OWASP Windows Binary Executable Files Security Checks Project.
We hope that the methodology will be useful to you every time you face a thick client application.
