Thick Client (Desktop) Application Penetration Testing - Part-2

Thick Client (Desktop) Application Penetration Testing – Part-2

by

Privilege Escalation using RegShot

  • You can directly download using this link: https://sourceforge.net/projects/regshot/
  • Regshot is an excellent open-source registry comparison utility.
  • It helps compare registry entries before and after installing new software by taking snapshots.
  • We will use Regshot to identify registry modifications made by our application.
  • After downloading, extract the files to any desired location.
  • Run the portable version of Regshot on your machine.
  • This is the initial and fresh interface of Regshot.
  • First, select the HTML document radio button and click on “1st shot.”
  • After completing the 1st shot, open the vulnerable application (DVTA in this case).
  • Log in with any normal user and interact with some valid feature buttons, keeping the features running.
  • Now, click on the “2nd shot” button.
  • Both shots (before and after running the vulnerable application) are now complete.
  • Click on the “Compare” button.
  • Open the generated HTML document with any browser or tool; I chose Edge browser to read it.
  • Here are a bunch of lines of information.
  • The HTML file shows all the differences between the 1st and 2nd shots.
  • Carefully analyzing the document (marked with a rectangle), initially, the values of username, password, email, and isLoggedIn were ‘null.’ After running the application and logging in with valid user credentials, this information was populated one by one.

DLL Hijacking

  • DLL stands for Dynamic Link Library, which contains executable code loaded into RAM when needed.
  • DLL Hijacking is a common vulnerability.
  • Applications search for DLLs if the accurate path is not provided, using paths set by Windows global environmental variables.
  • To understand DLL Hijacking, one must know how Windows applications locate DLL files without a full path.
  • If an attacker replaces a DLL with a malicious one having the same name, the application may load the attacker’s DLL, executing malicious code. This is known as DLL Hijacking.
  • Use the ‘ProcMon’ tool from the ‘SysInternals Suite’, no separate download or installation is needed.
  • This is the initial and fresh interface of the Process Monitor tool (ProcMon).
  • Run the vulnerable application (DVTA.exe).
  • Simplify analysis of the operations by focusing on our vulnerable application (DVTA.exe). Filter the traffic to show only the DVTA process.
  • Let’s make it easier to our analyzing or searching part using another new two filters (Result is NAME NOT FOUND) (Operation is CreateFile).
  • Multiple DLLs are shown as “NAME NOT FOUND” indicating vulnerability to DLL Hijacking and potential usability for this attack.
  • I understand you might be wondering how to exploit this vulnerability, right? Don’t worry.
  • To exploit vulnerabilities, once you find the location, you need a safe and effective payload.
  • I recommend creating a “calc.dll” (safe and very generic) payload using any tools or codes. Since I’m feeling lazy, I suggest using the “msfvenom” tool for this task.
  • After creating the payload, rename it to match the found missing DLL filename (e.g., rename calc.dll to DWrite.dll) and place it in the appropriate location (refer to the last POC image).
  • Now it’s your turn to proceed with the exploitation.

Sensitive information in Memory (Dumping connection string from Memory)

  • Extract the file and run it.
  • Similarly, run the vulnerable application. No need to log in.
  • Open the “Process Hacker” tool and locate the target application.
  • Right-click on the target application and select “Properties”.
  • Navigate to the ‘Memory’ tab.
  • Click the ‘Strings…’ button.
  • A pop-up with multiple options will appear.
  • Follow the recommended options from the screenshot one by one.
  • View the results.
  • Use the ‘Filter’ option in the bottom-left corner with four sub-options.
  • Click the ‘Contains…’ button.
  • Another ‘Filter’ pop-up will appear.
  • Enter the string you want to search within the results.
  • For example, search for the database connection string using the keyword ‘Data Source’ and click ‘OK’.
  • Boom! The database connection string with the current SQL Server “UserId” and “Password” is found.

Let’s try to log in with this credential using HediSQL:

  • Once the download is complete, install it.
  • The installation process is straightforward; simply click “Next” until the installation is finished, without making any changes.
  • Open the HeidiSQL application.
  • Upon installation, you will encounter a clean and user-friendly interface.
  • Select the ‘New’ button.
  • Navigate to the ‘Settings’ tab.
  • Configure your ‘Network type’; for instance, Microsoft SQL Server can be identified from the provided POC string.
  • Input the Hostname/IP address and the necessary credentials.
  • Finally, click the ‘Open’ button to proceed.
  • Upon successful login, the figure below illustrates the tables associated with the application. Notably, the table named “dbo.users” contains sensitive information, including passwords. It is important to highlight that these passwords are stored in plain text.

Remediation: Sensitive information should be encrypted. If encryption is not possible, use obfuscation techniques based on the application’s severity.

Passwords In Registry

  • The Registry Editor in Windows is a tool that stores settings and configurations for the operating system and installed software.
  • It’s like a big database where Windows keeps information about how things should work on your computer.
  • You can use it to view, change, or delete these settings, but it’s important to be careful because making the wrong changes can cause problems with your computer’s performance.
  • Run the target application.
  • Log in with valid user credentials and keep the application running.
  • Open the ‘Registry Editor’, also known as ‘regedit’.
  • Use the Run terminal with ‘Win + R’ and type ‘regedit’, or search for it directly.
  • Locate the registry path of the target application.
  • Notice that all sensitive information is stored in plain text.

Remediation: Encrypt passwords before storage, or store garbage values instead of passwords.

Sensitive Information in Hexdump

  • Hexdump is a utility that displays the contents of binary files in hexadecimal, decimal, octal, or ASCII.
  • It is used for inspection, data recovery, reverse engineering, and programming.
  • In some cases, Hexdump stores sensitive information like username, password, email, permissions, and other information.
  • Begin testing by opening the vulnerable application and logging in with valid user credentials.
  • Keep it running …
  • Open Task Manager, locate the running vulnerable application, right-click on it, and select ‘Create memory dump file.’
  • After creating the dump file, open it with a text editor, such as Notepad.
  • The dump file contains both encrypted and plain text information.
  • Use Ctrl + F to search for specific information; In most cases, login credentials stored in RAM are not encrypted. in this case, search for the login credentials used.

Remediation: Encrypt sensitive data stored in in-process memory.

Unsigned DLL/EXE Vulnerability

  • All DLL and EXE files used by the Thick Client Application should be digitally signed with valid certificates.
  • Internal organization certificates can be used for signing these files.
  • Download Sysinternals tools from the following link and locate the ‘sigcheck’ application: https://download.sysinternals.com/files/SysinternalsSuite.zip
  • Let’s verify the signature of DLL and EXE files.
  • The advantage of ‘sigcheck’ is that it identifies the signatures of all files in the given path simultaneously.
  • We found that ‘Excelibrary.dll’ is ‘Unsigned’ using ‘sigcheck.’
  • We can also verify this using another method, the PowerShell utility.
  • We saw an ‘unsigned’ application, but now let’s check another file that is signed to see how it looks.

Remediation: It is recommended to sign all DLL and EXE files of the thick client using the organization’s certificate.

Reverse Engineering and Hard-Coded Sensitive information

  • Extract and open it.
  • Run the dnSpy.
  • Open the vulnerable application (DVTA.exe).
  • Here is the complete decompiled application name and its version in the title section.
  • Let’s explore all functions and classes.
  • Open the “addExpenses” page of the application, where you will see the “DBAccess” namespace. Click on it to explore further.
  • There is a function called “decryptPassword()” used to decrypt the database password.
  • Similarly, we selected the “Admin()” class and found that the application uploads some data to the server.
  • The application uses FTP to upload the data, and the FileZilla server credentials are hardcoded.
  • Open the “Login” page and you will find the “checkLogin()” function. Click on it to explore further.
  • The “checkLogin()” function directly calls “DBAccessClass” and verifies user credentials through a defined SQL query when they are entered on the login page.
  • Given the hardcoded login credential verification SQL query, an attacker could easily perform an SQL injection attack.

SQL injection

  • Issues such as SQL injection arise when untrusted input is passed to an interpreter as part of a query or command.
  • Desktop applications often utilize 2 or 3-tier architecture, and the impact varies based on the sink.
  • Databases like MySQL and MSSQL are commonly used, exposing desktop apps to SQL injections.
  • Many desktop applications rely on system calls in the background, rendering them susceptible to OS command injection.
  • Desktop apps that render HTML content, such as email clients, are prone to HTML injections.
  • Vulnerable sinks include scripting templates, XPath, and LDAP, among others. Thus, similar to web applications, desktop apps are at risk of common injection attacks.
  • Furthermore, if desktop apps consume web APIs or microservices, they become susceptible to relevant web attacks.
  • Impact: Depending on the sink, the consequences may range from successful privileged command execution and unauthorized data access to complete system compromise or denial of service.
  • Let us commence our testing.
  • Firstly, I am eager to examine the functionality of my login code logic.
  • Open ‘dnSpy’ and load the ‘DVTA.exe’ file.
  • Navigate to the ‘login’ tab and observe the ‘checkLogin’ function being called; let us explore its operation.
  • Upon clicking ‘checkLogin’, we are redirected to ‘DBAccess’ or ‘DBAccessClass’.
  • Observe the code here, which illustrates how the application processes user credentials.
  • Let us examine the query: SELECT * FROM users where username=” and password=”;
  • Upon confirming the possibility of bypassing or executing SQL queries through the ‘Username’ and ‘Password’ fields, we will explore various standard SQL injection scenarios to bypass authentication.
  • We will discuss:
    • The classic technique is to bypass authentication without knowing any username or password.
  • Here, I will enter a SQL query that bypasses validation and achieves successful login without requiring a username and password.
  • The payload is: a’ or ‘1’=’1’—
    • This payload is divided into four parts:
      • The first part, “a’”, closes the ‘Username’ input field.
      • The second part, “or”, separates the first part from the third. If either side of this condition is true, the output will be true.
      • The third part, “‘1’=’1’”, is a condition that is always true, as “1=1” is always valid.
      • The final part, “–”, comments out the rest of the SQL statement, ensuring anything following it is ignored.
  • The modified query now appears as: SELECT * FROM users where username=’ a’ or ‘1’=’1′–‘ and password=”;
  • Let’s insert the payload into the ‘Username’ field, enter any text into the ‘Password’ field, and click ‘Login’.
  • Notice how our payload successfully works and logs in as the ‘ashok’ user.

Authentication bypass with only the username:

  • Let’s assume we know the username of the vulnerable application. In this instance, the username is “ashok”. We will create an SQL payload using this username.
  • The payload is: ashok’–
  • This translates to: SELECT * FROM users WHERE username = ‘ashok’–
  • After validating the registered username, “–” comments out the rest of the validation query, allowing us to successfully log in as the user “ashok”.

Admin login with false condition

  • There are multiple ways to exploit SQL injection to successfully log in as the “admin” user. Here, we will explore two examples.
  • Firstly, using a false condition:
  • Payload: admin’ or ‘1’=’2’–
  • This payload consists of four parts:
    • First is “admin’”, which closes the ‘Username’ input field.
    • Second is “or”, separating the first and second conditions. If either condition is true, the rest of the query is ignored.
    • Third is ‘1’=’2’, a condition that is always false.
  • Note: Although the third condition is false, the first condition is accepted due to the “Boolean Logical Operators”. The “–” at the end comments out the rest of the query, allowing successful login as “admin”.
  • Secondly, we can provide the username and comment out the rest of the query:
    • Payload: admin’–

Remediations:

  • One widely adopted practice involves treating all user input as potentially risky and sanitizing it accordingly.
  • Industry standards recommend using stored procedures or parameterized queries to handle SQL queries securely.
  • It’s crucial to prevent user input from directly executing system-level commands.
  • Employing appropriate forms of encoding based on the intended use can effectively mitigate injection vulnerabilities.

Sensitive data leak using ‘strings’ tool via strings

  • Sometimes, details in code or information may be overlooked or not thoroughly read.
  • However, utilizing the ‘strings’ tool allows for the extraction of information in a sequential manner, revealing hardcoded credentials, tokens, and other sensitive data.
  • The tool is readily available in the ‘SysInternals Suite’ for installation.
  • Here’s a guide on leveraging the ‘strings’ tool to uncover sensitive information within our vulnerable application.

Remediations

Involves refraining from exposing sensitive data and implementing robust encryption methods to safeguard such information.

Side Channel Data Leak

  • Application logging exemplifies a significant form of Side Channel Data Leaks.
  • During development, developers frequently utilize logging for debugging purposes, writing and debugging logs to the console or files on disk. However, if these debug logs remain present when the application moves to production, they pose a security risk.
  • Let’s examine the vulnerable application to see if it’s recording sensitive information in its console logs or not.
  • To do this, open Command Prompt (CMD), go to the directory where the vulnerable application is located and run the application by typing: vulnerableApplication.exe > path-where-you-want-to-store-log-file/logFileName.log
  • Executing this command will launch the vulnerable application and save its output to a log file in the specified path.
  • After logging into the application, click on “Add Expenses,” then “View Profile,” and finally log out.
  • Next, log in with an Admin account such as “admin,” explore the application, click on “Backup Data to FTP Server and log out.
  • Essentially, we are navigating through the application to generate logs. This process will create a log file on the desktop.
  • Open this file using Notepad to find various interesting details, such as users ‘usernames’, and ‘passwords’, decrypted database passwords, database connection strings, and SQL queries.