Penetration testing

Data Storage Issues with DAMN Vulnerable Thick Client App

Practical Thick Client Application Penetration Testing using Damn Vulnerable Thick Client App: Insecure Data Storage

Background:

Welcome to part-3 of thick client application penetration testing series. In the first part of this series, we have set up the lab and discussed the information gathering techniques. In the second part of this series, we have discussed traffic analysis for thick client applications. In this third part of this series, let's discuss the data storage issues in thick client applications.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Insecure Data Storage (specifically at client side) has got more attention after the evolution of mobile applications. However, this is not new. Thick client (desktop) applications are also prone to these vulnerabilities. In this article, let us discuss various data storage issues in DVTA application.

Sensitive data in registry:

"Sensitive data in registry" is one of the most common vulnerabilities seen in Windows desktop applications. Developers often use the registry as a storage location for their client-side data storage needs.

Let's analyze DVTA and see if it is storing any sensitive data in the registry.

regshot is a popular tool for analyzing registry modifications. This tool comes handy in understanding registry changes in Windows machine before and after a specific instance. It is hard for us to check the new registry entries added/modified without the help of such tool.

regshot can be downloaded from the link below.

https://sourceforge.net/projects/regshot/

After downloading, launch regshot, and take the 1^st shot by clicking the 1^st shot button. Make sure that you did not start DVTA yet. Also take note that HTML Document is selected in regshot as shown in the figure below.

After taking the 1^st shot, launch DVTA application and login as Rebecca using the following credentials that we setup in part-1.

User credentials: - rebecca: rebecca

If the login was successful, we should see the user logged in. This looks as shown in the figure below.

Now, to see if any changes are made to the registry after running DVTA, let's take another copy of registry by clicking the 2^nd shot button shown in the following figure.

After taking this 2^nd shot, we can compare these two shots by clicking Compare button shown in the figure below.

Let's click Compare in the above figure and observe the HTML output, which will be loaded automatically. This looks as shown in the figure below.

Interestingly, there is a new registry key added, and there are some new values added to this newly added registry key.

These are the currently logged in user details. We can see the username, password, email ID and another interesting key called isLoggedIn. isLoggedIn may be used as authorization check by the application. We will explore the attacks associated with this in a later article.

We can also view these in the registry by navigating to Start Button | run and then typing regedit to open registry. After opening, registry navigates to HKEY_CURRENT_USER | dvta as shown in the figure below.

Note: As shown in part 1 of this series, we can also use Process Monitor from Sys Internals suite to identify the registry entries being accessed by the application.

Obtaining Database credentials:

It is common in applications with two-tier architecture to leave the database credentials in the memory while connecting to the database. This is a design fault, as every two-tier application by default will place the connection string in memory at some point in time. Usually, we see two common cases with two-tier apps to gain access to database credentials.

Case 1:

• Clear text Connection string is hard coded
• Connection String is seen in memory

Case 2:

• The encrypted Connection string is hard coded, so encrypted credentials are found.
• The connection string is seen in memory while the application is decrypting it.

In case 1, we have two easy ways to obtain the connection string. First is to obtain it from the memory and the second is to get it from the hard coded strings.

In case 2, one-way is to obtain the connection string from memory. Another way is to decrypt the connection string.

DVTA application falls under case 2. We will discuss the hard coding part and decryption technique in a later article, but let's see how to get access to the database credentials from memory in this section.

Obtaining connection string from memory:

Let us explore the ways to obtain connection string from memory. We are using a tool known as Process Hacker, which can be downloaded from the following link.

https://sourceforge.net/projects/processhacker/

Download and install Process Hacker in the machine, where DVTA is running. Launch Process Hacker and you should see DVTA.exe process running as shown in the following figure.

We now need to analyze DVTA.exe in memory for the connection string. So, choose DVTA.exe and give a right click on it, then click on Properties as shown in the following figure.

We should be able to see the following window after the above step. Now, Choose Memory and click on Strings to obtain the strings associated with this application in memory. This looks like what we see in the figure below.

After clicking Strings button in the above window, we can choose to have the minimum length of the strings to be displayed next.

Let us leave it to a default value and click OK. Now, we should see all the strings dumped from memory. Since we have a huge number of strings, we can use the Filter button shown in the figure below, to look for what we need.

From part-1 of this series, we have setup database server's IP address as 192.168.56.110. As DVTA has to communicate with this IP, let us check for this IP using the filter available. This looks as shown in the figure below. Next, click OK.

Now, we should see the strings containing the pattern we are searching for. Notice the output highlighted in the figure below. We have got the Connection String used in the application.

Following are the database credentials dumped.

Database name: DVTA

username: sa

password: p@ssw0rd

As you can see, the application is connecting to the database as "sa," which is a privileged account. This is another important security issue that we should note. It is always recommended to provide a least privileged account to minimize the attack surface.

Connecting to the database:

Now, we can use any SQL client such as Heidi SQL to connect to the database using the credentials obtained.

The following window shows the values to be used with Heidi SQL client.

We will see the following after connecting to the database. As we can see in the figure below, there are two tables associated with DVTA.

Clicking on dbo.users will show us the entries in it. This looks as shown in the figure below.

As you can notice, the user credentials in the database are stored in clear text.

Hard coded credentials:

Another commonly seen issue in thick client applications is hard coded credentials. In the previous article, we have seen that DVTA uses clear text FTP communications for uploading some data to its server. The same credentials can be obtained by looking at the hard coded strings in this application.

The following figure from DVTA's Github page shows the code used to upload FTP data. We can notice those credentials highlighted.

If your question is about what if we do not have source code; we can reverse engineer the application using a .NET decompiler or get strings from the executable itself.

We will discuss the reverse engineering tools later. Let us see the strings.exe tool available in Sys Internals suite to grab the strings of our interest.

The following figure shows the command searching for the string ftp within DVTA.exe binary.

Though we need to look for these from the strings output, I am grepping and showing that we can find these strings in the application binary itself since we already knew them.

The following figure shows the command searching for the string dvta, which is the username.

The next figure shows the command searching for the string p@ssw0rd, which is the ftp password.

How you find the credentials is your choice, but the idea here is to demonstrate various ways of doing it.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Conclusion:

In this article, we have learned how DVTA application can be used to practice various data storage issues and then we have seen how to analyze memory for sensitive data, followed by hard coding issues. In the next article, we will discuss vulnerabilities related to input validation.