Introduction
In this lab, we explore a critical vulnerability arising from insecure Java deserialization, specifically when an application uses Apache Commons Collections—a library known to be exploitable when deserialization is not properly secured. Java deserialization vulnerabilities occur when untrusted input is passed directly into a deserialization process, allowing attackers to craft malicious serialized objects that execute arbitrary code on the server. In this PortSwigger lab, we exploit this weakness using a serialized payload generated via the ysoserial tool to gain a shell and execute arbitrary commands. This challenge simulates a realistic scenario that demonstrates the dangers of exposing deserialization mechanisms without proper validation and hardening.
Understanding Gadget Chain
A “gadget” is a snippeof code that exists in the application that can help an attacker to achieve a particular goal. An individual gadget may not directly do anything harmful with user input. However, the attacker’s goal might simply be to invoke a method that will pass their input into another gadget. By chaining multiple gadgets together in this way, an attacker can potentially pass their input into a dangerous “sink gadget”, where it can cause maximum damage.
It is important to understand that, unlike some other types of exploit, a gadget chain is not a payload of chained methods constructed by the attacker. All of the code already exists on the website. The only thing the attacker controls is the data that is passed into the gadget chain. This is typically done using a magic method that is invoked during deserialization, sometimes known as a “kick-off gadget”.
In the wild, many insecure deserialization vulnerabilities will only be exploitable through the use of gadget chains. This can sometimes be a simple one or two-step chain, but constructing high-severity attacks will likely require a more elaborate sequence of object instantiations and method invocations. Therefore, being able to construct gadget chains is one of the key aspects of successfully exploiting insecure deserialization.
Working with Pre-built Gadget Chains
Manually identifying gadget chains can be a fairly arduous process, and is almost impossible without source code access. Fortunately, there are a few options for working with pre-built gadget chains that you can try first.
There are several tools available that provide a range of pre-discovered chains that have been successfully exploited on other websites. Even if you don’t have access to the source code, you can use these tools to both identify and exploit insecure deserialization vulnerabilities with relatively little effort. This approach is made possible due to the widespread use of libraries that contain exploitable gadget chains. For example, if a gadget chain in Java’s Apache Commons Collections library can be exploited on one website, any other website that implements this library may also be exploitable using the same chain.
ysoserial
One such tool for Java deserialization is ysoserial. This lets you choose one of the provided gadget chains for a library that you think the target application is using, then pass in a command that you want to execute. It then creates an appropriate serialized object based on the selected chain. This still involves a certain amount of trial and error, but it is considerably less labor-intensive than constructing your own gadget chains manually.
Note
In Java versions 16 and above, you need to set a series of command-line arguments for Java to run ysoserial. For example:
java -jar ysoserial-all.jar \\
--add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED \\
--add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.runtime=ALL-UNNAMED \\
--add-opens=java.base/java.net=ALL-UNNAMED \\
--add-opens=java.base/java.util=ALL-UNNAMED \\
[payload] '[command]'
In Java versions 15 and below:
java -jar ysoserial-all.jar CommonsCollections4 '$command' | base64
Challenges
This lab uses a serialization-based session mechanism and loads the Apache Commons Collections library. Although you don’t have source code access, you can still exploit this lab using pre-built gadget chains.
To solve the lab, use a third-party tool to generate a malicious serialized object containing a remote code execution payload. Then, pass this object into the website to delete the morale.txt file from Carlos’s home directory.
You can log in to your own account using the following credentials: wiener:peter
Walkthrough
Step 1: As with previous labs, start by logging into the application using the credentials given in the lab description. This step ensures access to the features required to proceed with the exploitation.
Step 2: we analyze the requests in the HTTP history section of Burp Suite. During this analysis, we identify a suspicious cookie that appears to be a serialized Java object.
Step 3: We confirm our suspicion by inspecting the cookie further. Our previous experience with a Java deserialization lab, where we used a gadget chain with ysoserial, helps us recognize that this is indeed a serialized Java object.
For a detailed revision, feel free to refer to my previous lab on- https://cybersecasad.com/insecure-deserialization-java/ which covers similar concepts.
Step 4: We send the request to the Repeater section and modify the cookie in an attempt to solve the challenge, as well as the lab.
Step 5: We create our payload by generating the cookie with the help of ysoserial.jar using the following command:
java -jar ysoserial-all.jar CommonsCollections4 'rm /home/carlos/morale.txt' | base64 -w 0
Step 6: We replace the original cookie with the newly generated one and then encode the cookie into a URL format.
Step 7: After converting the cookie into URL-encoded format, we send the request and observe a 500 Internal Server Error.
Step 8: Despite receiving a server error in the previous step, we check the web application and find that the Lab has been solved.
