Penetration testing of Java Applets/Thick Clients is a lesser-known art. The process of pen testing Java Applets starts from knowing how to intercept data between an Applet and the remote server.
Here is the difference between a Thick client & a Thin client. A Java applet is a thick client. Thick clients are also known as fat clients.
What are Thick Clients
These applications, based on two-tier architecture, are installed on the client-side and connected to the server. However, most of the processing happens on the client-side. These applications use backend databases for storing and retrieving information. Authentication and authorization get done on the client-side. Installation of Thick Clients is on the client-side. Hence the right software upgrades are a must.
Exhibit 1 : 2-Tier architecture in which client directly talks to database
Exhibit 2 : 3-Tier architecture
How to pen test Java Applets
- Intercepting communication
- Observing local storage for sensitive information
- Memory dumping
- Reverse engineering
Thick Client applications do not use HTTP/HTTPS for communication. Due to this, intercepting communication through a regular proxy is not useful in finding vulnerabilities. However, several open-source tools are available for a Thick Client to intercept the communication, such as ITR, Javasnoop echomirage, etc.
Echomirage is the simplest tool, and here is how it can be used to intercept communication.
Step 1: Download echomirage and install it on your system.
Step 2: Run command prompt as an Administrator.
Step 3: Browse java applet path and execute through command prompt (you just opened as an administrator). In this scenario, it is chatGUI.jar.
Open this jar file with the following command: java –jar filename.jar
Exhibit 3: Executing java applet by command prompt
Step 4: The executed applet can be seen.
Exhibit 4: Java Applet login screen
Step 5: Open echomirage as an administrator and click on the “select process for injection” option.
Exhibit 5: Process selection for injection
Step 6: After clicking on “select process for injection” you get a detailed listing of the running process. Select java.exe and press Ok.
Exhibit 6: Selecting Java.exe from the list of processes
Step 7: Click the green button “inject into application.”
Exhibit 7: Process injected
Step 8: Echomirage is ready to intercept the communication between the client and the server. You get a red-colored text indicating that the tool is in injected form.
(Note: Before capturing check interception, enable both outbound & inbound connection under the “Rules” option.)
Exhibit 8: Process is in intercepting mode
Step 9: Use the applet, and echomirage will start intercepting the communication. Now, you can see the data sent by the applet to the server.
Exhibit 9: Captured request by Echomirage
Step 10: Check logs to understand further the communication (i.e., IP address of the server).
Exhibit 10: Log analysis in Echomirage
Note: If you want to intercept any “.exe” file, execute the “.exe” application through echo mirage (Select Application to execute and go to the path of executable and click to launch). Now you can intercept any application as discussed earlier.
Observing local storage for sensitive information
It is essential to check whether the application stores any sensitive information locally or not, without user knowledge. Information is stored in the temp folder, registry, and application folder in file formats such as .ini, .log, .cfg. Check for any new files, as this information may be user’s credentials, cryptographic keys, account details, or any other application-specific sensitive information.
It is easy for an adversary to find credentials by doing memory analysis since the application temporarily stores data like username, password, etc. in the memory for further processing. Passwords and other sensitive information are stored in encrypted or digest form, but if these security mechanisms are not applied, an attacker can find a password and hijack the account. It depends on the password type, whether it’s a database password or a general user password. If the password is of a higher-level user, then it may lead to privilege escalation. The lifetime of these sensitive data depends on the point of whether they get overwritten or not. An adversary can perform a memory dump using WinHex to find such sensitive information and entire memory content, but local access to the system is required to perform such tasks.
Exhibit 11: Password in clear text form
This attack is very easy to launch, as the attacker does not require any exploit code. The only thing required is a tool to dump memory. Hence, it is essential that before launching any product, memory testing must be to ensure that memory does have any sensitive information. If it is there, then it should be in an encrypted form.
This is the most effective technique to bypass client-side validation. In standard web application pen tests, we cannot reverse the application. As thick clients are installed on the client side, reversing client side applications can help penetration testers find some sensitive information i.e. hardcoded username/password, SQL queries, and cryptographic keys. This reverse engineering technique also helps in Android penetration testing.
Only through reverse engineering one can extract the application, decompile it, modify the code, and then recompile the application. This helps in creating malicious applications to launch an attack.
For reversing java applet, you need to download java decompiler, i.e., JD-GUI, and then open that file with a decompiler. After opening with JD-GUI, search for sensitive information.
Exhibit 12: Analyzing code for sensitive information
Pen testing a Java Applet requires a slightly different mindset than a standard client-server application as applets are stored on the client-side. Hence it’s easier to decompile them, understand them better, and attack them. The information listed here can be used as a guide to get a head-start into pen testing Java Applets.