Thick Client Penetration Testing – Exploiting JAVA Deserialization Vulnerability for Remote Code Execution

Thick Client? What do you mean by that?

Thick client is the kind of application which is installed on the client side and major of its processing is done at the client side only which is independent of the server. Like we installed some players or .EXE files in our windows system.

Main difference between Thin Client and Thick Client

Thin client is the browser based application which is having database (server) only in the back end & there is no need to install thin client applications at the client side. Also they are lightweight and do not occupy more space at the client system, whereas Thick client needs more storage space in order to install it on client side.

What is Java Serialization?

Java serialization offers an object to convert itself into a stream of bytes that includes object data to store it into the file systems or to transfer it to another remote system.

After serialize input (stream of bytes) is written to a file, it can be read from the file after deserialization process like stream of bytes then converted to the object again into the memory.

Classes ObjectInputStream and ObjectOutputStream are high level streams that contain the methods of serialization and deserialization.

Why it is vulnerable?

The Apache Commons Collection (ACC) Library is the main reason behind the successful RCE attack. This library has the dangerous class InvokerTransformer which an attacker abused to gain access to remote system.

The InvokerTransformer’s goal is to transform objects in a collection by invoking a method. Attackers take advantage of this functionality and manage to call any method they want.

To create malicious method attacker uses readily available tool called ysoserial

Here is the link to the tool: https://github.com/frohoff/ysoserial

The attack can be summarized as:

  1. A vulnerable application(Thick Client) accepts user supplied serialized objects
  2. An attacker creates malicious payload into stream of bytes (serialization process) to invoke any class/method they want and sends it to application.
  3. Then the application reads the stream of bytes and tries to construct the object from it(Deserialization process)
  4. During deserialization the malicious payload gets executed on target system resulting into compromised system.

 

How to Perform this Attack?

Step 1: First we should know what is the IP and Port the Thick client is communicating to, in order to intercept the request/response using burp suite.

In cmd ping the thick client URL to know the IP.

In our case lets the assume the URL for thick client is http://thickclient:8081 and after pinging this URL we got the IP 192.168.0.1 and port is 8081

Make the changes in the burp proxy

 

Step 2: Edit the host file in your system so that the server host (http://thickclient:8081 in our case) points to local host and our burp proxy can intercept the request.

 

Step 3: Run the thick client and intercept the request in burp

 

Step 4: Now, we will replace this serialized data with our malicious serialized data, which will be de serialized server side and our command will be executed. For this purpose we will use a tool called ysoserial (download: https://github.com/frohoff/ysoserial)

Run this tool with following syntax and create our malicious serialized payload (the IP should be your system IP and port I am using here is 4444)

The output will be somewhat like below

 

Step 5: Now on another side listen to incoming connection from server where our malicious data will get execute. We are using netcat tool for this. You can get this tool here: https://nmap.org/download.html

 

Step 6: Now our payload is created in a file (test.out in my case), we will use Burps ‘paste from file’ option to paste our malicious payload in the intercepted login request as follows and will then execute our malicious data.

 

Step 7: Now to check whether our command got executed or not on the server, netcat to the connection and you can see in below screenshot that we got incoming connection form the server, meaning our malicious code get executed on the server.

 

Further Reading:

  1. https://www.owasp.org/index.php/Deserialization_of_untrusted_data
  2. https://dzone.com/articles/why-runtime-compartmentalization-is-the-most-compr
  3. https://www.synopsys.com/content/dam/synopsys/sig-assets/whitepapers/exploiting-the-java-deserialization-vulnerability.pdf

 

Author
Pranav Jagtap.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.