Thick Client Testing Toolkit Part 5 – Tools & Testing Techniques: Decompiling and Reverse Engineering

Asim Khan
By Asim Khan

March 10, 2016

Decompiling and Reverse Engineering

As mentioned earlier, in Thick Clients majority of the business logic resides in the client application, thus it is important to identify any backdoors that might be present on the client-side logic. To analyze the client-side logic we need to view the source code of the Thick Client application and the best bet is to decompile them to see the business logic.

Additionally, if the Thick Client can be decompiled easily, it will be easy for an adversary to change key business logic checks and recreate the client, which in turn will compromise the apthick client 5_1

JetBrains dotPeek is a decompiler tool that allows the users to view the source code of Thick Clients developed in .Net framework. This includes the Applications developed in C# and Visual basic.

thick client 5_2

How to secure them?

To secure Thick Client applications, security should be implemented in the architecture and development stage. Some of the key best practices that should be followed during Thick Client application development are as follows:

Transport security:
If the application is developed in two-tier architecture, the communication between the application and database server should be encrypted.

If the application is developed in three-tier architecture, the communications between the application and the application server and also between the application server and the database server need to be encrypted.

The transport security can be implemented with the help of IPSEC (Network Layer) or SSL (Socket layer).

Authentication:
Strong authentication and session management should be implemented in the application.
If the application is developed in two-tier architecture, authentication and validation of business logic should be performed at the database tier.

If the application is developed in three-tier architecture, authentication and validation of business logic should be performed at the Application server tier.

Use random and unique tokens to identify users after authentication. Login status check should be performed for all the post-login actions.

Authorization:
If the Thick Client application has multiple roles, then server-side check should be in place that verifies whether the logged-in user has the privilege to perform a particular action or to view a particular section. A common oversight observed in Thick Client applications is that view-based authorization check is performed, but action-based authorization check is not in place.

Input Validation:

Application should validate all the user input for malicious characters.
If the application is developed in two-tier architecture, it is advised to use stored procedures to prevent injection attacks. It should be kept in mind that if dynamic SQL queries are used in the stored procedure, then it will defeat the purpose. Hence, stored procedures should not contain any dynamic SQL queries.

If the application is developed in three-tier architecture, all the user inputs should be validated before processing in the application server tier. There are two approaches for input validation:

• Blacklisting (block a list of characters).
• Whitelisting (allow only some characters).

Insecure Storage:

Thick Clients can create files and Registry entries in the local machine; these files or registries can contain sensitive data like user credentials, database credentials, encryption keys, etc. A local adversary can obtain the sensitive data by accessing them. Hence, if sensitive data are written in a file or registry, then they should be in an encrypted format.

Decompiling and Reverse Engineering

As mentioned earlier, if the Thick Client can be decompiled easily, it will be easy for an adversary to change key business logic checks and recreate the client. This is a major security concern and the application should be resilient to this attack. The best way to tackle this weakness is to have code obfuscation in place. Code obfuscation ensures that if the application is decompiled, the actual source code is not revealed and it makes code recompilation a very difficult process.

About the Author
Muhammed Noushad K. is an EC Council-Certified Security Analyst (ECSA) associated with information security for the past 5 years. He has rich experience in Application Security and Secure Code Reviews. Currently, he is employed as a Security Researcher at Paladion Networks.


Tags: Uncategorized

About

Asim Khan

SUBSCRIBE TO OUR BLOG

Buyers-Guide-Collateral

WHITEPAPER

Buyer’s Guide to Managed Detection and Response

Download
MDR

Get AI Powered

Managed Detection and Response

MDR-learmore-btn

 

MDR-Guide-Collateral

REPORT

AI-Driven Managed Detection and Response

Download Report
Episode

EPISODE-25

Red-LineAsset-6

Why Your ‘Likes’ on Facebook May Be Revealing Far More than You Thought

Click URL in the Post for the Full Podacst
  • FacebookAsset
  • LinkedinAsset
  • TwitterAsset