Why thick client penetration testing?
Thick client applications are not new having been in existence for a long time, however if given to perform a pentest on thick clients, it is not as simple as a Web Application Pentest.
Thick clients are majorly used across organizations for their internal operations.
In this series of articles, we will learn various tools and techniques used to perform thick client application penetration testing.
A step by step breakdown being deployed, we will discuss about starting with the very basics to the advanced test cases.
Referenced under multiple names, such as: Fat client/Heavy client/Rich client/Thick client, such applications follow a client–server architecture.
For an easy to understand approach, thick clients are applications which are deployed locally on our systems. Such as skype/ outlook.
Thick clients can be developed using multiple languages such as: .NET, C /C++, Java
Architectural view of Thick Client applications:
A typical setup where a client and a database interacts with each other. Here the bulk of processing and operations are performed on the client side, while the database operations and queries once executed makes the data processed and stored on the database.
Why is this insecure?
Deploying such a setup opens up multiple vulnerabilities which may lead to compromise of database credentials along with plethora of multiple exploits within the application.
This is the alternate and well-structured 3-tier architecture. Here the client server has three components defined:
The bulk of processing is done at the server side while the queries are performed at client side with requests. This makes security stringent at than a 2-tier application, however not fully safe.
What are the security testing methods feasible for Thick Client?
We can break down the different types of pen testing a thick client into:
- Dynamic Testing ( fuzzing, traffic interception, injections)
- System Testing ( checking for logs, data files, registry keys, process threads)
- Static Testing ( reverse engineering, binary analysis )
Dynamic testing generally follows data flow from the client side to server side.
This gives rise to the following test cases:
- Dynamic test cases:
Input Validation (Fuzzing user input fields)
Here our main goal is to test all the input parameters for different types of attacks which includes:
- SQL injection
- Command injection
- Malicious input acceptance.
SQL injection is one of the prime attacks you can carry onto a thick client’s database. Do note performing thick client sql injection needs patience and is a time consuming task. You need to iterate multiple queries with a mix and match by observing response to each of them.
Some good links for a collection of sqli payloads:
You can crawl the net for multiple payloads to find the one which is appropriate for the application you are testing.
Here our goal is to attempt to upload malicious files which can be injected into the application input request which can lead us to shell upload/ malicious code execution.
Here you can simply check for all the browse buttons and check the file upload logic.
Here our goal is to examine C / C++ programmed thick clients majorly to test the memory functions deployed which will allow us to check how the buffer overflow vulnerabilities and memory violations.
Secure traffic analysis (protocols)
The testing for this case involves checking whether encryption is applied for sensitive data on the wire or not (example: clear text data transmission is a vulnerability)
Business logic validations
This has multiple sub test cases which can involve privilege escalation, price tampering, authorization bypass etc.
Error handling/ Info Leakage
Tester tries in this case to extract verbose error messages which may give information about underlying framework, application code and log details.
Test cases on session validity/ expiration/ fixation comes under this method.
Forced URL access via browser
Many a times, configuration URLs can be directly connected via the web browser
Most of the applications we test does not validate the timestamp directly accepting the local system time from user, performing malicious transactions via changing the system time leads to inconsistency of the application logs.
- System Test cases:
Exfiltration of Sensitive data from memory
Many times applications store username passwords. Such information is lethal for compromising the application. There are multiple tools which help us to check the same (A free tool for the same is Winhex)
Test case for this involves: if the application validates the DLLs used by the application. If by replacing the actual DLLs with malicious file with the same name, this can lead to critical findings in the application.
- Static Testing:
Analysing Config files
Many a times configuration files of the application reveals URL, Server credentials/ Cryptographic keys/ Hardcoded passwords. Even checking of certain parameters can be easily disabled with a value =yes with = no!
Using reversing tools, executable file/ jar files can be decompiled which can be modified and repackaged
That’s all readers for now. This article gave you a brief idea of how to go about testing an application.
In upcoming articles we will cover the following yet not limited to topics:
- Intercepting thick client applications and tampering request/ response
- Reverse engineering jar/ exe files
- DLL Hijacking
- Memory forensics
- Deserialization of traffic analysis of java thick clients