Thick Client Application Security Testing

Introduction

A thick client is a computer application runs as an executable on the client’s system and connects to an application server or sometimes directly to a database server. Unlike a web-based application, thick clients require a different approach to testing, as they are not easy to proxy using a client-side proxy tool such as Burp Suite.
There are basically 2 types of thick client application.

• Executables (written in one of either Java, C, C++, .net, etc.)
• Java applets

Testing of a thick client application

There are three stages in thick client application testing.

• Dynamic Testing
• System Testing
• Static Testing

Dynamic testing

In this phase of testing we analyze the data transfer from the client application to application server.
Test cases in this phase are as follows

1. Input Validation

This phase involves tests for injection attacks, like SQL injection, Command injection, LDAP injection. These are similar to the standard OWASP tests for a web application

2. File Upload

This phase involves testing for malicious file upload in the application. The tester should check if the application allows the upload of the file with malformed or executable file extensions.

3. Buffer Overflow

In this phase it is observed how the application handles the data provided by the user. It could be tested by injecting large random values in the input fields.

4. SSL or TLS

Check if the request generated by the application is in clear text format while being transmitted over the network layer.

5. Business logic

In this phase the authorization issues in the application can be tested, like updating profile with some other user’s identity, or accessing the documents intended for some other user.

6. Improper error handling

Here the application tester has to observe if any internal error messages (server errors) are disclosed to the application user in response to any invalid value entered by the user.

7. Broken authentication & Session management

Check how the application manages session in the application, and check if this value is reusable, maximum validity of this value, or if this value can be used to access some other user account.

8. Try connecting directly to URLs via the web browser

If the application uses the HTTP or HTTPS protocol then the configuration file the request generated by the application may reveal the URL used to connect the application server. This URL could be used to connect the server directly using web browser. If this case succeeds you can check typical web application related vulnerabilities.

9. Log forging

This test case is valid for applications which store the logs of the user activity on both client and server of the application. Here if the application does not validate the timestamp generated the client on the server side, this may lead to unreliable logs of the user activity. To test this vulnerability, the tester has to change the current time to any random value of the past or future and check if the logs recorded by the application reflect the modified value of time and date.
To execute test cases mentioned in the above module it is recommended to use Echo Mirage or in fact Burp Suite Pro as a web proxy. For applications that do not work on HTTP or HTTPS, tool such as Interactive TCP Relay, Wireshark or Java Snoop would need to be considered.

System level testing

1. Sensitive data in process memory

Check for the clear-text credentials in process memory. Winhex could be used to check for this. This vulnerability is commonly found in the applications which transmit credentials and other sensitive data in clear-text format.

2. Dependencies in process

In this phase we check for the executables and libraries used by the application, these executable includes .exe, .dll, .jar etc. These files may connect to application server or to some third party services and the changes made in registry by the application on the client machine may reveal information about the presence of backdoor in the application.
Tools such as procmon (process monitor) from sysinternals suite is most useful detect such services, executables and registry changes. Regshot is another tool that could be used to detect the changes made in the registry by the application while installation.

3. Privilege levels of the application

In this phase we check for the privilege level of the application on the client machine. If the application running with system level privilege is vulnerable to DLL hijacking this may allow an attacker to elevate his privilege and execute commands as system level user of the client machine.

4. DLL High-jacking

Check if the application validates the DLL or exe used by the application. First step will be to identify the executables used in the application while execution, this could be traced by the process monitor tool present in sysinternals suite. Now replace this DLL/exe file with some malicious file with the same name and check if the application executes this malicious file. To avoid DLL Hijacking vulnerability, application should sign all the executable files and check for the signature before executing the exe or DLL.

Static testing

1. Configuration files (clear text details)

Check if configuration files of the application disclose URL, server credentials or cryptographic keys, etc. Normally these files are in XML format. Though it is recommended to use Jasypt to encrypt the configuration files of Java applications, and use Aspnet_regiis.exe to encrypt the configuration files in .Net applications.

2. Source code decompilation

Check if the executable file could be decompiled to the source code of the application, if yes check for the hard coded credentials, cryptographic keys or business rules which could be modified and the application could be recompiled. To do this JDGUI is the tool used for Java application and Dotnet reflector for .Net applications.

3. Test encryption used in the application

If the application uses encryption, check how encryption keys are stored in the application, what kind of encryption is used in the application (i.e. symmetric or asymmetric encryption).

Conclusion

As we saw, testing a thick client application requires a slightly different approach to the typical testing approach for a web application. However, the tester need not be dissuaded from testing thick client applications. In some cases, use of decompilation makes it easier to understand the entire flow of the code and reverse engineer the application. The use of ‘security by obscurity’, where the coding team thinks that because the application is compiled into an executable, the testing team won’t come to know its internal workings is very common in these cases. This is evidenced by the use of hard-coded credentials, magic numbers, weak encryption, etc. Tools from the sysinternals suite can be useful as well as Wireshark to sniff the traffic from the application to the server. Much of the same web application vulnerabilities can be found in thick client applications as well. So happy testing!