Introduction:
Serialization is the process of converting an object into a format that can be easily stored or transmitted, such as a string or byte stream. Deserialization is the reverse process — converting that format back into an object. However, if an application trusts and uses serialized data without proper validation, attackers can manipulate it to alter the application’s behavior.
This blog is based on PortSwigger’s lab “Modifying Serialized Objects”, where we’ll explore how insecure deserialization can lead to privilege escalation.
Challenges
PortSwigger provides a hands-on lab titled “Modifying Serialized Objects” that focuses on exploiting insecure deserialization in PHP. The lab presents the following challenge:
“This lab uses a serialization-based session mechanism and is vulnerable to privilege escalation as a result. To solve the lab, edit the serialized object in the session cookie to exploit this vulnerability and gain administrative privileges. Then, delete the user carlos.”
This sets the stage for a classic insecure deserialization vulnerability. In this blog, we’ll walk through the steps to analyze the serialized object, modify it to escalate our privileges, and complete the final goal — deleting the user carlos.
This is a PortSwigger lab web application vulnerable to insecure serialization. We’ll exploit it to escalate privileges and delete the user carlos.
Walkthrough
Step 1: To begin solving the lab, we start by logging into the application using the credentials provided by PortSwigger. While submitting the login request, we intercept it using Burp Suite. This allows us to analyze the HTTP request being sent, especially looking for session-related information — such as cookies — which could potentially contain serialized objects. This is an essential first step to understanding how the application handles user sessions.
Step 2: While logging in, we intercepted the request and response and noticed a session cookie. It appeared to be encoded, so our next step is to analyze and decode this cookie to understand what kind of data it holds.
Step 3: Upon decoding the session cookie using Base64, we discovered that it contains a PHP serialized object:
O:4:”User”:2:{s:8:”username”;s:6:”wiener”;s:5:”admin”;b:0;}%
This indicates an object of class user with two properties — usernames set to wiener and admin set to false. This structure hints that privilege control might be based on this serialized object.
The given string appears to be a serialized PHP object, specifically an instance of a class named User. Here’s a breakdown of its structure:
O:4:”User”:2:{s:8:”username”;s:6:”wiener”;s:5:”admin”;b:0;}%
Analysis:
O:4:”User” → This indicates an object (O) of class “User” with a length of 4 characters.
2 → The object has two properties.
s:8:”username” → The first property is “username”, which is a string of length 8.
s:6:”wiener” → The value of “username” is “wiener”, a string of length 6.
s:5:”admin” → The second property is “admin”, a string of length 5.
b:0; → The value of “admin” is boolean false (0).
% → Possibly an artifact of encoding, transmission, or an incomplete object.
Step 4: After analyzing the serialized object, we modified the admin flag to escalate privileges. Specifically, we changed b:0 (false) to b:1 (true), effectively making the user an admin.
- Original serialized object:
O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin";b:0;} - Modified serialized object:
O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin";b:1;}and encode the Modified Serialize object into base64
Step 5: Now, we replace the original session cookie with our newly crafted one using a browser extension like Cookie Editor. This allows us to inject the modified serialized object (with admin privileges) into the session and continue browsing as an administrator.
Step 6: After updating the session cookie, we refresh the page. This time, we successfully gain access to the admin panel, confirming that the privilege escalation through serialized object manipulation has worked.
Step 7: As instructed in the challenge, we proceed to the admin panel and delete the user carlos. This action completes the objective of the lab and demonstrates the successful exploitation of insecure deserialization to escalate privileges and perform administrative actions.
Step 8: We have successfully solved the lab by exploiting the insecure deserialization vulnerability. By modifying the serialized session object, we escalated privileges and gained admin access, allowing us to delete the user carlos and complete the challenge.
