We are all aware of tools like Burp, Paros, WebInspect, etc… for intercepting web-based traffic and also for automating the security testing process. However, the same is not true for thick client applications. We do not have automated tools available for automating the security testing of thick client applications.
In my previous article on “Application Security Testing of Thick Client Applications”, I mentioned a few tools that can be used for penetration testing of a thick client application. We had discussed a tool called Echo Mirage that can be used to intercept and edit the traffic for .EXE based applications. In this article, we will discuss a tool that can be used to assess the security of JAVA based applications.
We are all aware of how difficult it is to intercept thick client applications due to the complexity and nature of these applications.
Let us see the various approaches currently available for testing of Java based thick client applications and their respective drawbacks.
Approach 1: Intercepting and hacking the traffic
If the Java based application uses the following, then we have a chance of intercepting the traffic for testing:
- It uses HTTP
- It has configurable proxy settings
- It does not use encryption, custom protocols or serialized objects
If all the above possibilities are met, we might be able to capture and hack the traffic from a proxy tool like BURP.
Approach 2: Altering the client and hacking
- We identify the JAR files
- Decompile them
- Perform a source code review
- We could alternately alter the code and re-compile the client,then send custom attacks
Decompiling binary Java often results in source code that has a number of compilation errors. These errors are introduced by bugs in the decompilers themselves or the result of a special build processes, which show that the compilation and decompilation processes are not, in practice, 100% deterministic.
The drawback to this approach are that this is not an easy task (re-compiling the code might generate huge errors) and we may end up wasting our time on understanding, altering and then trying to hack something.
The two approaches above might not work and do not provide the security tester the flexibility to carry out a fully fledged security assessment of the Java based thick client application.
To overcome these difficulties, we make use of a tool called JavaSnoop developed by Aspect Security.
Introduction to JavaSnoop
The JavaSnoop tool provides the following features:
- Allows easy interception of any method in the JVM
- Allows the editing of return values and parameters
- Allows custom Java to be inserted into any method
- Able to work on any type of Java application (J2SE, Applet, or Java Web Start)
- Able to work on already-running Java processes
- Not require any target source code (original or decompiled)
These features of the tool make it easier for testing of any kind of Java based apps.
Working of JavaSnoop tool:
Java 6.0 contains the Attach API feature that allows seamless, inter-process modification of a running JVM. The Attach API is a Sun extension that provides a way for a Java process to “attach” to another JVM at runtime. This bridge can be used to load Java agents onto remote virtual machines. Those agents can then redefine classes or retrieve information about the JVM to which it’s attached. This mechanism allows JavaSnoop to satisfy the requirements listed above. JavaSnoop can use the Attach API and the Instrumentation class (helps in modification of a JVM during runtime) to jump into another JVM on the machine and install various “hooks” throughout class methods on that system. These hooks are then used by an agent to communicate with a GUI that allows the JavaSnoop user to “intercept” calls within the JVM.
The hooking technique used by JavaSnoop can perform the following actions:
- Edit method parameters
- Edit method return value
- Pause method
- Execute user-supplied script at the beginning of the method
- Execute user-supplied script at the end of the method
- Print the parameters to the console (or to a file)
Installation of JavaSnoop:
The JavaSnoop tool can be downloaded from the following URL: https://www.aspectsecurity.com/research/appsec_tools/javasnoop/
Step 1:Install JDK 1.6 from the following URL:
Set the JAVA_HOME environmental variable for Windows as follows:
Go to Start > My Computer > Properties > Advanced System Settings > Advanced > Environmental Variable. Set a new user variable to
JAVA_HOME: Path pointing to JDK 1.6 folder as shown below:
Applets and Java Web Start applications are configured to run by default in afairly strict sandbox.Obviously, hacking privileged internal classes andtampering with private fields are not usually allowed. This means we have toessentially turn the security “off”. To achieve this, we need to run the JavaSnoop tool using the startup.bat file provided with the JavaSnoop setup.
This batch file will achieve the following:
- Check for the presence of the environmental variable JAVA_HOME set to the path of JDK 1.6
- Will then turn off the Java security for JavaSnoop usage
- Will start the JavaSnoop tool
- On quitting the tool, this batch file will again turn the Java security back for safe browsing
Injecting JavaSnoop into a Process:
The JavaSnoop tool provides two types of processes to be hacked.
1. An existing process:
We can inject JavaSnoop to an already running process by selecting from the available list of running processes.
2. A new process:
Alternately, we can start a new process by selecting the JAR file to be hooked/intercepted.
Functionality of the JavaSnoop tool interface:
The main interface of the JavaSnoop tool is divided into four parts as shown in the diagram below.
In this part, we select the class or method that needs to be hooked or intercepted. The interface provides a button to add a new Hook. We can then add a method from a specific class available from the list, as shown in the snapshot below:
This part provides features for setting various options for intercepting the method calls. We can set regular expression conditions for matching and intercepting the traffic from the method calls. A snapshot is shown below:
This part of the interface helps in deciding what to do with a particular hook that we select from the part one of the interface. It provides various options like the following:
- Printing the parameters/stacktrace on to the console or a particular file
- Running custom scripts
- Tampering with parameters
- Tampering with return value
- Pausing program
The output from the hooks and the decompiled classes from the target application are shown up in this area.
Intercepting traffic from JAVA based applications using JavaSnoop
In this article, we look at two sample Java based applications and learn to intercept the traffic in the JavaSnoop tool:
- Intercepting the traffic from an applet which runs inside a browser
- Intercepting the traffic from a JAVA based thick client application
1. Intercepting the traffic from an applet which runs inside a browser
A Java applet is an applet delivered to users in the form of Java bytecode. Java applets can be part of a web page and executed by the Java Virtual Machine (JVM) in a process separate from the web browser, or run in Sun’s AppletViewer, a stand-alone tool for testing applets.
It is difficult to intercept the traffic from an applet that is a part of a web page. Normal proxy tools like Burp and Paros fail to intercept / interpret the traffic from these applets. We see an example of intercepting the traffic from an applet using JavaSnoop tool.
Step 1: We have a sample login applet embedded into the web browser, which takes the user credentials and forwards it to the server for authentication. In order to intercept the traffic from the Java Applet, we use the method hooking techniques of JavaSnoop to intercept the traffic.
The snapshot below shows the Login Applet with the user credentials entered into the input fields.
Step 2:As we have already opened the Java applet in the browser, we select the “An existing process” option from the JavaSnoop tool to attach the agent into the running applet as shown below.
Step 3: Attaching the agent into the running applet will open the JavaSnoop interface. We can then select the classes and the respective methods to be hooked for intercepting the traffic. We select the required class for which the methods are to be hooked, as shown below:
Step 4: We then select the methods of that specific class, as shown below:
Step 5: The screenshot below shows the JavaSnoop interface containing the hooked methods and the conditions applied on the methods for intercepting the Java applet traffic.
Step 6: As soon as we submit the user credentials on the Login applet, the tool intercepts the traffic and provides the user with a pop-up window for editing and forwarding the intercepted traffic.
2. Intercepting the traffic from a JAVA based thick client application
In the section above, we learned to intercept the traffic for Java Applets. In this section, we will learn to intercept the traffic for JAR applications. For example, we will try to intercept the traffic from the BURP proxy tool (JAR based proxy tool) to the JavaSnoop tool.
Since JavaSnoop makes application data and traffic easy to tamper with, figuring out the right method to hook becomes a difficult part of the assessment. Although nothing can substitute code review for understanding an application’s logic, a pen-tester without access to the source code has a few options for finding the right hook. The user can choose a Java API they suspect may play a role in a test, they can search for methods by name or class, and they can use a special mode of JavaSnoop, called “Canary Mode”. This mode is very useful in larger applications, where identifying of the correct class and method becomes difficult. We can understand the Canary mode with the example of intercepting BURP traffic in the JavaSnoop tool.
The screenshot below shows the huge list of BURP classes loaded into the JavaSnoop tool. This makes it difficult to identify the correct class and method for hookingand intercepting the traffic.
Even after searching and guessing, it may be difficult to find what methods to hook. It’s likely that attackers are interested in methods where data they put into the UI ends up going. If the flow of their data through the class methods could somehow be seen, it may end helping the user find functions to hook.
Discovering this lifetime is the purpose of “Canary Mode”, a unique and useful feature of JavaSnoop. In this mode, you define some “canary” value that you want to trace through the system. This should be some unique value that you’re going to enter into the application somewhere, probably through a form field or a properties file.
Once this value is chosen, Canary Mode can be started. JavaSnoop will then remove all other hooks currently in use, and then add canary “listeners” to every method in the JVM that has the data type of the canary as a parameter.
Each time the canary is found being sent to a method, a “chirp” is sent back to JavaSnoop, letting the user know what method operated on the canary value. In a way, this amounts to a very primitive, clumsy form of data flow analysis.
Steps to identify the methods to be hooked for testing purposes are as follows:
Step 1: Inject the JavaSnoop agent into the BURP process
Step 2: Open the Canary mode interface in the JavaSnoop tool
Step 3: Input a string to be searched for in the input field
Step 4: Start the Canary Mode listener from the interface
Step 5: Send a request for Google.com from the browser to the Burp tool. The JavaSnoop tool will start populating the list of methods in which the input string (say Google.com) is passed. We can then hook these methods for testing purposes, as shown in the screenshot below:
In this article we saw the drawbacks that can be faced while assessing Java based thick client apps and also saw how the JavaSnoop tool can be used to overcome these difficulties.
- Article on JavaSnoop by Arshan Dabirsiaghi