This article discusses in detail the lesser known art of Pen-Testing Java Applets/Thick Client apps. Here I have explained in detail the process of Pen-Testing Java applets starting from how to go about intercepting data between an Applet and the remote server.
Before pentesting Java Applet, let's understand the difference between Thick client & Thin client, in brief as java applet is a thick client. Thick client are also known as fat client.
These applications are installed on client side although they are connected to server but almost all the processing happens at client side only. They use their backend databases for storing and retrieving information and thus authentication and authorization is performed only on the client side. As these applications are installed at client side, proper maintenance of software upgrade is required. They are based on 2 tier architecture.
Fig1: 2-Tier architecture in which client directly talks to database
Fig2: 3- Tier architecture
Pentesting Java Applet Steps:
- Intercepting Communication
- Observing local storage for sensitive information
- Memory Dumping
- Reverse Engineering
Generally Thick client applications do not use HTTP/HTTPS for communication, so intercepting communication through regular proxy will not help find vulnerabilities. However, there are a number of open source tools available for thick client to intercept communication, like ITR, Javasnoop echomirage, etc. I have tried almost all tools, but here I will describe intercepting communication by echomirage, as this is the simplest tool through which newbies as well as advanced skill people can intercept the communication. Let me show you step by step how to intercept:
Step 1: Download echomirage2 from http://www.bindshell.net/entry/31.html and install it on your system.
Step 2: Now run command prompt as an Administrator.
Step 3: Browse path of java applet and execute through command prompt (that 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
Fig3: Executing java applet by command prompt
Step 4: Our executed applet can be seen.
Fig4: Java Applet Login Screen
Step 5: Open echomirage as an administrator and click on “select process for injection” option.
Fig5: Process Selection for Injection
Step 6: After clicking on “select process for injection” you get a detailed listing of running process. Now go for java.exe and press Ok.
Fig6: Selecting Java.exe from the list of processes
Step 7: Press the green button “inject into application” to inject into our java process.
Fig7: Process Injected
Step 8: Echomirage is ready to intercept the communication between client and server. You get a red line indicating that currently the tool is in injected form.
Note: Before capturing check interception, enable both outbound & inbound connection under “Rules” option.
Fig8: Process is in intercepting mode
Step 9: Use your applet and echomirage will intercept the communication. Now you can see what data your applet is sending to server.
Fig9: Captured Request by Echomirage
Step 10: Check you logs for further understanding of communication i.e. ip address of server.
Fig10: 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 very important to check whether application is storing any sensitive information locally or not, without the knowledge of computer user. This information will be stored in the temp folder, registry and application folder in various file formats like .ini, .log, .cfg. It is recommended to check any new files that are created, as this information may be user’s credentials, cryptographic keys, account details or any other application specific sensitive information.
Memory Dumping: It is easy for an adversary to find credentials, by doing memory analysis, as the application temporarily stores data like username, password etc, into the memory for further processing. Generally all these passwords and other sensitive information are stored in encrypted or digest form, but if these security mechanisms are not applied, an attacker can find password and hijack the account. It depends on the password type whether its database password, or 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 whether they get overwritten or not. An adversary can perform memory dump using WinHex to find all this sensitive information as well as entire memory content, but local access of the system is required for performing all these tasks.
Fig11: Above Screenshot showing Password in Clear Text Form
This attack is very easy to launch, as attacker don’t require any exploit code, the only thing that is required is tool to dump memory. Hence, it is very essential that before launching any product memory testing should be done to ensure that any sensitive information is not stored in memory and if it is there then it should be in an encrypted form.
Reverse Engineering: This is the most effective technique to bypass client side validation. In general web application pentest we cannot reverse the application, but as thick client is installed on client side reversing client side application can help penetration testers to find some sensitive information i.e. hardcoded username/password, SQL queries, cryptographic keys. This reverse engineering technique also helps in Android pentesting.
As android is not a part of this article we will not talk much about it except for some key points. Only through reverse engineering one can extract the application, decompile it, modify the code and then recompile the application. In this way one can make malicious applications and can launch an attacks.
For reversing java applet, you need to download java decompiler i.e. JD-GUI and then open that file with decompiler. After opening with JD-GUI search for sensitive information
Fig12: Analyzing code for sensitive information
Conclusion: Pen-Testing a Java Applet requires a slightly different mindset as compared to normal Client-Server application, due to the basic reason that these applets are normally stored on the client side. Hence it’s easier to decompile them, understand them better and hence attack them. This article can be used as a guide to get a head-start into Pen-testing Java applets.
About Author: Nitin has been working with Aujas as a Security Researcher in the Telecom Security domain. With a rich back-ground in application, Mobile and net-work security, Nitin is now involved in researching about new and emerg-ing threats to the Telecom Core Nodes. Apart from Research, Nitin is also in-volved in assisting in the implemen-tation of security measures for Fixed/ Mobile Network (2g/3G/LTE) and core fixed network systems to regulate access to specific network elements for the secure oper-ation of the core fixed network and all its variants.
Disclaimer: This article was published in Hakin9's December 2012 issue - http://hakin9.org/how-to-protect-your-company-against-intruder-with-hakin9-122012/