Thick Client Penetration Testing Methodology_1

___
Products & Services Topics Industry Content Type

Resource Menu
All (https://www.cyberark.com/resources) » Threat Research Blog (https://www.cyberark.com/resources/threat-resear…
Thick Client Penetration Testing

Methodology
Niv Levy | 2/11/20 Share This!    
• 1 Introduction (https://www.cyberark.com/#ThickClientPenetrationTestingMethodolog)
• 2 Common Architectures of Thick Client applications
(https://www.cyberark.com/#ThickClientPenetrationTestingMethodolog)
• 2.1 Two-Ttier architecture

• 2.2 Three-Tier architecture
• 3 How to test thick client applications?

• 3.1 Information Gathering

• 3.1.1 Application Architecture and Identifying the Languages and Frameworks Used
• 3.1.2 Network Communication Between the Client and the Server
• 3.2 Client-Side attacks

• 3.2.1 Files Analysis

• 3.2.2 Identifying DLL Hijacking Vulnerability
• 3.2.3 Identifying Interesting Files Bundled with the Thick Client Application
• 3.2.4 Binary Analysis
• 3.2.5 Weak Graphical User Interface
• 3.2.6 Memory Analysis
• 3.3 Server-side Attacks

• 3.3.1 OWASP TOP10 Vulnerabilities

• 3.4 Hacking Playgrounds

• 3.5 Closing Words (https://www.cyberark.com/#ThickClientPenetrationTestingMethodolog)
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://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://rhinosecuritylabs.com/application-security/nvidia-rce-cve-2019-5678/)
• https://pwning.re/2018/12/04/github-desktop-rce/ (https://pwning.re/2018/12/04/github-desktop-
rce/)
• https://medium.com/@mantissts/more-thick-client-fun-73196809493d
(https://medium.com/@mantissts/more-thick-client-fun-73196809493d)
• https://hackerone.com/reports/513154 (https://hackerone.com/reports/513154)
• https://hackerone.com/reports/291539 (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
(https://www.owasp.org/index.php/OWASP_Windows_Binary_Executable_Files_Security_Checks_Project).
(https://www.cyberark.com/wp-content/uploads/2020/02/1.jpg)
Figure 1: A series of tests and the associated tools necessary to perform tasks related to thick
client testing.
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.
• https://cve.mitre.org/cve/search_cve_list.html (https://cve.mitre.org/cve/search_cve_list.html)
• https://www.exploit-db.com (https://www.exploit-db.com/)
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

A tool that was designed to make PE editing as easy as
1 CFF Explorer (https://ntcore.com/?page_id=388) possible without losing sight of the portable executable’s
internal structure.
A tool that detects most common packers, cryptors and
2 PEid (https://www.aldeid.com/wiki/PEiD)
compilers for PE files.
Detect It Easy (DIE) A program for determining file types for Windows, Linux
3
(https://github.com/horsicq/Detect-It-Easy) and macOS.
A tool that scans any files you pass it for UNICODE or ASCII
Strings (https://docs.microsoft.com/en-
4 strings of a default length of three or more UNICODE or
us/sysinternals/downloads/strings)
ASCII characters.
In Figure 2, We loaded the DVTA.exe
(https://github.com/secvulture/dvta/blob/master/DVTA/DVTA/bin/Release/DVTA.exe) thick client binary
into the CFF Explorer tool and received basic information about the thick client’s development language
(marked in red).
(https://www.cyberark.com/wp-content/uploads/2020/02/4.png)
Figure 2: Damn Vulnerable Thick Client Application loaded by the CFF explorer tool.
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.
Figure 3: Damn vulnerable thick client application loaded by “Detect It Easy” tool.
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:

1 dnSpy (https://github.com/0xd4d/dnSpy) A .NET debugger and assembly editor.
ILSpy is the open-source .NET assembly browser
2 ILSpy (https://github.com/icsharpcode/ILSpy)
and decompiler.
A program for determining types of files for
3 JetBrains DotPeek (https://www.jetbrains.com/decompiler/)
Windows, Linux, and macOS.
4 de4dot (https://github.com/0xd4d/de4dot) .NET deobfuscator and unpacker.
NeonFuscatorDeobfuscator .NET deobfuscator for Autori Obfuscator
5
(https://github.com/NotPrab/.NET-Deobfuscator) (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:

Wireshark is the world’s foremost and most widely-used
1 Wireshark (https://www.wireshark.org/download.html)
network protocol analyzer.
TCPView is a Windows program that shows detailed
TCPView (https://docs.microsoft.com/en- listings of all TCP and UDP endpoints on your system,
2
us/sysinternals/downloads/tcpview) including the local and remote addresses and the state
of TCP connections.
SmartSniff is a network monitoring utility that allows you
to capture TCP/IP packets that pass through your
3 SmartSniff (http://www.nirsoft.net/utils/smsniff.html)
network adapter and view the captured data as
sequence of conversations between clients and servers.
tcpdump is a common packet analyzer that runs under
the command line. It allows the user to intercept and
4 tcpdump (https://www.tcpdump.org/) display TCP/IP and other packets being transmitted or
received over a network to which the computer is
attached.
Microsoft Network Monitor 3.4
Microsoft Network Monitor 3.4 is a tool for network
5 (https://www.microsoft.com/en-
traffic capture and protocol analysis.
us/download/details.aspx?id=4865)
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:
Figure 4: The traffic between the Damn Vulnerable Thick Client Application and the database
server is shown using the WireShark 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
(https://portswigger.net/burp/documentation/desktop/tools/proxy/options/invisible).
Figure 5 presents the steps for configuring the invisible proxy feature on Burp Suite tool.
Figure 5: Burp Suite invisible proxying configuration.
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.
Figure 6: The first step is to click on the injector icon and choose a running process from the
list.
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.
Figure 7: The second step is to modify to SQL query marked in yellow.
The following table presents a set of proxy tools that can be used:

B (https://www.wireshark.org/download.html)urp Suite Burp Suite Professional is an advanced set
1
(https://portswigger.net/burp) of tools for testing web security.
F (https://docs.microsoft.com/en- Fiddler is a free web debugging tool which
2 us/sysinternals/downloads/tcpview)iddler logs all HTTP(S) traffic between your
(https://www.telerik.com/fiddler) computer and the Internet.
Echo Mirage is a versatile local proxy tool
Echo Mirage that can be used to intercept and modify
3
(https://sourceforge.net/projects/echomirage.oldbutgold.p/) TCP payloads for local Windows
applications.
Charles is an HTTP proxy that enables to
view all of the HTTP and SSL / HTTPS
4 Charles Web Debugging Proxy (https://www.charlesproxy.com/) 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:
Figure 8: The Process Monitor filter mechanism enables us to filter unnecessary operations
by configuring rules so that they show us only the relevant operations.
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.
Figure 9: The Process Monitor shows all the relevant operations for our tested thick client
application only – DVTA.exe.
The following table presents a set of file analysis tools that can be used in this part:

Process Monitor (https://docs.microsoft.com/en- An advanced monitoring tool for Windows that shows
1
us/sysinternals/downloads/procmon) real-time file system, Registry and process/thread activity.
An open-source (LGPL) registry compare utility that
allows you to quickly take a snapshot of your registry and
2 Regshot (https://sourceforge.net/projects/regshot/)
then compares it with a second one – used after doing
system changes or installing a new software product.
Provides the functionality of the Windows Task Manager
Process Explorer (https://docs.microsoft.com/en- along with a rich set of features for collecting information
3
us/sysinternals/downloads/process-explorer) about processes running on the user’s system. It can be
used as the first step in debugging software.
A free, powerful multi-purpose tool that helps you
Process Hacker
4 monitor system resources, debug software and detect
(https://processhacker.sourceforge.io/)
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 (https://www.cyberark.com/threat-
research-blog/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:

A tool that detects DLL hijacking in running processes and
1 DLLSpy (https://github.com/cyberark/DLLSpy)
services and in their binaries.
Robber An open-source tool for finding executables prone to DLL
2
(https://github.com/MojtabaTajik/Robber) hijacking.
Run the process monitor tool and apply a filter as shown in Figure 10:
Figure 10: Configure filter rules in Process Monitor tool.
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.
Figure 11: Process Monitor presents only the relevant operations as configured previously in
the Filter mechanism.
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:

Process Monitor (https://docs.microsoft.com/en- An advanced monitoring tool for Windows that shows
1
us/sysinternals/downloads/procmon) real-time file system, Registry and process/thread activity.
allows you to quickly take a snapshot of your registry and
2 Regshot (https://sourceforge.net/projects/regshot/)
then compares it with a second one – used after doing
system changes or installing a new software product.
A tool that provides the functionality of the Windows Task
Manager along with a rich set of features for collecting
Process Explorer (https://docs.microsoft.com/en-
3 information about processes running on the user’s
us/sysinternals/downloads/process-explorer)
system. It can be used as the first step in debugging
software.
A free, powerful multi-purpose tool that helps you
Process Hacker
4 monitor system resources, debug software and detect
(https://processhacker.sourceforge.io/)
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.
Figure 12: The thick client’s folder contains files that might be interesting for us as pentesters.
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:
Figure 13: Configuration files often contain sensitive information, such as usernames,
passwords, connection strings, cryptographic keys, etc.
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:

A suite of free software reverse engineering tools developed
by the NSA’s Research Directorate. It was originally exposed in
1 Ghidra (https://www.ghidra-sre.org/)
WikiLeaks’s “Vault 7” publication and is now maintained as
open-source software.
Immunity Debugger Immunity Debugger is a powerful new way to write exploits,
2
(https://immunityinc.com/products/debugger/) analyze malware and reverse engineer binary files.
Proprietary multi-processor disassembler and debugger for
Interactive Disassembler (IDA Pro) Windows, GNU/Linux or macOS. It also has a free version, IDA
3
(https://www.hex-rays.com/products/ida/) Free (https://www.hex-
rays.com/products/ida/support/download_freeware.shtml).
x86 debugger for Windows binaries that emphasizes binary
4 OllyDbg (http://www.ollydbg.de/)
code analysis.
5 Radare2 (http://rada.re/r/index.html) Open source, cross-platform reverse engineering framework.
6 dnSpy (https://github.com/0xd4d/dnSpy) A tool to reverse engineer .NET assemblies.
7 x64dbg (http://x64dbg.com/) Open source x64/x32 debugger for windows.
JetBrains DotPeek
8 Free .NET decompiler and assembly browser.
(https://www.jetbrains.com/decompiler/)
9 ILSpy (https://github.com/icsharpcode/ILSpy) Open-source .NET assembly browser and decompiler.
JD-GUI (https://github.com/java-decompiler/jd-
10 A standalone Java decompiler GUI.
gui)
11 Jadx (https://github.com/skylot/jadx) Dex to Java decompiler.
Bytecode Viewer
12 A lightweight user-friendly Java bytecode viewer.
(https://github.com/Konloch/bytecode-viewer)
Luyten
13 An Open source Java Decompiler GUI for Procyon
(https://github.com/deathmarine/Luyten)
PE Explorer
14 View, Edit and Reverse Engineer EXE and DLL Files.
(http://www.heaventools.com/overview.htm)
A free, portable, extendable, high-performance executable
15 UPX Decompression (https://upx.github.io/)
packer for several executable formats.
A dynamic instrumentation toolkit for developers, reverse-
16 Frida (https://frida.re/)
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:
Figure 14: The dnSpy tool helps us to edit and debug assemblies, even if we don’t have any
source code available.
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:

A tool whose purpose is to help you view
WinSpy++ (https://www.softpedia.com/get/Programming/Other-
1 and modify the properties of any window
Programming-Files/WinSpyPlusPlus.shtml)
in your system with great ease.
A simple tool to manipulate window
2 WinManipulate (https://github.com/appsecco/winmanipulate)
objects in Windows.
A simple tool that lets you activate
Windows Enabler (https://windows-
3 functions your thick client application has
enabler.en.uptodown.com/windows)
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:

An advanced monitoring tool for Windows that shows
1 Winhex (https://www.x-ways.net/winhex/index-m.html) real-time file system, Registry and process/thread
activity.
allows you to quickly take a snapshot of your registry
Volatility
2 and then compares it with a second one – used after
(https://github.com/volatilityfoundation/volatility)
doing system changes or installing a new software
product.
Provides the functionality of the Windows Task
Manager along with a rich set of features for collecting
Process Explorer (https://docs.microsoft.com/en-
3 information about processes running on the user’s
us/sysinternals/downloads/process-explorer)
system. It can be used as the first step in debugging
software.
Strings scans any file you pass it for UNICODE or ASCII
Strings (https://docs.microsoft.com/en-
4 strings with a default length of three or more
us/sysinternals/downloads/strings)
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.
Figure 15: The first step is running the Process Hacker tool and right-clicking on the tested
thick client application and selecting the properties option.
In the properties window, we should choose the Memory tab, click on the Strings button and then click
OK.
Figure 16: The second step is selecting the Memory tab and clicking on the Strings button,
choosing the maximum length and then clicking 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 17: For easy identification of sensitive information, the third step is filtering the
memory’s data output.
Figure 18 presents the extracted memory from the tested thick client application, which contains a
cleartext connection string to the application’s database.
Figure 18: The Process Hacker tool displays the information according to the filter we defined
earlier.
Now, we can use any SQL client such as HeidiSQL (https://www.heidisql.com/) 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 (https://www.owasp.org/index.php/Top_10-2017_A1-Injection)
• A2:2017-Broken Authentication (https://www.owasp.org/index.php/Top_10-2017_A2-
Broken_Authentication)
• A3:2017-Sensitive Data Exposure (https://www.owasp.org/index.php/Top_10-2017_A3-
Sensitive_Data_Exposure)
• A4:2017-XML External Entities (XXE) (https://www.owasp.org/index.php/Top_10-2017_A4-
XML_External_Entities_(XXE))
• A5:2017-Broken Access Control (https://www.owasp.org/index.php/Top_10-2017_A5-
Broken_Access_Control)
• A6:2017-Security Misconfiguration (https://www.owasp.org/index.php/Top_10-2017_A6-
Security_Misconfiguration)
• A7:2017-Cross-Site Scripting (XSS) (https://www.owasp.org/index.php/Top_10-2017_A7-Cross-
Site_Scripting_(XSS)) (Not applicable for a thick client testing)
• A8:2017-Insecure Deserialization (https://www.owasp.org/index.php/Top_10-2017_A8-
Insecure_Deserialization)
• A9:2017-Using Components with Known Vulnerabilities (https://www.owasp.org/index.php/Top_10-
2017_A9-Using_Components_with_Known_Vulnerabilities)
• A10:2017-Insufficient Logging&Monitoring (https://www.owasp.org/index.php/Top_10-2017_A10-
Insufficient_Logging%26Monitoring)
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 19: Identifying the checkLogin method.
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.
Figure 20: Identifying an SQL injection vulnerability in the checkLogin method.
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.
Figure 21: Testing for SQL injection vulnerability on the login screen of DVTA.
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 22: We successfully logged in to Raymond’s account without knowing his password.
This was possible because the user input was inserted into the SQL query without the
appropriate checks.
Figure 23 presents the tested thick client application’s users table in the database.
Figure 23: When inspecting the users’ table on the application’s database, we can see that
Raymond’s account is listed third in the users’ table (marked in yellow).
In the following Wireshark TCP stream, we can see that we successfully logged into Raymond’s account
without knowing his private password.
Figure 24: A successful SQL injection attack on the Wireshark TCP stream.
Hacking Playgrounds
If you want to exercise on vulnerable thick client applications, you can find vulnerable thick client
applications on the following GitHub repositories:

Damn Vulnerable Thick Client App DVTA is a vulnerable thick client application
1
(https://github.com/secvulture/dvta) developed in C# .NET.
Vulnerable Java (EE) Application DVJA is a vulnerable thick client application
2
(https://github.com/appsecco/dvja) developed in JAVA.

Thick Client Penetration Testing Methodology_1

Uploaded by

Copyright:

Available Formats

You might also like

Thick Client Penetration Testing Methodology_1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thick Client Penetration Testing Methodology_1

Uploaded by

Copyright:

Available Formats

___

Products & Services Topics Industry Content Type

All (https://www.cyberark.com/resources) » Threat Research Blog (https://www.cyberark.com/resources/threat-resear…

Thick Client Penetration Testing

• 2.1 Two-Ttier architecture

• 3 How to test thick client applications?

• 3.1 Information Gathering

• 3.2 Client-Side attacks

• 3.2.1 Files Analysis

• 3.3 Server-side Attacks

• 3.3.1 OWASP TOP10 Vulnerabilities

• 3.4 Hacking Playgrounds

How to test thick client applications?

Application Architecture and Identifying the Languages and Frameworks Used

# Tool Name Description

# Tool Name Description

# Tool Name Description

# Tool Name Description

# Tool Name Description

Identifying DLL Hijacking Vulnerability

• The directory from which the application is loaded

• Write Permissions on a system folder.

# Tool Name Description

Identifying Interesting Files Bundled with the Thick Client Application

# Tool Name Description

# Tool Name Description

# Tool Name Description

# Tool Name Description

OWASP TOP10 Vulnerabilities

The most common vulnerability in thick client applications is SQL Injection.

• In UPDATE statements within the updated values or the WHERE clause.

# Tool Name Description

You might also like