Background:

In the previous article, we have discussed the basics of DLL Hijacking vulnerabilities and how one can find and exploit DLL Hijacking vulnerabilities in DVTA application. In this article, we will discuss some miscellaneous test cases that can be used against Thick Client Applications. These test cases include Application Logging, Developer Backdoors, Unreliable Timestamps and lack of application signing.

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

Logging:

A commonly seen functionality in thick client applications is application logging. During the development, developers often log sensitive information into the application console or files for debugging. When the application is pushed into production, developers should make sure that the code associated with the logs is removed and no sensitive information is logged.

Let us test Damn Vulnerable Thick Client Application to see if it is logging any sensitive information into the console.

Let us launch DVTA.exe from the command line and write all the console logs in a text file as shown in the figure below.

Now, launch the application and login with a user account. Next, close the application and the console and then view the content in the text file.

As you can see in the preceding figure, the application is leaking a lot of sensitive information, which includes database connection string and credentials of the users logged in (SQL query).

Time Stamps:

It is commonly seen in applications to log time stamps of user activities. This may be later used for forensic investigations or other similar activities. If the application is reading time stamps from the client side and if it is not validated at the server side, it will result in unreliable logs as a user with malicious intent may change his current system time to an incorrect value.

Let us see if DVTA has this problem.

Login with the credentials – rebecca:rebecca and you should see the following screen as usual.

Now, let us click add expenses and add some expenses as shown in the figure below.

When you click save in the above window, the application will also save time along with other data.

Let us change the system time to an incorrect value. Originally, the time is 6:38 PM on the server as shown in the figure below.

But, we have changed our client's time to 9:01 PM as shown below.

Let us click save and you should see the following entry added in the database.

So, it is clear that there is no validation on the server to make sure that the time sent by the client is valid.

Developer backdoors:

Developer backdoors is a commonly seen problem everywhere. We often see backdoors in application code, and it is essential to spend decent amount time to spot these during an assessment.

If you remember, DVTA has an admin login. Did you notice what data could be uploaded to admin's FTP server after logging in as admin?

If not, take a look at the following code.

The above code is calling a function called getExpensesOfAll() and uploading the returned data to admin's FTP Server.

Let us see what getExpensesOfAll() is doing by observing the following code.

As you can see in the above figure, this code is fetching all the records from expenses table. This means admin is exporting all the users' individual expenses details to his server.

Unsigned Code:

It is often seen in penetration testing exercises that the developers do not sign the applications before releasing them to their customers. It is essential for a company to sign their applications to ensure the integrity and reputation of the application. When an application is digitally signed, it ensures that the application cannot be tampered with.

What if a malicious developer creates an application and signs it with a certificate? Can we trust the application? This is where we need to check for its reputation. When well-known companies such as Google, Adobe, and Microsoft, etc. sign software, chances are more likely to trust the software. We can additionally look for other factors such as the number of downloads, anti-virus reports, browser security checks during the download, etc. if the software is signed by a small company. Code Signing increases the trust in the software that users have.

So, it is one of the common checks that we can make during an assessment to make sure that the assembly is signed by developers. We can use Sigcheck.exe from Sysinternals suite of tools to check this.

Let's run sigcheck.exe against DVTA.exe and see if it is signed.

Command: sigcheck.exe <path to DVTA.exe>

The preceding screenshot shows that the binary is not signed. So, it is recommended to sign the application before its release.

Binary analysis with BinScope:

BinScope is a binary analysis tool provided by Microsoft. This tool is useful to check if the software being audited is making use of common exploit mitigation techniques such as DEP, ASLR, etc.

Let us audit DVTA.exe using BinScope to check if there are any issues.

Download and launch BinScope, then choose the target binary to be audited. In our case, it is DVTA.exe

Click Start and our binary should be audited. We will get a report with the Failed & Passed checks as shown in the figure below.

BinScope has identified on Failed check – SNCheck. This is flagged because the developer didn't sign DVTA.exe. We already discussed the need for signing assemblies in the previous section.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Conclusion:

In this article, we have discussed some commonly seen vulnerabilities in Thick Client Applications. We have seen how DVTA application is writing sensitive data into the console, we discussed the developer backdoor included in DVTA and finally we discussed some important checks on the binary itself. In the next article, we will discuss Source Code Review for DVTA.