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 applications.
- Executables (written in one of either Java, C, C++, .net, etc.)
- Java applets
Testing of a thick client application
There are three stages of thick client application testing.
- Dynamic Testing
- System Testing
- Static Testing
In this phase of testing, we analyze the data transfer from the client application to the application server.
Test cases in this phase are as follows
- 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
- 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.
- 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.
- SSL or TLS
Check if the request generated by the application is in clear text format while being transmitted over the network layer.
- 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.
- 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.
- Broken Authentication & Session management
Check how the application manages session in the application, and check if this value is reusable, the maximum validity of this value, or if this value can be used to access some other user account.
- Try connecting directly to URLs via the web browser
If the application uses the HTTP or HTTPS protocol then the configuration files 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 a web browser. If this case succeeds you can check typical web application related vulnerabilities.
- Log forging
This test case is valid for applications that 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, a tool such as Interactive TCP Relay, Wireshark or Java Snoop would need to be considered.
- 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.
- 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 the application server or to some third party services and the changes made in the registry by the application on the client machine may reveal information about the presence of a 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.
- 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 a system-level user of the client machine.
- DLL High-jacking
Check if the application validates the DLL or exe used by the application. The 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, the application should sign all the executable files and check for the signature before executing the exe or DLL.
- 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.
- 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.
- 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).
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!