Introduction
Insecure deserialization is a critical vulnerability that arises when an application processes untrusted serialized data without proper validation, allowing attackers to manipulate application logic or execute unauthorized actions. In this blog, we will explore the PortSwigger lab “Arbitrary object injection in PHP,” where we craft a malicious serialized object to exploit insecure deserialization in a PHP application. We will walk through analyzing the application’s source code, identifying exploitable classes and magic methods, and constructing a payload to successfully manipulate the application’s behavior in a controlled environment.
Understanding Arbitrary Object Injection
As weโve seen, it is sometimes possible to exploit insecure deserialization by simply manipulating the object supplied by the website. However, injecting arbitrary object types opens up many more attack possibilities.
In object-oriented programming, the methods available to an object are determined by its class. If an attacker can control which class of object is being passed as serialized data, they can influence the execution of code during or after deserialization. This can be extremely dangerous, as it allows attackers to invoke specific methods tied to the objectโs class.
Deserialization methods typically do not validate the type of object they are processing. As a result, attackers can inject objects from any serializable class available to the website, and these objects will be deserialized. This means an attacker can instantiate arbitrary classes and control their behavior, even if theyโre not the expected type. While this mismatch might trigger an exception in the applicationโs logic, the malicious object will have already been instantiated and its methods executed.
If an attacker has access to the source code, they can analyze the available classes and identify which ones contain deserialization magic methods, such as __wakeup, __destruct, or __toString. The attacker can then search for methods that perform dangerous actions on controllable data. Once they identify such methods, they can pass a serialized object of the relevant class to exploit these vulnerabilities.
Challenge
This lab uses a serialization-based session mechanism and is vulnerable to arbitrary object injection as a result. To solve the lab, create and inject a malicious serialized object to delete the morale.txt file from Carlos’s home directory. You will need to obtain source code access to solve this lab.
You can log in to your own account using the following credentials: wiener:peter
Walkthrough
Step 1: Log in to the application using the provided default credentials. This will grant access to the user dashboard, where we can begin analyzing the application’s behavior and identifying potential injection points.
Step 2: After logging in, I reached the user dashboard. Now, I will check the HTTP history and try to analyze the requests.
Step 3: This is the request from the dashboard, and once again, I observe the serialized cookie, just as we saw in the previous lab.
Step 4: We analyzed the target and its directory structure. In the target section, we found a libs directory, and inside it, we discovered a file named CustomTemplate.php. We will now send this request to the Repeater.
Step 5: Here, we can see the original request and response.
Step 6: In this step, we inserted a tilde (~) at last into the GET parameter and sent it. We received the source code in the response and were able to see the __destruct function within it. For a better understanding, please refer to the introduction and explanation of Arbitrary Object Injection.
Step 7: Now, we decode the cookie using Base64 encoding. The decoded result is:
O:4:"User":2:{s:8:"username";s:6:"wiener";s:12:"access_token";s:32:"k0ytpxf3nmgqj9rwd6nfawu02ih9hluo";}%3d%3d
Step 8: We modify the deserialized cookie and then re-encode it in Base64. The modified cookie looks like this:
O:14:"CustomTemplate":1:{s:14:"lock_file_path";s:23:"/home/carlos/morale.txt";}%3d%3d
Step 9: Now, we replace the original cookie with the generated one and refresh the page. Although we encounter an error, we notice that our lab is successfully completed, indicating that we have successfully deleted the morale.txt file.
